Re: [Trinidad] pattern for nested identifiers

[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

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