tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [DISCUSS] Rewinding conditionals
Date Wed, 13 Aug 2003 14:24:32 GMT

I cannot think of a reason why we would need a new component for added 
behavior to an existing component when it doesn't break any existing 
code. I am all for option 'C'.

On a side note, I know there has been some discussion about adding the 
conditional feature to most components sth. like <img jwcid="@Image" 
image="..." when="ognl:expr"/>. I don't know if its a good idea, but it 
would certainly make the templates more clear and concise. Thought I 
would bring it up for discussion while on the topic.


Mind Bridge wrote:

>Hi all,
>I am writing this message from an internet club, so please excuse any delayed replies.
>As you know, rewinding forms that vary in appearance/content depending on the server-side
state can be tricky, since the rewind must be absolutely identical to the render that generated
the form, or else the form cannot be rewound and a "Stale link" exception is produced.
>One simple way to resolve this issue is to store in the form the information necessary
to rewind the form in an identical manner. In the perfect case, the framework should allow
this to be done automatically. There are four standard components that can cause variations
in the form rendering/rewinding: Foreach, Conditional, RenderBlock, and Delegator. 
>There is already a component equivalent of Foreach that uses that "store in the form"
trick and hence resolves the issue -- ListEdit. It saves the number of iterations and the
items iterates over as Hidden fields in the form, thus it does not depend on the server-side
state being identical during rewind.
>The RenderBlock and Delegator components cannot really benefit much from this approach
(I think), since they often don't need it and when they do, their arguments would likely need
to be initialized in some custom way. (ideas here are welcome though)
>The Conditional component, however, can benefit -- the result of the condition can be
stored as a hidden field and during the rewind it will be clear whether the Conditional should
be rendered or not without reliance on the server-side state. 
>So here are my suggestions (for 3.1, of course):
>a) Create a new standard component, equivalent to Conditional, but for use in forms that
stores the result of the condition in a hidden field similar to ListEdit and acts on it (rather
than on the binding) during rewind. With the addition of this component it will become trival
to have stateless 'varying' forms, I believe (this came up on the user mailing list a while
>b) While the name 'ListEdit' is accurate in a way, I think it does not make clear the
true purpose and capabilities of that component and as a result it remains unknown for the
majority of the new users of the framework. My suggestion: name it and the new component described
above as FormConditional and FormForeach (or sth like that). I believe this should make things
much clearer.
>c) One further step could be to directly merge this capability directly into Conditional
and Foreach, and toggle it via a binding ('true' = store the values into the form). If the
binding is 'true', but the components are not within a form, an exception would occur. This
could conceivably simplify development.
>I am not sure at the moment which is better -- (b) or (c), although (c) looks more compact
to me.
>Best regards,

View raw message