> Don't forget you can add new object scopes to Tapestry. The main problem here is not definition of conversation scope, but specification of conversation boundaries (when the conversation should start and when it should end and release all objects associated with conversation scope). This mechanism should be as simple and user friendly as possible (all third party implementations I've seen so far are quite verbose in this point).
> It doesn't support this feature out-of-the-box, but it was built in such a flexible and intelligent way that this can be added as an add-on > package without rewriting Tapestry itself. You could use page class transformations to do that, for example. I agree that Tapestry is amazingly flexible framework that allows you modify it's internal behaviour if you need it. However, I also think that conversation support is so common requirement (each nontrivial web application needs it) that it should be supported out-of-the-box. On Wed, Oct 15, 2008 at 1:30 PM, Thiago H. de Paula Figueiredo < [EMAIL PROTECTED]> wrote: > Em Wed, 15 Oct 2008 08:51:33 -0300, Lubor Gajda <[EMAIL PROTECTED]> > escreveu: > > Hi Thiago/Geoff, >> > > Hi! > > 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. >> > > There's always the possibility of writing an analyzer using JavaCC or ANTLR > or even as a Tapestry service that does what you're describing by looking at > @InjectPage annotations. It wouldn't be as complete as a SWF configuration, > but I think it would cover most situations. ;) > > 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 would use an ASO and clean up manually. > > Don't forget you can add new object scopes to Tapestry. This has been done > before, even with conversation scope, even not using Seam or SWF: > http://www.nabble.com/T5%3A-Persistence-pains-tt17027697.html#a17080018. > > Looking at this list archives, some people were trying to integerate Seam > into Tapestry to provide what you're describing here (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). >> > > That's nice. I use Spring, but with JavaConfig, so I almost don't have to > write XML. > > Tapestry is by its concept strictly page based framework and it doesn't >> support grouping pages to flows/conversations. >> > > It doesn't support this feature out-of-the-box, but it was built in such a > flexible and intelligent way that this can be added as an add-on package > without rewriting Tapestry itself. You could use page class transformations > to do that, for example. > > 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? >> > > Discussions are always a good thing. :) > > > -- > 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] > >
