Proposed tabbed_pane widget changes

I've been brainstorming about the tabbed pane widget and come up with a 
number of changes I'd like to see done to it.

I want to implement the tabbed pane into a screen here at work but the 
current implementation has a number of shortcomings. First off, there's 
currently no mechanism to style the widget except through the __theme__ 
system. We have fixed this by implementing CSS theming capability. The 
CSS names we've chosen for now are:

TabbedPane-container-div
TabbedPane-table
TabbedPane-content-row
TabbedPane-content-cell
TabbedPane-content-div
TabbedPane-tab
TabbedPane-tab-mouseOver

Next item. There is no mechanism to have the widget automatically switch 
to the next tab other than by clicking on it. I would like to implement 
the capability so that when you 'blur' off the last 
input/button/select/textarea element on the pane, it automatically makes 
visible the next pane in the tab order. This would be controlled by a 
new autoSwitch='true'||'false' attribute on the inline ctor for the 
widget itself (ie. not the pane widgets). There would also be three 
other optional attributes called 'firstElement', 'lastElement' and 
'nextTab.' These are all fairly obvious names and would behave as follows.

If you have specified autoSwitch='true' but have not specified the other 
three attributes, the tabbed_pane widget will auto determine (via a best 
guess) what all of these values are by parsing the child elements of the 
pane and looking for first and last input/select/& textarea. Then, when 
you blur off this element, the widget will auto tab to the next content 
pane. The idea for having these values as attributes is so you can 
statically define them for performance reasons and because it is 
possible that you might not actually want to tab to the next pane in the 
list (you may want to jump from pane 1 to pane 3 for instance). Also, if 
you are blurring backwards off the first element in the pane, it will go 
to the pane from which you tabbed to get to the current pane.

Also, the current tabbed_pane widget doesn't play nice when used in 
forms. It seems as though it was intended as a display only mechanism. I 
would like to chance it's current behavior which is to actually sub out 
the content of the pane (it basically does DOM node swapping) for a 
different one, to a system where the visibility of a pane is determined 
by a CSS style of hidden / visible = false, whatever it is. This would 
have the benefit that the form fields would actually exist in the DOM 
then when a submit was done. My usage of it wouldn't be for quite this 
implementation, but is similar enough in that I require all the html 
elements to be 'visible' within the DOM so I can do my javascrip RMI 
data submission of all the html element values.

Hmm... I get the feeling I'm forgetting somthing here... if lightning 
strikes, I'll post again.

Thoughts?

--Michael


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org