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

[Andy Schwartz]

Jim Driscoll wrote On 5/25/2009 2:23 AM ET:
> Well, it can't be a div anyway, since that changes the layout from 
> inline to block.
>
> I guess we could wrap every single component in a span, but that's 
> quite a bit of extra characters for what is going to be rarely necessary.

Actually, we cannot do this, since the composite component 
implementation may include block-level content.  Nesting this within 
inline content (eg. a <div> nested within a <span>) would result in 
invalid html.  The composite component author needs to specify the 
appropriate type of root element for their implementation.
 
> > 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.
>
> But they don't require it every time.
>
> They only require it if they want to update the entire component via 
> ajax by the component name (or, more sadly, @this), rather than 
> subportions of the component or the entire form, which I imagine would 
> be a more common case.  and if you want to render the entire composite 
> component with ajax, then yes, you just add <span blah></span> - or 
> div, if you want the component to be block mode.

Right.  This seems like it will be common enough that we should make 
some effort to get the word out how to address this issue (ie. doc this 
as a best practice).  We can evaluate whether JSF can provide a more 
elegant solution in 2.1.


> 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 can't imagine that that confusion would last longer than the very 
> first example, would it?  For me, it didn't get past the first time I 
> used view source.   I got as far as "oh, it doesn't output anything 
> unless I tell it to", and that wasn't hard to understand.

Sure, but as I've heard Dan mention in some thread recently (or was it 
this thread?)... it is often these subtle little issues that cause 
frustration and disillusionment with the platform, so if we can help to 
clarify this in some way that will help our end users avoid the issue in 
the first place, it is a good thing.


>
>
> Still, that said, I think that this requires documentation - but 
> goodness knows that that's not the only part that needs more 
> documentation.    And for this, I really do think that a simple 
> statement of best practice would suffice.

Yeah, I was thinking that same.  Though not sure where exactly this 
should be documented in order to increase the chance the our users will 
find this information.

Andy