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