tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [DISCUSS] Rewinding conditionals
Date Wed, 13 Aug 2003 20:59:28 GMT
Did'nt I post about this a month or so ago?  I favor options 'a' and 'b'.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Mind Bridge [mailto:mindbridgeweb@yahoo.com] 
> Sent: Tuesday, August 12, 2003 10:16 AM
> To: tapestry-dev@jakarta.apache.org
> 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
> 
>  
> 


Mime
View raw message