Re: [jsr-314-open] Ajax rendering of components among compositions?
Hey Dan -
Dan Allen wrote On 5/24/2009 11:32 PM ET:
I still don't understand why the composite component is not
acting
like a naming container. I mean, if I assign an id to the composite
component:
<p:edit id="username"/>
Then it just seems wrong to me that it isn't rendered in the output.
However, if we are saying that the composite component must have:
<div id="#{cc.clientId}">
...
</div>
I suspect that this isn't so much a composite component limitation so
much as a general isssue with Facelets handling of static
(non-component) content. I haven't tested this out yet, but I am
guessing that the following trivial example displays the same behavior:
<f:subview id="namingContainer">
<div id="foo"></div>
</f:subview>
Facelets (actually, JSP too) will end up treating the <div> element as
raw HTML content - and as such will simply blast this content out rather
than creating a UIComponent that can participate in naming container id
manipulation.
On the other hand, if you've got:
<f:subview id="namingContainer">
<h:panelGroup id="foo"/>
</f:subview>
Or a composite component:
<p:edit id="username"/>
Containing:
<h:panelGroup id="foo"/>
Then naming container id resolution comes into play.
I don't know that there is anything wrong with this behavior in general,
though I do agree with your concern that composite component authors are
going to have no clue how best to specify the id in their rendered content.
(or something of the sort), then we need to highlight this point in
big *bold* letters.
Yep.
Otherwise, every time a newcomer creates a composite component that
he/she wants to update with Ajax, they are going to going through this
trial and error lesson.
I agree. I am not sure exactly how to go about improving this situation
in 2.1, but for 2.0 the technique that you described needs to be
encouraged as a best practice.
Andy
-Dan