Re: [jsr-314-open] [ajax] My AI on PartialResponseWriter.
Ah, I get what you're up to now. Yes, this is a valid use case.
However, I really don't like the idea of allowing this fashion of usage,
and would prefer we provide the ability to do that through other means.
Calling encodeAll for another component from within a component that
won't render the result inside itself is a quite different case than
would be allowed in a non-Ajax component, and as such would degrade
ungracefully. There's also the problem of that encouraging a rather
sloppy coding style. And finally, we'll be buffering the output of the
component, which could be problematic from a performance perspective.
But nothing immediately springs to mind as an alternative. I'm sure we
could always add one, but maybe that usage really is the simplest way -
let me think about it, and dink around with the code a bit.
I'd actually wanted to allow startUpdate for the purpose of modifying
part of the page which isn't directly corresponding to a JSF component -
which is another use case that we must support.
Jim
On 12/10/09 4:32 PM, Ken Paulsen wrote:
Jim Driscoll wrote:
> Thanks for the description - sorry to make you type it out, but you'll
> see why, I think, in the comment below.
>
> On 12/10/09 2:15 PM, Ken Paulsen wrote:
>>
>> Hi Jim,
>>
>> This is what I was imagining as a >1 deep nesting:
>>
>> * PartialViewContextImpl calls writer.startUpdate for componentX
>> * PartialViewContextImpl calls componentX.encodeAll()
>> * componentX calls writer.startUpdate for componentY b/c it knows
>> componentY must change if it changes
>
> So far, so good. But: calling writer.startUpdate doesn't actually call
> componentY.encodeAll(). Is that assumed in your example? When is the
> encode going to be called? And by what means?
No I did not assume startUpdate would call encodeAll().
PartialViewContextImpl calls encodeAll for X. During the encoding of X,
it calls startUpdate/encodeALL/endUpdate for Y, and Y calls
startUpdate/encodeAll/endUpdate for Z. X and Y are assumed to be smart
Ajax-enabled components with known associated components that they
auto-update during PartialRequests.
Thanks!
Ken
>
>> * componentY calls writer.startUpdate on componentZ b/c it knows...
>> * componentY calls writer.endUpdate
>> * componentX calls writer.endUpdate
>> * PartialViewContextImpl calls endUpdate
>>
>> For ordering, I would suggest a depth first traversal (i.e. add the
>> buffered output at the end* call).
>
> Yeah, a method scoped queue would make sense if this use case makes
> sense.
>
> Jim