[jsr-314-open] Ajax rendering of components among compositions?

[Andy Schwartz]

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
>