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 21:12:55 GMT
You would not believe, I was thinking of the same names. I kinda like 
the Formeach!

-Harish

Howard M. Lewis Ship wrote:

>Lots of stuff in Tapestry should be renamed.  Sorry, folks!
>
>ListEdit has a counter-intuitive name; Formeach (get it?) would be better, or FormLoop,
perhaps.
>
>The book has a large section about using ListEdit and ListEditMap together to streamline
the whole
>process.  "ListEditMap?" you say?  I put this together while working on the book because
describing
>all the stuff involved to use ListEdit succesfully was a mess.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>
>
>
>  
>
>>-----Original Message-----
>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
>>Sent: Wednesday, August 13, 2003 4:41 PM
>>To: Tapestry development
>>Subject: Re: [DISCUSS] Rewinding conditionals
>>
>>
>>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
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>---------------------------------------------------------------------
>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