incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] pattern for nested identifiers
Date Thu, 01 Mar 2007 03:25:19 GMT
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