Can someone please enlighten me as to the current thinking is on integrating Struts with Cocoon:
- there seems to be certain amount of thought/discussion that points toward reinventing the wheel as far as Cocoon's outstanding XML functionality is concerned - Cocoon also seems somewhat to have started encroaching on areas that were previously not part of its scope, i.e. not directly XML related... at the very least there is a close analogy between Cocoon pipelines and the (and eagerly anticipated!) workflow functionality in the next version of Struts. The Cocoon sitemap and Struts action mappings config file also exhibit similar ideas, and the ideas of both combined together could provide a very powerful framework for building apps. Is this overlap occurring or am I just been seeing things! Forgive me if this discussion has already taken place, or I've got the wrong end of the stick! It's true that there are sometimes different perspectives in each project's take on the same ideas, and sometimes the duplication of work may make sense, but I think there is probably more common ground than differences. It's just that there there are a number of amazing projects under various parts of the Apache umbrella that I've used use together to build apps, but recently it seems that sometimes they are not aware of obvious overlap with other Apache projects... I'd just rather continue discounting inferior expensive commercial "solutions" to the benefit of using the great work going on in the projects at Apache XML, Jakarta etc rather than have to trade off between two different implementations of the similar functionality in two Apache projects. Anyway, I'd be interested in hearing thoughts... Kosh > -----Original Message----- > From: husted > Sent: 04 February 2002 19:51 > To: struts-user > Cc: husted > Subject: Re: Extending Struts (was: Boost Struts with XSLT and XML - > JavaWorld.com) > > > "Couball, James" wrote: > > > > I have been lurking for a couple of months now and have > seen many useful > > extensions to the Struts framework. I am curious to > understand what thought > > has gone into better understand how Struts can be extended > in common ways > > such that: > > > > (1) Extensions are an add-on/plug-in rather than a rewrite > of the Struts > > classes. > > Craig and Oleg are doing some work along those lines via the Commons > Services component > > http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/services/ > > > > > > > > And > > > > (2) non-overlapping extensions are compatible. For > example, wouldn't expect > > Velocity and XSLT extensions to work together but might > expect different > > classes of extensions to work together. > > I believe both of these would be. The model is that the ActionServlet > forwards the request to another servlet (via the container). > The second > servlet then finishes the response cycle, building on what the Action > and ActionServlet started. So, you could use a Velocity > template in one > requesst, and XLST document the next, and then back to JSPs. > > > > > Can the types of extensions be classified? For example, > the XSLT extension > > talked about in the JavaWorld article could be a "View" extension. > > > > Should the framework be separated out into "core" and > "extension" pieces? > > For example, maybe the custom taglibs should be considered > part of the JSP > > Extension. And the JSP Extension considered a "View" > extension that follows > > certain rules that other View extensions (such as Velocity > and XSLT) must > > follow. > > Yes. At some point, I'd like to get the taglibs moved out into a > seperate JAR to help clarify this point. This would be slightly more > important if more people where using alternative presentation devices > and didn't need the JSP tags at all. But right now, we are all still > recovering from suddenly needing so many Commons JARs :o) > > -Ted. > > > > > Thank you, > > James. > > > > -----Original Message----- > > From: Ted Husted [mailto:[EMAIL PROTECTED]] > > Sent: Monday, February 04, 2002 9:51 AM > > To: Struts Users Mailing List > > Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com > > > > Vaughan Jackson wrote: > > > > > > A couple of naive questions. > > > > > > 1. Given that the authors of the article mention that the > > > Cocoon framework uses XML and XSLT to generate HTML > > > (among other formats), I assume their motivation > > > for using Struts is to gain the MVC framework. Is this > > > correct? Does Velocity also have the same deficiency > > > compared with Struts? > > > > It's said that Velocity enforces MVC better than JSPs. > > > > > 2. Is there any possibility that something like this > > > may become a formal extension to Struts? > > > > Definately. > > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > > -- Java Web Development with Struts. > > -- Tel +1 585 737-3463. > > -- Web http://www.husted.com/struts/ > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
