Re: Review: Put back marker logic (First iteration)

From: Adam Winer <>
Date: Tue, 17 May 2005 10:44:42 -0700

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

-- Adam 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 <> wrote on 05/17/2005, 06:22:45 PM:
>>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.
>>(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