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:40:45 GMT
Now I see where you are coming from and I agree with you. If so, 
ListEdit certainly has to be renamed.

-Harish

Richard Lewis-Shell wrote:

>I just think that providing a set of components that know nothing about HTML
>and its form semantics is a good thing - the abstraction is stronger, the
>components simpler, and the dependencies one-way.  Simple is better. (IMO)
>
>If you want HTML form handling (incl. rewinding), then use form handling
>components.  Tapestry is not just an HTML framework, and I like the clean
>separation that has been achieved so far...
>
>R
>
>-----Original Message-----
>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
>Sent: Thursday, 14 August 2003 8:12 a.m.
>To: Tapestry development
>Subject: Re: [DISCUSS] Rewinding conditionals
>
>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
>>
>>
>> 
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>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