Re: Proposed tabbed_pane widget changes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 July 2003 1:18 pm, Michael Flanagan wrote:
> 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

Looks great. I'm all for it.

> Next item. There is no mechanism to have the widget automatically
> switch to the next tab other than by clicking on it.

I think that Shift-left and Shift-right keystroke modifiers (or 
something similar but not caught by the browser) might also be useful 
here.

> 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. 

Um, what if I got to a previous element in the same container? Do I 
then still get switched?

I think the intended behvior here is to move to the next tab if I 
tab-through the last input element, not necessarialy if I blur off of 
the last one.

> 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.

Should this be "tabbing backwards through" (as above) instead?

> 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.

I think this makes some sense. Although this brings up the question of 
whether or not all tabs are treated as a single form or multiple 
forms?

> 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.


- -- 
Alex Russell
[email protected]
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/Hu4toV0dQ6uSmkYRAi8AAKDD0CHyjS1MEKZckoRsr7cYry8gywCfV1wF
ySmpvBHAFmaug+Eihf5UyYU=
=uxTp
-----END PGP SIGNATURE-----


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