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:58:36 GMT
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
> >
> >
> >  
> >
> 


Mime
View raw message