You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Renzo Tomaselli <re...@tecnotp.it> on 2007/02/23 11:17:20 UTC
[Trinidad] pattern for nested identifiers
Hi, in a page of mine I replaced a f:form by a tr:form, because of the
well known issue with Tomahawk jscookmenu missing a hidden field.
As a side effect - I noticed a change concerning the way nested
identifiers are generated.
If I put:
<f:form id = "browser">
<tr:commandButton id="double" ...
then the generated if for this button is "browser:double".
If I replace the form tag by:
<tr:form id = "browser">
then the generated button id is simply "browser".
Needlessy to say, this harmless replacement invalidates an entire bunch
of js code, expecting the combined ids.
Is nesting parameter-driven anywhere ? Any comment ?
Thanks -- Renzo
Re: [Trinidad] pattern for nested identifiers
Posted by Renzo Tomaselli <re...@tecnotp.it>.
Actually both. Tomahawk and Trinidad are - almost - lonely players with
JSF. At least they are widely used. It appears strange to me that
neither one talks
about which components are naming containers or not, if there is a
chance that enclosing components - such as a form - behave differently.
Nor - AFAIK - JSF is mandatory about rules for naming containers.
The real problem is about js invalidation. Perhaps it is limited to
tr:form, so that there is no problem at all.
-- Renzo
Adam Winer wrote:
> On 2/25/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
>> Thanks Adam. This explanation leads to another question - somewhat
>> obvious: I never saw any component description stating which is a naming
>> container and which is not. Neither for Tomahawk or for Trinidad or for
>> JSF base components.
>> What is the rationale behind this ?
>
> Do you mean, "What is the rationale behind not having any
> description?" or "What is the rationale behind making something
> a naming container or not?"
>
> -- Adam
>
>>
>> -- Renzo
>>
>> Adam Winer wrote:
>> > tr:form is not a naming container - while h:form is.
>> > For people developing new pages, this is a big
>> > advantage (far easier than setting forceId everywhere).
>> >
>> > If you want to preserve this old JS, then just use:
>> >
>> > <tr:form>
>> > <f:subview id = "browser">
>> > ...
>> > </f:subview>
>> > </tr:form>
>> >
>> > -- Adam
>> >
>> >
>> > On 2/23/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
>> >> Hi, in a page of mine I replaced a f:form by a tr:form, because of
>> the
>> >> well known issue with Tomahawk jscookmenu missing a hidden field.
>> >> As a side effect - I noticed a change concerning the way nested
>> >> identifiers are generated.
>> >> If I put:
>> >>
>> >> <f:form id = "browser">
>> >> <tr:commandButton id="double" ...
>> >>
>> >> then the generated if for this button is "browser:double".
>> >> If I replace the form tag by:
>> >>
>> >> <tr:form id = "browser">
>> >>
>> >> then the generated button id is simply "browser".
>> >> Needlessy to say, this harmless replacement invalidates an entire
>> bunch
>> >> of js code, expecting the combined ids.
>> >> Is nesting parameter-driven anywhere ? Any comment ?
>> >> Thanks -- Renzo
>> >>
>> >
>> >
>>
>
>
Re: [Trinidad] pattern for nested identifiers
Posted by Adam Winer <aw...@gmail.com>.
On 2/25/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
> Thanks Adam. This explanation leads to another question - somewhat
> obvious: I never saw any component description stating which is a naming
> container and which is not. Neither for Tomahawk or for Trinidad or for
> JSF base components.
> What is the rationale behind this ?
Do you mean, "What is the rationale behind not having any
description?" or "What is the rationale behind making something
a naming container or not?"
-- Adam
>
> -- Renzo
>
> Adam Winer wrote:
> > tr:form is not a naming container - while h:form is.
> > For people developing new pages, this is a big
> > advantage (far easier than setting forceId everywhere).
> >
> > If you want to preserve this old JS, then just use:
> >
> > <tr:form>
> > <f:subview id = "browser">
> > ...
> > </f:subview>
> > </tr:form>
> >
> > -- Adam
> >
> >
> > On 2/23/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
> >> Hi, in a page of mine I replaced a f:form by a tr:form, because of the
> >> well known issue with Tomahawk jscookmenu missing a hidden field.
> >> As a side effect - I noticed a change concerning the way nested
> >> identifiers are generated.
> >> If I put:
> >>
> >> <f:form id = "browser">
> >> <tr:commandButton id="double" ...
> >>
> >> then the generated if for this button is "browser:double".
> >> If I replace the form tag by:
> >>
> >> <tr:form id = "browser">
> >>
> >> then the generated button id is simply "browser".
> >> Needlessy to say, this harmless replacement invalidates an entire bunch
> >> of js code, expecting the combined ids.
> >> Is nesting parameter-driven anywhere ? Any comment ?
> >> Thanks -- Renzo
> >>
> >
> >
>
Re: [Trinidad] pattern for nested identifiers
Posted by Renzo Tomaselli <re...@tecnotp.it>.
Thanks Adam. This explanation leads to another question - somewhat
obvious: I never saw any component description stating which is a naming
container and which is not. Neither for Tomahawk or for Trinidad or for
JSF base components.
What is the rationale behind this ?
-- Renzo
Adam Winer wrote:
> tr:form is not a naming container - while h:form is.
> For people developing new pages, this is a big
> advantage (far easier than setting forceId everywhere).
>
> If you want to preserve this old JS, then just use:
>
> <tr:form>
> <f:subview id = "browser">
> ...
> </f:subview>
> </tr:form>
>
> -- Adam
>
>
> On 2/23/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
>> Hi, in a page of mine I replaced a f:form by a tr:form, because of the
>> well known issue with Tomahawk jscookmenu missing a hidden field.
>> As a side effect - I noticed a change concerning the way nested
>> identifiers are generated.
>> If I put:
>>
>> <f:form id = "browser">
>> <tr:commandButton id="double" ...
>>
>> then the generated if for this button is "browser:double".
>> If I replace the form tag by:
>>
>> <tr:form id = "browser">
>>
>> then the generated button id is simply "browser".
>> Needlessy to say, this harmless replacement invalidates an entire bunch
>> of js code, expecting the combined ids.
>> Is nesting parameter-driven anywhere ? Any comment ?
>> Thanks -- Renzo
>>
>
>
Re: [Trinidad] pattern for nested identifiers
Posted by Adam Winer <aw...@gmail.com>.
tr:form is not a naming container - while h:form is.
For people developing new pages, this is a big
advantage (far easier than setting forceId everywhere).
If you want to preserve this old JS, then just use:
<tr:form>
<f:subview id = "browser">
...
</f:subview>
</tr:form>
-- Adam
On 2/23/07, Renzo Tomaselli <re...@tecnotp.it> wrote:
> Hi, in a page of mine I replaced a f:form by a tr:form, because of the
> well known issue with Tomahawk jscookmenu missing a hidden field.
> As a side effect - I noticed a change concerning the way nested
> identifiers are generated.
> If I put:
>
> <f:form id = "browser">
> <tr:commandButton id="double" ...
>
> then the generated if for this button is "browser:double".
> If I replace the form tag by:
>
> <tr:form id = "browser">
>
> then the generated button id is simply "browser".
> Needlessy to say, this harmless replacement invalidates an entire bunch
> of js code, expecting the combined ids.
> Is nesting parameter-driven anywhere ? Any comment ?
> Thanks -- Renzo
>