Hi Thiago/Geoff, In my opinion centralized flow definition can be quite useful in some circumstances, especially in complex applications. Imagine for instance that you have to analyze/understand application that consists of hundreds of pages and you are not familiar with the code because it was implemented by somebody else. If you are using centralized flow definition it's quite easy because the only thing you have to do is to check your flow definitions and you immediately get an overview what is going on (what view, action and decision states you have in the application, what transitions are possible between those states, how is defined overall application logic flow, how is defined global exception handling, etc.). However, when you are using page based approach your flow definition is scattered across whole application and you have to edit and analyze all those hundreds of pages to gather all information pieces, what is much more time consuming and less user friendly approach.
Moreover, Spring Web Flow is not only about flow definition. Its another important feature is that it introduces new object scopes that allow you easily share objects between pages in the same flow/conversation. How would you implement this in Tapestry? Would you use ASO objects and manually clean them when flow/conversation ends? Or would you just use 'bucket brigade pattern' and manually set the object to following page instance? Each of these two approaches is less productive and less user friendly than directly using flow/conversation scope. I completely agree that XML programming is nonsense, but XML flow definition is not the only choice. You can use java based flow definitions or eventually create your own custom flow builders (for instance grails framework uses SWF with groovy based flow builder). Tapestry is by its concept strictly page based framework and it doesn't support grouping pages to flows/conversations. I think that this would be good opportunity to start discussion in Tapestry community about advantages/disadvantages of flow/conversation concept to clarify if it would be useful to introduce this concept in future Tapestry releases or not. So, what do you think? Regards Lubor On Wed, Oct 15, 2008 at 11:38 AM, Geoff Callender < [EMAIL PROTECTED]> wrote: > Good rant. I completely agree. > > > On 15/10/2008, at 12:31 PM, Thiago H. de Paula Figueiredo wrote: > > Em Tue, 14 Oct 2008 20:51:10 -0300, John Jimmy Dondapati < >> [EMAIL PROTECTED]> escreveu: >> >> I am sorry if this has already been asked but is there anyway to >>> integrate Spring Web Flow 2.x with Tapestry 5.x? >>> >> >> Nabble has a very good archive of this mailing list: >> http://www.nabble.com/Tapestry---User-f340.html >> >> Reasons : >>> 1. I like the way SWF organizes the flow outside the code. >>> 2. please add your own reasons. >>> >> >> <rant> >> I don't really get why would I like keep the flow outside the code. Flow >> is application logic, and the best place to write logic, in my humble >> opinion, is code. Disclaimer: I am a former, very disgruntled Struts user. >> One of the reasons I have to not use JSF is that faces-config.xml is >> struts-config.xml (that is a pain) with some tags renamed. I hope XML >> programming dies quickly. >> </rant> >> >> When learning Tapestry, I strongly suggest you to not try to find how you >> can map some other framework concept or feature into Tapestry: try to learn >> its concepts. Think that every page is an ordinary object and that pages can >> interact with other just like objects interact with other objects. >> >> -- >> Thiago H. de Paula Figueiredo >> Independent Java consultant, developer, and instructor >> Consultor, desenvolvedor e instrutor em Java >> http://www.arsmachina.com.br/thiago >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
