Adding components at render time is kinda nasty, I agree,
and generally poor style. While there are some scenarios
(for composite components, e.g.) where I find adding
components during encodeXyz() invaluable, but I always
mark those components transient (and programatically
recreate them in decode()), so state saving is a moot point.
To consider something a bit less grotesque than adding
components during rendering, how about just setting a
property? I wouldn't call it good style, but it is
occasionally useful, and it raises exactly the same
issues.
-- Adam
jacob_at_hookom.net wrote:
> I consider myself a little more draconian than most, but I would simply
> disallow adding components at render time. I thought TCCI was supposed
> to correct issues correlated to render time state saving?
>
> Do we have a specific use case or request to tie this change to? Does
> this re-enforce some of the discussion pertaining to a phase event
> before rendering in the client side scripting issues Ed/Roger brought
> up?
>
> -- Jacob
>
> Adam Winer <adam.winer_at_oracle.com> wrote on 05/17/2005, 06:22:45 PM:
>
>>Jayashri,
>>
>>A couple of options;
>>
>>(1) Simplify this code, and eliminate the
>>buffering, by stating that components added after the
>>first call to UIForm.encodeEnd() are not guaranteed to be
>>saved? I'm uncomfortable with requiring all ViewHandlers
>>to support dynamically adding components during Render
>>Response - in general, this is bad coding style.
>>
>>Or,
>>
>>(2) Write the state marker immediately - since it certainly
>>won't change - but delay actually saving the state and structure
>>of the UIViewRoot by using an RI-specific PhaseListener
>>that is coupled to the RI StateManager that runs in afterPhase()
>>of Render Response.
>>
>>I prefer #2.
>>
>>-- Adam
>>