Originally posted by Vishnu Murthy: The contents for each jsp is different and also the layoout except header/footer and side menu links. ... However,we are told to into the possiblity of using a few XML/XSLT instead of writing 150 odd JSP pages so that the project effort can be reduced.
I'm very suspicious about reducing overall effort simply by using XSLT instead of JSP. What do those existing JSP files contain?
sorry to hijack your thread Vishnu, arnold can I ask you a question.
I've been thinking of using xsl to produce web pages for as while now, I'm currently using JSP.
I'm a bit confused though on one aspect, currently using struts it's very easy to forward to a JSP page using something like "return (mapping.findForward("success"));".
So, if I had a sql query result set that had been transformed to XML format (using iBatis it looks quite easy to do this) -
1. How would I run an XSL file (or however it's stored - memory?) pass it to produce a web page?
2. How do you then pass control to this page in Struts?
You see, I have a requirement to produce a report in a web page. This page also needs to have an "export" faclity so the same details can be produced & downloaded as an excel file. So I'm thinking to run the same results against 2 different XSL's to acheive this. Does this sound right or am I talking rubbish? - need to get this straight in my head before attempting it!
Vishnu, I used in XSLT in my previous job and currently use JSP. I find JSP to be much easier to maintain. If those 150 JSPs are really different, you are going to have the same amount of complexity, it will just be in XSLT. If there are less templates, they will be more complex and harder to work with. This doesn't reduce effort, just number of files.
If the JSPs are not really different, some of the JSPs can be merged. Look for JSPs that have virtually the same layout and see if you can make them more generic. You will need to go through this merging effort regardless of whether you stay with JSPs or go to XSLT if you want to reduce the complexity/effort. Remember, the same JSP can service many different pages.
Jeanne is right. XSLs are much harder to maintain than JSPs. If reusablility is your concern, it can be improved with JSP + Tiles. With XSL, u seem to loose all the comfort of JSTL and other taglibs that makes your life easier. Anyway, this is my private opinion. IMHO, XSL can be used, but it should not replace JSPs.
Joined: Jan 04, 2001
Hi Jeanne, I have gone through that article in javaworld.com there he is explained about the process everything about as how to write use XSL/xslt. we are using Websphere studio application developer v5.1 now I would like to know two things
1. where (in which file) we have to specify the mapping between form and xslt i.e for a particular form (Ex: login page is a form) what is the xslt and, 2. In WSDE v5.1 where we have place these xslt file.
XSLT should complement Struts. I don't think it is wise to use XSLT only. In my opinion, for cases that you need to change a lot of presentations out of the same data, XSLT is very helpful. I found this is especially true for reports. You can choose different stylesheets on the fly. It is very convenient to add/change stylesheets. If the presentation is quite stable and relatively simple, such as simple forms, a typical HMTL page, JSP is sufficient, fast and good.
XSLT transformation is expensive in memory and speed. You have to generate data in XML format before spending mem/cpu on the transform. SAX is faster parsing XML but still uses a lot of memory than JSP for the same job.
Hope it helps.
Tony Yan<br /> <br />IBM Certified Developer XML and Related Technology<br />Sun Certified Web Component Developer For J2EE Platform<br />Sun Certified Programmer For Java 2 Platform
Joined: Jan 23, 2002
Originally posted by Vishnu Murthy: 1. where (in which file) we have to specify the mapping between form and xslt i.e for a particular form (Ex: login page is a form) what is the xslt and, 2. In WSDE v5.1 where we have place these xslt file.
There is no standard place to specify such mappings. You might want to add your own proprietary mapping document under WEB-INF or under WEB-INF/classes.
Vishnu, As Lasse pointed out, there is no special file for the mapping. The only restriction is that the transformation servlet must be able to read it.
If you decide to put it in WEB-INF/classes, I would recommend putting the file in your WSAD source folder and letting it "compile" into /classes. If you decide to put it in WEB-INF, you can put it loose or in a subfolder.
Joined: Nov 20, 2003
The Model2X is straightforward and easy to use, this is a real pro for this architecture. If you are happy with this, use it. On the other hand realize that the Model2X copies, or reinvents, ideas that have already been implemented and tested in the Cocoon project. Furthermore the Model2X architecture only presents an idea and gives you some direction how you can implement this solution by presenting only a reference implementation that you can download and use.
The combination of Struts and XML/XSL is a powerful combination and I think that it should depend on the size and architecture of your project which solution you should/could use. If your project is very small, almost a lab environment, you can start with Model2X. But another solution that you could try, or look at, is the stxx project ( http://stxx.sourceforge.net/ ). If you, on the other hand, feel confident that you understand Struts and the XML/XSL transformation process. I would advice you to combine the flow/validation/tiles aspects of Struts with the presentation framework of Cocoon. And even in this type of solution you are not alone. Connectors between Cocoon and Struts/Struts and Cocoon are already written. In 2003 someone has already written a connector that integrates Cocoon with Struts. Take a look at : http://struts.sourceforge.net/struts-cocoon/ to see how this is done. But there are more connectors over there that you can use
About transforming your JSP style of pogramming to a XML/XSL style of programming and transforming your 150 pages : One of the drawbacks of executing this transformation is that you have to change from an object oriented paradigm to a declarative ( functional ) progamming style. Another drawback is that instead JSP seperates code from presentation, like Velocity does and JSP should do. It gives you the possibility to mix your presentation code with your business code. So when you've sort of a Model1-architecture and your presentation code is mixed with you business code, don't use XSL. When you want a quick fix and don't want to learn a new programming style, don't use XSL. Even when you're pages don't have the 'same' structure and presentation, don't use XSL. I've done some projects in the past where we didn't look at the last constraint and just used XSL because we always used it for our presentation layer. This solution took really a lot of time and it would be so much faster if we've just used XHTML. So there are some constraints that you should be aware of. Currenlty I only use XSL in very specific situations. For example when transformation to PDF or SVG is needed, and I can't use DocBook. Or when I'm using a standard product that spits out some standard XML that needs to be transformed to XHTML.
About reading and writing Excel : Are you already aware of the POI project, http://jakarta.apache.org/poi/hssf/index.html But instead of directly using POI you can also use Cocoon for generating your Excel file. I've explained above how you can integrate Struts/Cocoon [ December 01, 2004: Message edited by: Arnold Reuser ]