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 Sun, 25 Feb 2007 16:15:32 GMT
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 <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