Don, Thanks for the prompt reply. Comments inline:
> The difference as I see it is struts-chain benefits > the controller > process, in other words, the process that is global > to all requests. > The actual handling of the request, the "action", is > still one class. > Cocoon, as I understand it, works the other way > around with the global > request processing fixed, but a lot of flexibility > at the action > level. I feel having flexibility at the action level to be more desireable for performance reasons and fine-grained control over particular requests. For example, imagine I have a workflow component that evaluates if a given request is involved in a workflow. If this set of requests pertains only to certain URLs, why should every request have to go through this command? The same would apply for a Authentication command, a controller managing application integration, and so on... On the other hand, having a global view is already achievable via the Servlet's filter model. Perhaps the intention is not to rely on this implementaion specific? >Even then, Cocoon focuses more on the view > through the SAX > pipelines so it has a more robust view processing > model enabled > through SAX. I still think combining Struts and > Cocoon is the best > solution to get the best of both worlds - Struts for > controller > processing, Cocoon for view rendering. Throw in > Struts Flow > (http://struts.sf.net/flow) and you can still use > continuations-based > flowscript. I agree, although I am skeptical of the javascript approach. I have read that the performance is dramatically less and that the changes to the Rhino engine exist as a fork. Again, not sure if this is FUD, but it is a concern. My preference would be to output XML from Struts and pass it to a Coocon pipeline for processing the view. I have more research to do obviously and appreciate any feedback. That's about it, thanks. Julian > That is, at least, how I understand it today. I > know Ted was doing > some work in writing apps where there was no concept > of an "action", > but the action implementation simply looked up and > executed a chain > itself. As we get chain into Struts, we will see a > number of > possibilities open up that may redefine how we think > of actions. If > you have any ideas of a better way to use struts > chain, post some code > and/or thoughts. > > Don > > > On Wed, 10 Nov 2004 08:37:36 -0800 (PST), Julian > <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I am an avid user of Cocoon and really love the > > sitemap concept. I am wondering if the current > > direction of the struts-chain component is to only > > manage action chaining. IMHO, Struts is great > as a > > controller, but not nec. for the View in the MVC > > world. In other words, will it be possible to > have an > > analogous process to Coccon pipelines in Struts or > is > > it best to use the Cocoon plugin for "view" > > processing? I really enjoy how the seperation of > > concerns has been achieved with Cocoon, but for > > similar reasons, I cannot use Cocoon's Forms > paradigm > > or Java Server Faces yet. > > > > Thanks in advance, > > Julian > > > > ===== > > Live simply so others may simply live. > > > > -Ghandi > > > > Pluralitas non est ponenda sine neccesitate. > > "Entities should not be multiplied unneccesarily" > > > > -William of Occam > > > > __________________________________ > > Do you Yahoo!? > > Check out the new Yahoo! Front Page. > > www.yahoo.com > > > > > --------------------------------------------------------------------- > > 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] > > ===== Live simply so others may simply live. -Ghandi Pluralitas non est ponenda sine neccesitate. "Entities should not be multiplied unneccesarily" -William of Occam __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
