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

[Jim Driscoll]

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.  And 
I do recall having a number of arguments about outputting even a few 
extra characters - it makes performance much slower.   So I'd expect 
putting <span id="#{cc.clientId}"></span> on every component made this 
way, may raise objections.  While I don't have strong objections, it 
really doesn't seem necessary to me.

On 5/24/09 8:32 PM, Dan Allen wrote:
> 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.


It doesn't seem wrong to me.    So, we both seem to operating on 
impressions.  Let me try to explain why my impression is what it is:

Let's say for the sake of argument that you wrote a component the old 
fashioned way - you know, UIComponent.  Let's further say that you did 
not put a wrapping span in that component.  Let's say, in fact, that you 
just said to output "hello world".

Would you then expect that component to output something you didn't tell 
it to output?   Would you expect that component to have a wrapping span? 
  If not, why not?    Or is your argument that because we've made the 
composite components easier, it'll be more common for people to make 
them, and we shouldn't make them keep track of this sort of thing?

I guess I could try to make the argument that sometimes you want a div, 
for a block mode component, and sometimes you'll want a span, but that's 
specious, I guess, since you could always embed a div inside the span - 
it'll make styling with css a touch more awkward, but not too painful. 
But that does raise other issues - since you're now proposing wrapping 
all components with span, what of the other traditional passthrough 
attributes?  Should we pass those through too?

I guess if I wanted to pass those through, I could once again write a 
span, inside the autogenerated span.  Eww.

> However, if we are saying that the composite component must have:
>
> <div id="#{cc.clientId}">
> ...
> </div>
>
> (or something of the sort), then we need to highlight this point in big
> *bold* letters.
 > 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.


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.

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.

I guess I'm arguing against this as an issue primarily because I see the 
current behavior as consistent and not having a special case.  I'm 
worrying about adding a special case in this way, and what kind of 
misery that will lead to further down the road as we have to make 
allowances for all these special autogenerated spans that aren't even 
being used most of the time, as well as having these bloat up the pages 
that they're in.

Jim