Re: Boost Struts with XSLT and XML - JavaWorld.com
mandag februar 4 2002 kl. 06:43 PM skrev Dustin Aleksiuk: The most common way to generate HTML forms is through the Struts HTML tag library, which is not XML compliant and therefore unusable in conjunction with XSLT. Does this mean that Struts generates HTML and not XHTML? If so, then this should be relatively easy to fix. -- Thorbjørn Ravn Andersen Scandiatransplant, c/o Christian Mondrup 89 49 53 01 http://biobase.dk/~tra -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
I have messed with both Cocoon using XML / XSLT extensively to render views to varying devices and also use the Struts Tiles framework to do the same. I found Cocoon very powerful for static XML documents but as soon as I started trying to hook dynamic content in (forms, JSP's, Servlets, Struts), and NOT through XSP, I was hitting walls daily. However, in Struts I was able to write a custom Tiles FactorySet which looked at the incoming UserAgent and then applied certain rules against that to select the factory. Once that was selected you could write a factory file to have custom JSP's render as the output to actions. I don't explain it all that well but it is actually rather nice. I suggest using this mechanism if you are using Struts and want custom views for each device type. We actually use this user agent mapping factory in every website we develop in our lab. Sean P.S. I am working on getting this submitted back to Jakarta or at least Open Source it ... getting the company to do it isn't all that easy. Matt Raible wrote: Hmmm, I read everyone's posts, and they are somewhat inspiring. I'd like to see examples of using Xalan to get my struts message bundle, or other messag bundles. I'm sure I could spend an hour and figure this out, but if anyone has ready examples, links, send them my way! XForms - I'm excited about these, but I think it'll be awhile before the browser's support them. #3 is probably from my own experience. I spent a week trying to develop a XML/XSL framework using JSPs to emit XML, XSL and the JSTL to do the transformation. My JSPs became very small and nice, but it seemed I was spending a lot of time writing the XSL and trying to get it to work properly. I've had a lot of experience with writing HTML and JSPs, and so I bagged the whole idea and recommended we just use JSP/HTML with Tiles and CSS. I know that my client will get more value from my time with this approach. The reason my client wanted to use XML/XSL was to easily adapt the UI for other devices. I think this is a great reason, but it almost seems simpler to me to separate my HTML client from my WAP client and develop entirely new JSPs for the WAP client. Of course, working with a limited budget and a small development team (1) - there's not much time for learning curve. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
Sean Willson wrote: P.S. I am working on getting this submitted back to Jakarta or at least Open Source it ... getting the company to do it isn't all that easy. I certainly hope you are successful! The Velocity guys are also looking at ways XML/XSLT can be integrated into their applications, in response tot this same article. With a flexible front controller, like, say, Struts, this is not an either/or decisions. You can have your pick of presentation devices, and choose the right tool for each job :) I hear that the Maverick framework plays well with XSLT too. http://mav.sourceforge.net -- 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]
RE: Boost Struts with XSLT and XML - JavaWorld.com
IMHO, internationalization is best done on the tail-end rather than up front. This is a little bit backwards compared to how you're probably used to doing it. My approach would be to scatter xml elements like message key=foo/ throughout your base XML and XSLT transforms, making sure that they pass unmolested to the last transform. The last transform would be a simple stylesheet that included the identity transform and a bunch of templates that look like this: xsl:template match=message[@key='foo']The Foo Message/xsl:template xsl:template match=message[@key='bar']The Bar Message/xsl:template Assuming you have a framework that allows multiple XSLT transforms to be chained together using SAX events, this should actually be quite efficient. About a year ago a friend and I wanted an MVC framework that allowed us to work with XSL. Struts was very tightly coupled to JSP at the time (and arguably still is), so we wrote our own. It is very similar to Struts in many ways, but it is designed around building what the JavaWorld article calls Model 2X. Like Struts, Maverick (our framework) offers an XML sitemap configuration, but unlike Struts: * Each view can have multiple, iterative transformations * You can halt the transformation process at any step and obtain static XML that designers can work with offline. * JavaBeans are automatically domified with an adapter that uses Java reflection to provide a lazily-loaded DOM façade. No need to ever generate or parse text XML. * Designed from the start to be template-language agnostic; you can seamlessly mix and match XSLT, JSP, Velocity, or other views. * View and transform types are pluggable. Not only can you use XSLT transforms, but also DVSL transforms and document transforms that let you use JSP or Velocity to simply wrap the content of previous steps. * Framework will automatically pick from multiple views based on Accept-Language or any other request characteristic, automating internationalization, browser customization, etc. * Actions (called Controllers in Maverick) can work either like Struts Actions (which are singletons) or like WebWork Actions (which are instantiated, used, and thrown away on every request). I'm not just writing this to publicize a competing framework (http://mav.sourceforge.net :-). I am beginning to wonder if maybe there is some potential to merge it with the Struts codebase. It sounds like Struts is being decoupled from JSP and generally moving in the direction of a view-agnostic MVC framework. If a year ago I had suggested making changes to the Struts config file format to accommodate XSL, I think I would have been booed, but I'm not so sure anymore. Any thoughts? Anyone familiar with the Struts config file would probably be amused by seeing the Maverick equivalent. Here is what a Maverick config file looks like for an XSL app (a simple contact-list manager): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/opt-domify/examples/f riendbook-domify/WEB-INF/maverick.xml?rev=1.4content-type=text/vnd.view cvs-markup Here is the exact same app (uses the same Controller aka Action classes) using JSP (with the JSTL ea3 taglib): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/examples/fri endbook-jsp/WEB-INF/maverick.xml?rev=1.5content-type=text/vnd.viewcvs-m arkup Here is the exact same app using Velocity: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/opt-velocity/examples /friendbook-velocity/WEB-INF/maverick.xml?rev=1.2content-type=text/vnd. viewcvs-markup And here is a simple config file which shows using the internationalization feature: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mav/maverick/examples/shu nting-jsp/WEB-INF/maverick.xml?rev=1.3content-type=text/vnd.viewcvs-mar kup Perhaps there merging the two projects is worth investigating? Jeff Schnitzer [EMAIL PROTECTED] Maverick: http://mav.sourceforge.net -Original Message- From: Chappell, Simon P 1. I18N. Agreed. This is a problem. Having gotten used to I18N in my apps, I really have no desire to give it up. According to the book XSLT (by Doug Tidwell, Pub: O'Reilly, Aug 2001) it is possible to extend XSL/XSLT with Java extensions. Could we brave souls not write an XSL/XSLT extension to give us the I18N that we get in struts-powered JSPs? On the other hand, as I re-read this before I hit send, the XSL/XSLT only process the XML that it's given. It's up to what ever generates the XML to perform the I18N. With a struts/XSL/XSLT mix, who's responsibility would it be to provide I18N? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
Jeff Schnitzer wrote: I'm not just writing this to publicize a competing framework (http://mav.sourceforge.net :-). I am beginning to wonder if maybe there is some potential to merge it with the Struts codebase. It sounds like Struts is being decoupled from JSP and generally moving in the direction of a view-agnostic MVC framework. If a year ago I had suggested making changes to the Struts config file format to accommodate XSL, I think I would have been booed, but I'm not so sure anymore. Any thoughts? I think we are all onboard with view agnosticism now. Though, the Struts config file will accomodate any URI, and does not prefer JSPs in anyway whatsoever. Personally, I'm liking the model we're seeing in X2 and VelServlet, where other helper servlets are loaded to handle whatever presentation devices someone might use. I think what we are moving towards is exposing the Struts controller API as a standard object in the request that will be easy to use with any helper servlet or presentation system, including JSTL when it ships. Does this jive with where Maverick is going? The ActionMapping object is pluggable. Would extending that provide the support you need in the config to assist with the transformations? -- 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]
RE: Boost Struts with XSLT and XML - JavaWorld.com
From: Ted Husted [mailto:[EMAIL PROTECTED]] I think we are all onboard with view agnosticism now. Great! Though, the Struts config file will accomodate any URI, and does not prefer JSPs in anyway whatsoever. Personally, I'm liking the model we're seeing in X2 and VelServlet, where other helper servlets are loaded to handle whatever presentation devices someone might use. Using a URI to invoke a servlet is great for simple documents like JSP or Velocity pages, but it is far too limiting for more complicated views like XSLT. With a simple URI, how would you configure these things on a view-by-view basis: * Define multiple transformations to iteratively run. * Pass xslt params to the transformation process. * Run transforms against XML generated from JSP or other views. * Define custom uri-resolvers. * Specify the name of the root element. I've found that it makes sense to distinguish JSP, Velocity, et al as a separate stage from XSLT and DVSL. The former are view types, the latter are transform types; users should be able to arbitrarily apply transforms to views, and there is a considerable amount of configuration data needed to define a transform. Furthermore, the framework's interface to a transform is not necessarily text; it is often much more efficient to be able to pass a DOM, SAX events, or other parsed data directly into the transform. Side node: A really neat idea adapted from Turbine is the document transform which simply takes the output from executing one document and passes it as a String in the request attributes to a subsequent document. This addresses 90% of what the struts-template taglibs are used for, but in a templating-language-independent way and with far less mess. I'm trying to make a case for allowing much more configuration to be specified in the Struts config file. Taking all the above points, the Maverick config for a command might look like this: command name=signupSubmit controller class=org.infohazard.friendbook.ctl.SignupSubmit/ !-- JSP which generates XML which is then processed -- view name=success type=document path=hello.jsp transform path value=outside.xsl/ path value=english.xsl param name=dialect value=uk/ /path /transform /view !-- XML is automagically produced from the model -- view name=error type=domify node=signupElement transform path value=signup.xsl uri-resolver value=org.foo.CustomURIResolver/ /path path value=outside.xsl/ path value=english.xsl/ param name=dialect value=uk/ /path /transform /view /command That should be pretty clear, although it's a lot more complicated than most commands would be. I don't think there is any way to do this sort of thing in the current Struts config schema. Do you think it's reasonable to try to evolve some of the Struts schema in this direction? I think what we are moving towards is exposing the Struts controller API as a standard object in the request that will be easy to use with any helper servlet or presentation system, including JSTL when it ships. Will it allow arbitrary XML configuration data to be pulled from the config file? Does this jive with where Maverick is going? Well, in Maverick 2.0 we removed Velocity from the core and are using the same JSP-like servlet that Struts is using, so I guess the answer is sort-of :-) The ActionMapping object is pluggable. Would extending that provide the support you need in the config to assist with the transformations? I'm looking through the docs and javadocs, and I'm not sure. How do you plug it? And is it free to interpret the XML? Can it read (hypothetically) child elements of forward (under action)? Jeff Schnitzer [EMAIL PROTECTED] http://mav.sourceforge.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Boost Struts with XSLT and XML - JavaWorld.com
This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery I was also starting to learn Struts and saw and continue to see in Struts stuff that I have been doing on my own for a while now, done in a more polished cleaner fashion that attracts me to it. This article showing how to have the best servlet centric architecture (Struts) while cutting out the dead-weight (JSP) really hits home. I just wish they would've provided more code so people like myself who are new to xml can really get a sense of how to implement this beast. -Original Message- From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 12:17 PM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com This is one of the most well written articles I have ever seen. At first blush, I am having a difficult time deciding wether this technology is totally cool, or it is just such a straightforward presentation that I am twitterpated. Thanks Todd Todd G. Nist wrote: I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts is an innovative server-side Java framework designed to build Web applications. Hosted by the Apache Software Foundation's Jakarta Project, Struts has recently gained wide acceptance in the Java community. In this article, Julien Mercay and Gilbert Bouzeid introduce the processing model underlying Struts, describe the Struts framework itself, and present Model 2X, which enhances Struts by replacing JSP (JavaServer Pages) with XML and XSLT (Extensible Stylesheet Language Transformations) to better separate logic and presentation. (2,600 words; February 1, 2002) By Julien Mercay and Gilbert Bouzeid URL: http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html? Todd G. Nist -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Pete Carapetyan http://datafundamentals.com Java Development Services Open standards technology for commercial profitability -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the postmaster at [EMAIL PROTECTED] www.sothebys.com ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery I was also starting to learn Struts and saw and continue to see in Struts stuff that I have been doing on my own for a while now, done in a more polished cleaner fashion that attracts me to it. This article showing how to have the best servlet centric architecture (Struts) while cutting out the dead-weight (JSP) really hits home. I just wish they would've provided more code so people like myself who are new to xml can really get a sense of how to implement this beast. -Original Message- From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 12:17 PM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com This is one of the most well written articles I have ever seen. At first blush, I am having a difficult time deciding wether this technology is totally cool, or it is just such a straightforward presentation that I am twitterpated. Thanks Todd Todd G. Nist wrote: I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts is an innovative server-side Java framework designed to build Web applications. Hosted by the Apache Software Foundation's Jakarta Project, Struts has recently gained wide acceptance in the Java community. In this article, Julien Mercay and Gilbert Bouzeid introduce the processing model underlying Struts, describe the Struts framework itself, and present Model 2X, which enhances Struts by replacing JSP (JavaServer Pages) with XML and XSLT (Extensible Stylesheet Language Transformations) to better separate logic and presentation. (2,600 words; February 1, 2002) By Julien Mercay and Gilbert Bouzeid URL: http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html? Todd G. Nist -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Pete Carapetyan http://datafundamentals.com Java Development Services Open standards technology for commercial profitability -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the postmaster at [EMAIL PROTECTED] www.sothebys.com ** -- 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]
Re: Boost Struts with XSLT and XML - JavaWorld.com
Matt, nicely said. Pretty much what I feel, but could not describe. I guess it comes down to: ITS TOO EARLY. i.e use it for prototypes and dept projects. Don't start designing customer web sites with it until you have sorted out tools, maintenance, evolving xslt/xml specs and so on. Jonathan (who also hates JSP, they are too easy...and thus messy.) Message History From: Matt Raible [EMAIL PROTECTED] on 04/02/2002 09:00 PST Please respond to Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] cc: Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery I was also starting to learn Struts and saw and continue to see in Struts stuff that I have been doing on my own for a while now, done in a more polished cleaner fashion that attracts me to it. This article showing how to have the best servlet centric architecture (Struts) while cutting out the dead-weight (JSP) really hits home. I just wish they would've provided more code so people like myself who are new to xml can really get a sense of how to implement this beast. -Original Message- From: Pete Carapetyan [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 02, 2002 12:17 PM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com This is one of the most well written articles I have ever seen. At first blush, I am having a difficult time deciding wether this technology is totally cool, or it is just such a straightforward presentation that I am twitterpated. Thanks Todd Todd G. Nist wrote: I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts
RE: Boost Struts with XSLT and XML - JavaWorld.com
Matt, Those are very good points. Here is how I deal with each one: 1. You can internationalize using resource bundles with Xalan, because it allows Java extensions. Another thing on i18n, I've noted that when UI's are described in XML, you are combining question text, labels, instructions all in one document. In that case it's more direct to just translate the XML docs, and not use resource bundles. It's rare that you just need to translate a word here or there for web apps. They are full of text, and resource bundles are suited well to managing documents of translated text. The framework just needs to choose the correct XML doc based on the language. 2. XForms is introducing a generic form descriptor language, once that's available we can choose a generic style sheet and modify...I have defined my own XML strucure, and that article gave an example as well. It's not that big of a deal. Once the first style sheet is done, it's easy to modify to account for little changes here and there. 3. Using a tool like excelon makes XSL easy to debug. It is not difficult to debug. You're not really 100% correct on that one. J2EE is difficult to debug, but we still use it. I just saw the post from J. Gibbons, and it is NOT TOO EARLY. Nope. That's wrong. It's time has come, at least for us to consider as developers. Taylor -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:01 AM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery I was also starting to learn Struts and saw and continue to see in Struts stuff that I have been doing on my own for a while now, done in a more polished cleaner fashion that attracts me to it. This article showing how to have the best servlet centric architecture (Struts) while cutting out the dead-weight (JSP) really hits home. I just wish they would've provided more code so
RE: Boost Struts with XSLT and XML - JavaWorld.com
I'm in the process of reading the article ... so no comments on it yet, but I have done a little XSL/XSLT and am in the process of converting my personal website to use it. 1. I18N. Agreed. This is a problem. Having gotten used to I18N in my apps, I really have no desire to give it up. According to the book XSLT (by Doug Tidwell, Pub: O'Reilly, Aug 2001) it is possible to extend XSL/XSLT with Java extensions. Could we brave souls not write an XSL/XSLT extension to give us the I18N that we get in struts-powered JSPs? On the other hand, as I re-read this before I hit send, the XSL/XSLT only process the XML that it's given. It's up to what ever generates the XML to perform the I18N. With a struts/XSL/XSLT mix, who's responsibility would it be to provide I18N? 2. XSL examples. Hmmm. I've written some small ones. They really aren't that hard. I'm planning to write some HOW-TOs (ant, junit etc) once my wife delivers our #2 child, and I take a week off to show support and pull the night shift for her, but she's T plus 5 days right now, so I'm still here at work. I'll add some simple XSL/XSLT examples to the list of things to write. The Tidwell XSLT book has a number of good examples in it and coupled with his excellent explanations, is a powerful book. Recommended. (Although being six months old, I'm sure that it's ready for a re-write! :-) Just a few comments before I get back to reading the article. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:01 AM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself that everything that comes from SUN must be good and beautiful and that those that were ragging on JSP were just fringe loonies. I thought the whole struts tag library and tag libraries in general would shut up the non-believers by removing spaghetti code from JSP. But from experience I am seeing that people will always go the easiest route and when offered a choice between learning how to handle a new tag library API or just slopping some java code into your JSP, its the rare coder who wont take the sloppy, easier, impossibly harder to debug 2 months later approach. I think I can finally admit now that JSP is just not a clean good technology and although I have a lot to learn I'd like to move away from JSP's altogether. Simultaneous to my JSP=bad voyage of discovery
RE: Boost Struts with XSLT and XML - JavaWorld.com
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? 2. Is there any possibility that something like this may become a formal extension to Struts? Thanks, Vaughan. -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 9:32 AM To: Struts Users Mailing List Subject: RE: Boost Struts with XSLT and XML - JavaWorld.com I'm in the process of reading the article ... so no comments on it yet, but I have done a little XSL/XSLT and am in the process of converting my personal website to use it. 1. I18N. Agreed. This is a problem. Having gotten used to I18N in my apps, I really have no desire to give it up. According to the book XSLT (by Doug Tidwell, Pub: O'Reilly, Aug 2001) it is possible to extend XSL/XSLT with Java extensions. Could we brave souls not write an XSL/XSLT extension to give us the I18N that we get in struts-powered JSPs? On the other hand, as I re-read this before I hit send, the XSL/XSLT only process the XML that it's given. It's up to what ever generates the XML to perform the I18N. With a struts/XSL/XSLT mix, who's responsibility would it be to provide I18N? 2. XSL examples. Hmmm. I've written some small ones. They really aren't that hard. I'm planning to write some HOW-TOs (ant, junit etc) once my wife delivers our #2 child, and I take a week off to show support and pull the night shift for her, but she's T plus 5 days right now, so I'm still here at work. I'll add some simple XSL/XSLT examples to the list of things to write. The Tidwell XSLT book has a number of good examples in it and coupled with his excellent explanations, is a powerful book. Recommended. (Although being six months old, I'm sure that it's ready for a re-write! :-) Just a few comments before I get back to reading the article. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:01 AM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Knoll, Zach wrote: This is really cool. I've been struggling with this for a while trying to convince myself
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]
Re: Boost Struts with XSLT and XML - JavaWorld.com
The ActionForms are just JavaBeans in the standard request or session scope, and available to any servlet process in the Application. Most of the other Struts elements are just application scope objects, which are also avaialble to any servlet process in the application, or request attributes (errors) or session attributes (locale). The Struts taglibs just happen to know what attribute name to look under for these objects, and which scope to find them in. It's important to remember that Struts does not render the JSPs. This is done by the container, usually through a service like Tomcat's Jasper. Anything with access to the servlet context can do the same things that the taglibs do, just as the Velocity/Struts kit does. http://husted.com/struts/resources/velstruts.zip Here, the functionality of the Sturts taglibs is provided as standard objects that other presentation layer devices can easily access. -- 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]
RE: Boost Struts with XSLT and XML - JavaWorld.com
Ok. I've read the article now. 1. They point out, correctly in my humble opinion, that the internationalisation is best done during the creation of the XML document. This makes sense to me. 2. They do provide a couple of examples of XML/XSL/XSLT. 3. They do not really seem to much in the way of HOW-TO. I see that there is an accompanying download file, but even if it contains everything I need to get this going, there is no explanation in the article as to how to implement this stuff. This article would have been better as a two-parter. We have the first part, now come back and show us how it's done! Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Chappell, Simon P Sent: Monday, February 04, 2002 11:32 AM To: Struts Users Mailing List Subject: RE: Boost Struts with XSLT and XML - JavaWorld.com I'm in the process of reading the article ... so no comments on it yet, but I have done a little XSL/XSLT and am in the process of converting my personal website to use it. 1. I18N. Agreed. This is a problem. Having gotten used to I18N in my apps, I really have no desire to give it up. According to the book XSLT (by Doug Tidwell, Pub: O'Reilly, Aug 2001) it is possible to extend XSL/XSLT with Java extensions. Could we brave souls not write an XSL/XSLT extension to give us the I18N that we get in struts-powered JSPs? On the other hand, as I re-read this before I hit send, the XSL/XSLT only process the XML that it's given. It's up to what ever generates the XML to perform the I18N. With a struts/XSL/XSLT mix, who's responsibility would it be to provide I18N? 2. XSL examples. Hmmm. I've written some small ones. They really aren't that hard. I'm planning to write some HOW-TOs (ant, junit etc) once my wife delivers our #2 child, and I take a week off to show support and pull the night shift for her, but she's T plus 5 days right now, so I'm still here at work. I'll add some simple XSL/XSLT examples to the list of things to write. The Tidwell XSLT book has a number of good examples in it and coupled with his excellent explanations, is a powerful book. Recommended. (Although being six months old, I'm sure that it's ready for a re-write! :-) Just a few comments before I get back to reading the article. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:01 AM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted
Extending Struts (was: Boost Struts with XSLT and XML - JavaWorld.com)
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. 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. 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. 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]
RE: Boost Struts with XSLT and XML - JavaWorld.com
Hmmm, I read everyone's posts, and they are somewhat inspiring. I'd like to see examples of using Xalan to get my struts message bundle, or other messag bundles. I'm sure I could spend an hour and figure this out, but if anyone has ready examples, links, send them my way! XForms - I'm excited about these, but I think it'll be awhile before the browser's support them. #3 is probably from my own experience. I spent a week trying to develop a XML/XSL framework using JSPs to emit XML, XSL and the JSTL to do the transformation. My JSPs became very small and nice, but it seemed I was spending a lot of time writing the XSL and trying to get it to work properly. I've had a lot of experience with writing HTML and JSPs, and so I bagged the whole idea and recommended we just use JSP/HTML with Tiles and CSS. I know that my client will get more value from my time with this approach. The reason my client wanted to use XML/XSL was to easily adapt the UI for other devices. I think this is a great reason, but it almost seems simpler to me to separate my HTML client from my WAP client and develop entirely new JSPs for the WAP client. Of course, working with a limited budget and a small development team (1) - there's not much time for learning curve. Matt --- Taylor Cowan [EMAIL PROTECTED] wrote: Matt, Those are very good points. Here is how I deal with each one: 1. You can internationalize using resource bundles with Xalan, because it allows Java extensions. Another thing on i18n, I've noted that when UI's are described in XML, you are combining question text, labels, instructions all in one document. In that case it's more direct to just translate the XML docs, and not use resource bundles. It's rare that you just need to translate a word here or there for web apps. They are full of text, and resource bundles are suited well to managing documents of translated text. The framework just needs to choose the correct XML doc based on the language. 2. XForms is introducing a generic form descriptor language, once that's available we can choose a generic style sheet and modify...I have defined my own XML strucure, and that article gave an example as well. It's not that big of a deal. Once the first style sheet is done, it's easy to modify to account for little changes here and there. 3. Using a tool like excelon makes XSL easy to debug. It is not difficult to debug. You're not really 100% correct on that one. J2EE is difficult to debug, but we still use it. I just saw the post from J. Gibbons, and it is NOT TOO EARLY. Nope. That's wrong. It's time has come, at least for us to consider as developers. Taylor -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:01 AM To: Struts Users Mailing List Subject: Re: Boost Struts with XSLT and XML - JavaWorld.com I read this article and think that it is good - but there's a couple of things that I think need to happen before this architecture is embraced. 1. There needs to be mechanisms for getting internationalization into your XML or XSL. It seems difficult to use messages from a properties files for messages and form labels. By difficult, I mean harder than it is to use bean:message in JSPs. I could see putting them into the XML document, but then it seems that HTML developer type stuff is getting handed off to the Java developer. 2. XSL Templates and examples are difficult to find. I think this technology and concept would rapidly catch-on if there were XSL stylesheets that you could download that would format all your form-elements and other details. If the struts-example where adapted to use this approach, people would jump all over it I'll bet. 3. XSL is difficult to debug, and if we're truly separating view from everything else - good luck finding a view developer that knows XSL. I know some of these are irrelevant since we HTML developers are often Java coders and XSL experts... but just my 2 cents. Matt --- Ted Husted [EMAIL PROTECTED] wrote: See also the Velocity/Struts toolset. http://husted.com/struts/resources/velstruts.zip and http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ Same basic idea: expose the Struts API as an object that anybody can easily use, without having to know that Struts even exists. All the hooks are there, they just aren't as easy to get to as they might be. I started a ContextHelper object that did this as part of the core framework. We pulled it out temporarily while the new multiapps stuff is going on. But I plan to put it back in so that the default controller does what the X2 Servlet and Velocity Servlets are doing, in a uniform way. It's my personal opinion that, while JSPs are flexible, these other technologies work are ever bit as effictive when used as the V in MVC. -- Ted Husted, Husted dot Com, Fairport NY USA
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]
RE: Re: Extending Struts (was: Boost Struts with XSLT and XML - JavaWorld.com)
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
Boost Struts with XSLT and XML - JavaWorld.com
I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts is an innovative server-side Java framework designed to build Web applications. Hosted by the Apache Software Foundation's Jakarta Project, Struts has recently gained wide acceptance in the Java community. In this article, Julien Mercay and Gilbert Bouzeid introduce the processing model underlying Struts, describe the Struts framework itself, and present Model 2X, which enhances Struts by replacing JSP (JavaServer Pages) with XML and XSLT (Extensible Stylesheet Language Transformations) to better separate logic and presentation. (2,600 words; February 1, 2002) By Julien Mercay and Gilbert Bouzeid URL: http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html? Todd G. Nist -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Boost Struts with XSLT and XML - JavaWorld.com
This is one of the most well written articles I have ever seen. At first blush, I am having a difficult time deciding wether this technology is totally cool, or it is just such a straightforward presentation that I am twitterpated. Thanks Todd Todd G. Nist wrote: I have not seen this posted so, for those interested in using XSLT and XML with Struts, thought the following article maybe of value. Boost Struts with XSLT and XML An introduction to Model 2X Summary Struts is an innovative server-side Java framework designed to build Web applications. Hosted by the Apache Software Foundation's Jakarta Project, Struts has recently gained wide acceptance in the Java community. In this article, Julien Mercay and Gilbert Bouzeid introduce the processing model underlying Struts, describe the Struts framework itself, and present Model 2X, which enhances Struts by replacing JSP (JavaServer Pages) with XML and XSLT (Extensible Stylesheet Language Transformations) to better separate logic and presentation. (2,600 words; February 1, 2002) By Julien Mercay and Gilbert Bouzeid URL: http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html? Todd G. Nist -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Pete Carapetyan http://datafundamentals.com Java Development Services Open standards technology for commercial profitability -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
