I agree that, at the moment, the most important is to concentrate on T5 RC finalization. However, I think that T5-SWF integration shouldn't be underestimated because it could be wise marketing move. Spring users community is much bigger than Tapestry community and for Spring centric developers and managers is SWF framework of first choice. They usually start project with decision that service layer will be based on Spring Framework and application logic flow on SWF. Just then they start looking for the most suitable web framework (frameworks without SWF integration are usually skipped). So, if T5-SWF integration existed more developers would give T5 a try.
On Thu, Oct 16, 2008 at 7:36 AM, Peter Stavrinides < [EMAIL PROTECTED]> wrote: > This is an interesting discussion, but I tend to agree with Howard's view > that Tapestry should be focused towards Tapestry centric applications and > later on integration with web flow and others... a side note on > compatibility, Tapestry is such a progressive platform yet it has not been > tested officially with Java 6? I know it works, as I have been using it for > over a year now, so why the delay in moving to JDK 6? > > cheers > Peter > ----- Original Message ----- > From: "Howard Lewis Ship" <[EMAIL PROTECTED]> > To: "Tapestry users" <users@tapestry.apache.org> > Sent: Wednesday, 15 October, 2008 8:23:00 PM GMT +02:00 Athens, Beirut, > Bucharest, Istanbul > Subject: Re: Tapestry 5 Integration with Spring Web Flow 2? > > No, actually, Keith Donald and I have discussed this repeatedly, and I > think it would be a good thing to add in 5.1. We also have ideas > about how to make Spring/Tapestry IoC integration better and more > symmetric. > > We're stumbling one one thing, Keith doesn't know much Tapestry and > sees it as a view technology; he wants SWF to "run the show". He does > have a point in terms of legacy apps that want to be implemented > partly in Struts/JSF/Craptaculous and partly in T5. > > I'm more concerned with new projects that are more purely T5 and I > want T5 to be in the driver's seat; my vision for truly seamless SWF > integration requires it. > > Right now I'm most concerned with getting a stable, useful 5.0 release > out the door. > > On Wed, Oct 15, 2008 at 9:03 AM, John Jimmy Dondapati > <[EMAIL PROTECTED]> wrote: > > I got some answers here supporting what Thiago and Geoff ranted about. > > http://tapestry.apache.org/tapestry5/tapestry-ioc/ > > > > Quote : > > > > " *The core concept of Tapestry IoC is that the Java language itself is > the > > easiest and most succinct way to describe object creation and method > > invocation. Any approximation in XML is ultimately more verbose and > > unwieldy. As the > > examples< > http://tapestry.apache.org/tapestry5/tapestry-ioc/service.html#injection > >show, > > a small amount of Java code and a handful of naming conventions and > > annotations is far simpler and easier than a big chunk of XML.* > > > > *In addition, moving from XML to Java code encourages testing; you can > unit > > test the service builder methods of your module builder class, but you > can't > > realistically unit test an XML descriptor. " > > * > > > > Looks like the fundamental idea of Tapestry is moving away from xml and > > putting the IOC into code. I guess, same goes for navigation. > > > > So, I guess there will not be a Spring Web Flow integration from Tapestry > > side unless Spring takes the effort. > > > > On Wed, Oct 15, 2008 at 11:54 AM, John Jimmy Dondapati < > [EMAIL PROTECTED] > >> wrote: > > > >> > >> > >> On Wed, Oct 15, 2008 at 9:21 AM, Lubor Gajda <[EMAIL PROTECTED] > >wrote: > >> > >>> > 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. > >>> > >> > >> Couldnt agree more. In fact thats the other main reason that made us go > for > >> JSF + SWF combo apart from the client requirement to specify navigation > >> outside the code. > >> > >> > >> > >>> > >>> 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] > >>> > > >>> > > >>> > >> > >> > >> > >> -- > >> Cheers, > >> John > >> > > > > > > > > -- > > Cheers, > > John > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > 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] > >
