> 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".
> I'm more concerned with new projects that are more purely T5 and I > want T5 to be in the driver's seat; This is exactly the issue I came across when I was experimenting with T5-SWF integration. SWF, especially in version 2.x, is trying to be universal controller lying between views (page templates) and backed beans (page classes) and controlling all their communication (including data binding, type coercion, ajax support, validations, etc.). This is maybe useful for frameworks such as Struts, JSF or Spring MVC where their internal controllers are quite pathetic compared to SWF. However, Tapestry is so advanced framework that it wouldn't make any sense to replace its internal controller and event mechanism by SWF (actually it would be Tapestry degradation). Therefore I absolutely agree that the only rational solution for T5-SWF integration is to base it at concept that SWF should complement Tapestry and not vice versa (SWF should be used only to provide services that are not provided by tapestry itself, e.g. flow definition and providing flow related object scopes). To avoid this conceptual mismatch, in my T5-SWF integration prototype, I decided that SWF won't participate in communication between page templates and page classes, but instead it will wrap Tapestry layer to preserve its internal integrity. To achieve this I had to split traditional SWF flow controller into two parts: 1. First part is executed as soon as we enter Tapestry layer. This part is implemented as Tapestry HttpServletRequestFilter and its responsibility is to acquire flow execution key from request and create flow execution context. We need to create the flow execution context at this level because it provides us access to flow scoped objects in page classes. 2. Second part is integrated with Tapestry event framework and allows us to process Tapestry events as web-flow events (if they weren't previously handled by a page class). This integration with existing Tapestry event mechanism is useful because we don't have to create SWF specific components to signal web-flow events and we can simply reuse existing components and directly handle Tapestry events as web-flow events. Another issue that I came across is that SWF quite heavily depends on Spring Framework. For instance a lot of its internal components are implemented as ApplicationContextAware, what means that they need direct access to Spring application context. So, it will be quite difficult to use SWF integration without Spring Framework (for instance if we decided to implement service layer by Tapestry IOC and not by Spring Framework). However, I'm looking forward to official T5-SWF integration to see how these issues will be addressed. Do we already have any estimations when we could see first results? Thanks Lubor On Wed, Oct 15, 2008 at 6:23 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > 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] > >
