You shouldn't have to use <f:subview> in those cases;  somehow,
<f:subview> got tangled up with includes, but its real purpose in
life is being a NamingContainer, so the combo of "gimme an
<f:subview>, but don't prepend its id" doesn't make sense.
Prepending IDs is what <f:subview> is for.

-- Adam


On Apr 1, 2005 2:02 PM, Heath Borders <[EMAIL PROTECTED]> wrote:
> Sorry, I meant appending, not prepending.
> 
> As far as not allowing turning off all parent NamingContainer
> prependings, I'm not sure that the disambiguation from <f:subview> is
> acceptable, especially in cases where you are developing a large
> application using Tiles.
> 
> In our case, we have our pages nested inside multiple subviews that
> wrap various abstractions needed by different pages.  However, the
> content dropped into those Tiles needn't ever change.  If there is no
> way to obliterate all prepended ids, it makes it nearly impossible to
> develop code inside a page that has no knowledge of its parent subview
> structure.
> 
> On Apr 1, 2005 3:47 PM, Adam Winer <[EMAIL PROTECTED]> wrote:
> > Prepending a row-number isn't that ideal, since that necessarily
> > violates the naming rules for IDs, which must start with letters,
> > an underscore, or a colon:
> >
> >  http://www.xml.com/axml/target.html#NT-Name
> >
> > ... but the decision (and my opinion) was that turning off *all*
> > prepending with one flag is simply too blunt, and didn't give
> > you a way to say something like "look, I'm sick of that form
> > ID getting in the way, but I can accept disambiguation from
> > <f:subview>".
> >
> > -- Adam
> >
> > On Apr 1, 2005 1:39 PM, Heath Borders <[EMAIL PROTECTED]> wrote:
> > > But what about other NamingContainers that are not UIForms, like
> > > UIDatas?  The way that forceId works is ideal with a UIData (it
> > > prepends the row-number onto the id).
> > >
> > > On Apr 1, 2005 3:35 PM, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > > Hi Martin!
> > > >
> > > > ADF Faces resolves this by virtue of its UIXForm component not
> > > > extending UIForm (or even UIComponentBase - we have our own
> > > > UIXComponentBase class), and therefore it does not
> > > > implement NamingContainer.
> > > >
> > > > BTW, the subject of "forceId" was raised on the EG a couple
> > > > weeks back, and we went a slightly different way to solve this
> > > > in 1.2:  <h:form> will have a "prependId" flag that can be set
> > > > to false.
> > > >
> > > > -- Adam Winer
> > > >
> > > > On Apr 1, 2005 11:07 AM, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > > > > So now that I know there is at least one ADF Faces person on this 
> > > > > list (Hi
> > > > > Adam! :) ...
> > > > >
> > > > > I'd be very interested in hearing how ADF Faces resolves the issues 
> > > > > that
> > > > > were discussed here a while ago with respect to JSF generating the 
> > > > > IDs for
> > > > > components, making it difficult to use getElementById(), and 
> > > > > culminating
> > > > > in the addition of the 'forceId' attribute to MyFaces. Is that 
> > > > > something
> > > > > the ADF Faces team might be able to share with us?
> > > > >
> > > > > TIA!
> > > > >
> > > > > --
> > > > > Martin Cooper
> > > > >
> > > >
> > >
> > > --
> > > -Heath Borders-Wing
> > > [EMAIL PROTECTED]
> > >
> >
> 
> --
> -Heath Borders-Wing
> [EMAIL PROTECTED]
>

Reply via email to