incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <renzo.tomase...@tecnotp.it>
Subject Re: [Trinidad] pattern for nested identifiers
Date Thu, 01 Mar 2007 08:35:16 GMT
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 <renzo.tomaselli@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 <renzo.tomaselli@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
>> >>
>> >
>> >
>>
>
>

Mime
View raw message