tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie Orchard-Hays" <ja...@dang.com>
Subject Re: [DISCUSS] Rewinding conditionals
Date Tue, 12 Aug 2003 15:29:58 GMT
I like c. If it is feasible, it would certainly simplify development and make the component
base smaller. Having a switch in a
component to use client-side or server-side state seems much more desirable than having two
separate components.

----- Original Message ----- 
From: "Mind Bridge" <mindbridgeweb@yahoo.com>
To: <tapestry-dev@jakarta.apache.org>
Sent: Tuesday, August 12, 2003 10:16 AM
Subject: [DISCUSS] Rewinding conditionals

> 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 ago).
> 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.
> Thoughts?
> Best regards,
> -mb

View raw message