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]
