• Post Reply Bookmark Topic Watch Topic
  • New Topic

Can JSP Exhibit XSL Behaviour?  RSS feed

 
Anirvan Majumdar
Ranch Hand
Posts: 261
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This might sound a bit out of sorts, but I post this purely out of curious concerns.
I have had significant experience working both with XSL's and JSP's, and I was wondering, is there some way in which a developer can use a JSP or a JSP-like templating component to perform tasks similar to XSL's?
Even though it's quite true that both XSL's and JSP's have been developed keeping in mind different sets of problems, but fundamentally speaking, both of these technologies are used to transform/template an input format of data to another one. This may involve a change of format => XML/Java Objects to HTML/Text or might simply involve a rearrangement or addition of new fields/properties in the same format.
But where they are quite different is the fact that while with XSL's a developer still has a handle after the transformation, but with JSP's once the transformation is done, the response is flushed directly to the client.
Also, if one would want to leverage the Taglib functionality of JSP's in having a templating tool other than XSL, does there exist a solution? For someone who's not too comfortable with the XSLT syntaxes, but has a firm understanding of JSTL and the likes, this can actually be really helpful.

I hope I managed to express my point clearly, and look forward to some helpful insights.
Thanks!
[ May 01, 2008: Message edited by: Anirvan Majumdar ]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
XSL-like behavior is realized in the code of the JSP Engine. This code handles the transformation of the HTML and JSP elements into Java code. This code is written by JSP Engine programmers.

A key reason why Java Server Pages technology was created was to enable HTML designers to create pages using Java objects without having to know Java.

Java programmers work with JavaBeans and custom JSP elements and provide them to HTML designers who use the beans and tags to create pages.

In regards to key runtime differences, an XSL Engine contains an XML parser.

Also, if one would want to leverage the Taglib functionality of JSP's in having a templating tool other than XSL, does there exist a solution?


Please clarify a bit. What does XSL have to do with JSP elements? I am not aware of any such connection.
[ May 05, 2008: Message edited by: James Clark ]
 
Anirvan Majumdar
Ranch Hand
Posts: 261
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I meant is:
Say I've got an XSL which transforms an input XML data to give an output of HTML or XML or simple text.
Now, can I have a JSP which takes Java objects instead of the XML as input and give an output as an HTML, XML or simple text?

This way, I could leverage the taglibs of JSPs, instead of relying on the XSLT syntaxes to transform the data. And since it's easier to find people more conversant w/ JSP than w/ XSLT, it will be of help in creating templates faster.

However, as I see, the problem w/ JSP vis-a-vis XSL is that once the HTTP request is forwarded to the JSP, a user cannot perform some operations and say change the HTTP response headers once the JSP has transformed the data.
Which in the case of XSL is possible since XSL's don't follow the request/response paradigm as is the case with JSPs.
I was only wondering if there was some way to obtain a handle on the response object once the JSP has done its work, and before it gets flushed.

I hope this helps you understand my case somewhat better.
Thanks for your reply in the first place though :-]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now, can I have a JSP which takes Java objects instead of the XML as input and give an output as an HTML, XML or simple text?


Yes. You would have to create your own JSP custom tags and write the code for this behavior. What you mean by "takes Java objects instead of XML as input" is unclear.

However, this is not the purpose of Java Server Pages technology. There are other API that can be used to do this transformation. The first step is process the Java object and get an XML representation of it. (Check out XMLBeans and JAXB API). The second step would be to transform the XML to HTML, XML or simple ASCII text with an XSL stylesheet using the JAXP API.

Again, you can certainly create your own JSP elements that do the processing above. But, the XSL was designed specifically for processing XML data, so why you would want to deviate from the norm and write code for your own transformations is questionable.
[ May 06, 2008: Message edited by: James Clark ]
 
Anirvan Majumdar
Ranch Hand
Posts: 261
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Clark:

What you mean by "takes Java objects instead of XML as input" is unclear.

By "takes" I simply meant that the JSP accepts Java objects as input [stored as an attribute on the request/session object]
Originally posted by James Clark:
However, this is not the purpose of Java Server Pages technology..... The first step is process the Java object and get an XML representation of it. (Check out XMLBeans and JAXB API). The second step would be to transform the XML to HTML, XML or simple ASCII text with an XSL stylesheet using the JAXP API.

I fully understand the purpose of JSPs. I just wanted to enquire whether someone might just have used a JSP to do the task of an XSL. I am aware of the transformational techniques [XMLBeans, JAXB) you've mentioned. However, the very purpose of my post was to bypass the transformation of Java objects to XML and then applying XSL on it! And not about how should I use XSL. I think you got it all wrong there.
Originally posted by James Clark:
Again, you can certainly create your own JSP elements that do the processing above. But, the XSL was designed specifically for processing XML data, so why you would want to deviate from the norm and write code for your own transformations is questionable.


I don't want to create any taglibs/elements as such. There are plenty of them which are already existent like the JSTL library. I just wanted to leverage the use of these libraries and avoid the overheads associated with using XSLs.
As to your query why I really want to deviate from the norm and want to use JSPs instead of XSLs:
1. I can do away with the overhead of transforming my Java objects to an XML document.
2. In the context of Java, JSPs seem to be much more powerful as a templating tool than XSLs.
3. People having a working knowledge of JSPs far outnumber those having a decent understanding of XSLs.

Thanks for your replies James, but I think, the alternative I'm seeking doesn't really exist.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are welcome. You are right, what you specify does not exist. However, this does not mean that you can't create it.

I don't want to create any taglibs/elements as such. There are plenty of them which are already existent like the JSTL library. I just wanted to leverage the use of these libraries and avoid the overheads associated with using XSLs.


If the existing, public tag libraries do not contain the functionality that you desire, then you can create your own tag library. Note, you can certainly create an element that extracts data from a Java object and outputs an HTML-based representation without using a eXtensible Stylesheet Language stylesheet. This is fairly simple. You just have to write it.



1. Create a JSP tag that will take this object from wherever and put a HTML fragment in the HttpResponse object.

<p><b>Bob Jones</b></p>


The code for creating the HTML fragment would be in the tag handler class. There would not be any eXtensible Stylesheet Language code anywhere.
[ May 06, 2008: Message edited by: James Clark ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!