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 20:12:29 GMT
Could you please share your reasoning? I think the rewind should be as 
transparent as possible to the user as it trips a lot of the users.

-Harish

Richard Lewis-Shell wrote:

>I would prefer to keep logic specific to HTML form rewinding separated from
>the general purpose components.  Clarifying the names of components seems
>like a good idea. I guess that means option a + b for me...
>
>R
>
>-----Original Message-----
>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
>Sent: Thursday, 14 August 2003 2:25 a.m.
>To: Tapestry development
>Subject: Re: [DISCUSS] Rewinding conditionals
>
>Hi,
>
>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.
>
>Thanks
>Harish
>
>
>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
>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
>>
>>
>>
>> 
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message