You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Sandor Irlanda <ty...@tiger.tigra.hu> on 2004/10/30 11:54:20 UTC
Re: tabindex
On Fri, 29 Oct 2004 10:30:27 -0400, Erik Hatcher
<er...@ehatchersolutions.com> wrote:
> Sure. Informal parameters should pass right through.
>
> <input jwcid="@TextField" value="ognl:value" tabindex="5"/>
>
It is not that easy though.
Normally you wanna have composite components on the page.
If a component can be used on diferent pages multiple times, at least the
tabindex should come from a binding.
But also as they should behave as a blackbox - you cannot foretell how
many tab-capable form component will be rendered by them.
So let's say we have an address and a phonelist component rendered in this
order, but it is required that the phone should get focus first.
This means in the address component you have no idea how many components
will precede the first field of the address in the taborder.
I am really interested in getting a good idea how it should be done.
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: tabindex
Posted by Andreas Pardeike <an...@pardeike.net>.
Sandor,
An alternative idea would also use Javascript but would totally stay
away from the tabidex="" property. Instead, one could define a
"tab-successor"
for each UI element. Then, custom JS attached to the element could
capture
the TAB key and (after blocking the event cross browser) move the focus
to
the successor UI element. This would require a way to define a
tab-successor
in the component which isn't easy.
At least, it's a different approach and would also work for browsers
that don't
support the tabindex argument.
Andreas Pardeike
On 30 okt 2004, at 15.45, Sandor Irlanda wrote:
> On Sat, 30 Oct 2004, Andreas Pardeike wrote:
>
>> I simple approach would be to first visualise the component tree of a
>> page:
>>
>> L1 PAGE
>> / \
>> / \
>> L2 C1 C2
>> / \ / \
>> L3 C3 C4 C5 C6
>>
>> and then assign priorities for each component level, i.e.:
>>
>> L1 PAGE
>> / \
>> / \
>> L2 2 1
>> / \ / \
>> L3 1 2 2 1
>>
>> which would then expand to
>>
>> C3 = 21
>> C4 = 22
>> C5 = 12
>> C6 = 11
>>
> This was my first idea too, but:
>
> - Component tree is not balanced this way, and actually you might not
> know
> how deep is a branch (if components are blackboxes)
> - What is the scale that is used to generate the numbers? It should be
> the
> maximum of subcomponents of a node. Even if the components are not
> treated
> as blackboxes, you cannot forecast the number of components in a loop.
>
> ----------------------------
> Let me think...
>
> I believe some delegate should be used to collect the controls that
> have
> tabindex, and an initializier script should be generated, that sets the
> taborder property of the controls from JS.
> Priorizing the nodes as you have done is a good idea, but the number
> should not be concatenated, but collected in a vector. These vectors
> will
> define a lexgraph ordering when the init script is generated.
>
> Ye. I think it would work...
> But it is a bit complex and uses scripting. Any better idea?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: tabindex
Posted by Sandor Irlanda <ty...@tiger.tigra.hu>.
On Sat, 30 Oct 2004, Andreas Pardeike wrote:
> I simple approach would be to first visualise the component tree of a
> page:
>
> L1 PAGE
> / \
> / \
> L2 C1 C2
> / \ / \
> L3 C3 C4 C5 C6
>
> and then assign priorities for each component level, i.e.:
>
> L1 PAGE
> / \
> / \
> L2 2 1
> / \ / \
> L3 1 2 2 1
>
> which would then expand to
>
> C3 = 21
> C4 = 22
> C5 = 12
> C6 = 11
>
This was my first idea too, but:
- Component tree is not balanced this way, and actually you might not know
how deep is a branch (if components are blackboxes)
- What is the scale that is used to generate the numbers? It should be the
maximum of subcomponents of a node. Even if the components are not treated
as blackboxes, you cannot forecast the number of components in a loop.
----------------------------
Let me think...
I believe some delegate should be used to collect the controls that have
tabindex, and an initializier script should be generated, that sets the
taborder property of the controls from JS.
Priorizing the nodes as you have done is a good idea, but the number
should not be concatenated, but collected in a vector. These vectors will
define a lexgraph ordering when the init script is generated.
Ye. I think it would work...
But it is a bit complex and uses scripting. Any better idea?
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: tabindex
Posted by Andreas Pardeike <an...@pardeike.net>.
On 30 okt 2004, at 11.54, Sandor Irlanda wrote:
> It is not that easy though.
> Normally you wanna have composite components on the page.
> If a component can be used on diferent pages multiple times, at least
> the
> tabindex should come from a binding.
> But also as they should behave as a blackbox - you cannot foretell how
> many tab-capable form component will be rendered by them.
> So let's say we have an address and a phonelist component rendered in
> this
> order, but it is required that the phone should get focus first.
> This means in the address component you have no idea how many
> components
> will precede the first field of the address in the taborder.
>
> I am really interested in getting a good idea how it should be done.
I simple approach would be to first visualise the component tree of a
page:
L1 PAGE
/ \
/ \
L2 C1 C2
/ \ / \
L3 C3 C4 C5 C6
and then assign priorities for each component level, i.e.:
L1 PAGE
/ \
/ \
L2 2 1
/ \ / \
L3 1 2 2 1
which would then expand to
C3 = 21
C4 = 22
C5 = 12
C6 = 11
which would then determine the tabindex. All it would need is to have a
tabindex
on each component level and have each component append the parents
tabindex as
a prefix. In your example above, one would specify if the address list
gets '2'
and the phone list gets '1' (because the address list should go last.
Inside each
component the elements would get a tabindex corresponding to their
required order.
In the final output, all fields would have their correct tabindex
values so the
grouping comes first and then the order inside the grouping.
I leave the implementation details to the experts but I guess it would
include
subclassing BaseComponent...
Andreas Pardeike
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org