• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XSLT as a JSP's murderer

 
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In other words "JSP is dead"
This article said that xml+XSLT make JSP redundand. As a big XSLT fan, I strongly object inflicting predatory beahavior upon this peacefull hardworking technology. JSP and XSLT usage may overlap in the field of HTML generating, but don't they have separate missions otherwise?
On the other hand, rumors that "For a dynamic web site, JSPs are going to be a magnitude of performance better" should be emphatically rejected as ill-proved
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I recently read and reviewed the book Java and XSLT by Eric Burke. The book discusses the option of using XSLT as a replacment for JSP. The author demonstrates that this has real potential as a solution.
However, there are several problems with it:
1) Skill set - XSLT is not a simple technology to learn and if your staff is proficient at Java then it makes little or no sense to have them learn XSLT when JSPs are at least as good a solution. Burke says that the XSLT solution may make sense if you have XSLT skills in your staff aleady.
2) Performance - An XSLT solution will never outperform a JSP solution. However not every application is performance oriented. Imagine a site where you generate static pages every day based on data in a database. Why not generate that into XML and then use XSLT to convert that XML into whatever output (HTML, WML, XML) that you need? But if performance is an issue then JSPs are the clear winner.
3) DOM, SAX, JDOM? - Face it, there are quite a few standards out there right now and none of them make generating XML a breeze. The XML world itself is in transition. It may be worthwhile to wait until a clear winner is in sight or until the standards are more "standardized" before committing your enterprise to a standard.
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just wanted to comment on the JSP "drawbacks" from Map's article:
As in Model 1's case, nothing prevents a developer from embedding application logic into the JSP. Experience shows that many developers actually fall into that trap, often to perform a quick fix. This can lead to applications that are hard to understand and maintain.
Yes that is why we have code walk thorughs. As far as I know there is no solution that prevents bad programming. XSLT does not solve this problem.
The JSP syntax is not XML compliant and therefore fails to guarantee that resulting XML or HTML documents will be well formed.
Yeah but I can use XSLT to take a compliant XML document and turn it into crap. I don't see the author's point here.
The developer must learn new APIs -- the Struts tag libraries. Experience shows that gaining an understanding of the Struts tag libraries, particularly the bean and HTML libraries, can take a long time.
Yes, it took me almost a week. It is at least 50 times simpler than XSLT.
You can't implement a real processing pipeline in the view with JSP. Only basic includes and forwards are possible, effectively limiting the view's flexibility. For example, separating layout and style proves difficult.
That is why we have CSS.
With JSPs, you must recompile after every change, which can be time consuming. Just ask any JSP developer waiting for page compilation after every mouse click.
Yes, Those 4 second waits are driving me crazy. Obviously these authors never worked in C++. I remember waiting 45 minutes for a C++ application to compile.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XSLT is not a simple technology to learn
Only because people learn it wrong way, or do not learn at all, hoping to get it by "messing around" or how do you call it?
But if performance is an issue then JSPs are the clear winner.
I still do not understand why.
DOM, SAX, JDOM? - Face it, there are quite a few standards out there right now and none of them make generating XML a breeze.
"Simple to generate" was one of XML design goals Yet when DOM and SAX were born, our community decided that it's far too complex and created JDOM. I bet, soon JDOM will be considered too complex and something even simplier will appear. Probably this is what they call "progress"
As far as I know there is no solution that prevents bad programming. XSLT does not solve this problem.
Agree
Yeah but I can use XSLT to take a compliant XML document and turn it into crap. I don't see the author's point here.
Again I have to agree
Yes, it took me almost a week. It is at least 50 times simpler than XSLT.
Only because it's less powerful!
"For example, separating layout and style proves difficult."
-That is why we have CSS.

XSLT doesn't automatically solve this problem either. You can perfectly mix logic, layout (in form of HTML tags) and style (more HTML tags). Or you can stylize your output with CSS - just like you do with JSP. There are possibly better solutions, this article offers one, but it should be considered "creative use" rather than "standard practice" and I bet one can use JSP in many creative ways as well.
The bottom line: I see XSLT as 1) a cheap, easy, declarative alternative to DOM/SAX/JDOM etc. for XML transformations; 2) better way to output HTML than System.out.println ("<b><font size=+2>Hello World</font></b>") but I do not see big advantages over JSP
[ February 09, 2002: Message edited by: Mapraputa Is ]
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason that JSP will perform better that XSLT is that the input to XSLT is an XML document but the input to JSP can be Java classes. Take the case of dynamically building a page based on data from a database. You can take the data, load it into a collection, and feed it into a JSP. For XSLT, I would have to get the data, create an XML document out of it, and then feed that it an XSLT processor. So how do I create my XML document? Do I use DOM or SAX? Do I simply have a bunch of out.println("< firstname >"+fname+"< /fname >"); statements?
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As to the power of XSLT, I agree. You can do a lot of neat things but the power comes at the cost of complexity. If I have a staff of Java programmers then I would stick with JSPs. If I have a staff familiar with XSLT then I would give serious thought to using it. The question, of course, is how do I get my data into a form that the XSLT process can handle?
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By the way, I love it when you agree with me. It makes me smile to see all those:

 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason that JSP will perform better that XSLT is that the input to XSLT is an XML document but the input to JSP can be Java classes. Take the case of dynamically building a page based on data from a database. You can take the data, load it into a collection, and feed it into a JSP. For XSLT, I would have to get the data, create an XML document out of it, and then feed that it an XSLT processor. So how do I create my XML document? Do I use DOM or SAX? Do I simply have a bunch of out.println("< firstname >"+fname+"< /fname >"); statements?
Ah, now I see what you mean. I assumed that we have XML input ready (cannot last versions of databases produce XML automatically?) and XSLT is compared to JSP in "presentation technique" nomination.
If we need to extract data from a database, then we probably do not have "redundant" data as an input for presentation and we do not need XSLT's ability to query = provide multiple views from the same document. Then XSLT can only be used for "styling", as a source of formatting HTML tags - I believe JSP can do that with the same success. Also paging isn't easy with XSLT, if at all possible, essentially it's "all or nothing" model.
The question, of course, is how do I get my data into a form that the XSLT process can handle?
If your database doesn't support XMLised output you can map data to objects, and then use one of binding frameworks. Of course, you next question will be why do I need this double mapping, and my answer would be "maybe you do not need it". XSLT is a great tool to transform an input in the form of XML into something else (maybe another XML). If somebody sent you XML document you need to process it somehow. But if XML isn't primordial data format, then I suppose you can live without XSLT
But I have my own questions. Here is a quote from aforementioned article.

Originally posted by JavaWorld:
The raw material used by the stylesheet is the XML stream, which is entirely defined by the model and the context. Although some XSLT transformers support extensions, letting you call Java code or other languages from within a stylesheet, use of such extensions is limited due to the additional effort required and the resulting lack of portability.


Additional efforts:
If to speak about programmer's efforts, they can be fully described as
1) add Java namespace to <xsl:stylesheet> element:
xmlns:java="java"
2) call Java method as
<xsl:value-of select="java:toUpperCase($titleStr)"/>
(I took this example from another JavaWorld article )
Question: how much additional efforts are too much? :roll:
Or are we talking about CPU's efforts? Then some statistics could help.
"the resulting lack of portability":
Is our presentation solution doomed to nomadic life? If it's Ok to call Java code from JSP, what is inherently wrong about doing the same from XSLT?
This difficulty effectively removes any possible side effects during the XSLT transformation and separates the business and presentation logic.
Either I am hopelessly stupid, or there are three different things accidentally combined in one sentence. "This difficulty" apparently refers to "additional efforts"; how does it "effectively removes any possible side effects"? No Java code = no side effects? It's hard to argue with such an interpretation, especially if to remember that XSLT is "side effect free" language and calling Java functions isn't going to introduce any of them. If I am mistaken, correct me. "... and separates the business and presentation logic" - I failed to understand how not calling Java code separates the business and presentation logic. Cannot we mix them with pure XSLT? Cannot we keep them separated even with Java code maliciously called?
Sorry for being sarcastic. Today I wrote Java code to read number of posts from our moderators profiles, and I call call call this code from my XSLT for the contact page. It's damn to watch how you guys are automatically sorted during an XML -> HTML transformation.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By the way, I love it when you agree with me. It makes me smile to see all those:

Ok, Tom, only for you:


(it was a part of my previous post, but UBB doesn't allow me put more than 8 smiles )
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, now I see what you mean. I assumed that we have XML input ready (cannot last versions of databases produce XML automatically?) and XSLT is compared to JSP in "presentation technique" nomination.
OK, we are getting real dull. We are agreeing way too much. I'll bet it's because we are the only two people who understand this technology and the authors of JavaWorld need our advice!
The way I see it there are two ways that XSLT transformations can be used over JSP where performance is not an issue. (1) You have a bunch of static HTML pages that you want to display to multiple device types or to another computer for processing. These could be dynamic pages that are created on a daily, weekly, monthly basis. rather than create them in 20 different formats, we could use XSLT to transform them into whatever process is desired. (2) I can pre-process my data in my database and produce XML as output. We are adding business logic to the database so that might not be a great idea but we do it all the time with stored procedures anyway.
But I have my own questions. Here is a quote from aforementioned article.

Originally posted by JavaWorld:
The raw material used by the stylesheet is the XML stream, which is entirely defined by the model and the context. Although some XSLT transformers support extensions, letting you call Java code or other languages from within a stylesheet, use of such extensions is limited due to the additional effort required and the resulting lack of portability.


Additional efforts:
Question: how much additional efforts are too much? :roll:
I don't see this as being a big deal.
"the resulting lack of portability":
Is our presentation solution doomed to nomadic life? If it's Ok to call Java code from JSP, what is inherently wrong about doing the same from XSLT?
I think they are talking about the loss of portability across XSLT transformers and there they have a point. If I use the extensions of one transformer then I can't go to another one. What is needed is a standard for extensions.

Originally posted by JavaWorld:This difficulty effectively removes any possible side effects during the XSLT transformation and separates the business and presentation logic.


Either I am hopelessly stupid, or there are three different things accidentally combined in one sentence. "This difficulty" apparently refers to "additional efforts"; how does it "effectively removes any possible side effects"? No Java code = no side effects? It's hard to argue with such an interpretation, especially if to remember that XSLT is "side effect free" language and calling Java functions isn't going to introduce any of them. If I am mistaken, correct me. "... and separates the business and presentation logic" - I failed to understand how not calling Java code separates the business and presentation logic. Cannot we mix them with pure XSLT? Cannot we keep them separated even with Java code maliciously called?
First, nothing is hopeless.
Second, I think they are trying to say that XSLT without Java is only doing presentation but if you add Java then it is doing business logic. They have a point. We try to keep Java code out of JSPs as much as possible for the same reason. Personally, I think it is wise to keep Java out of the XSLT. XSLT is confusing enough already.
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When people compare XSLT to JSP and say JSP will be replaced by XSLT, they are just comparing orange to apple. Sure, XSLT and JSP are all capable of generating HTML for presentation, just like oranges and apples are all fruits, but they have really distinguised features or nutrition serving for different purposes. XSLT and JSP will coexist just like oranges and apples. You will pick one of them mostly depending on what features that you need.
To me,
(1) XSLT is the query and formatting tool for XML, just like SQL to relational data base.
(2) JSP on the other hand, is like a 'glue' to stick things(Static content and dynamic contents in many forms) together
When it comes to presentation layer, they do compete with each other in some circumstance, like presenting the query result in HTML format. You do have the choice to encapsulate the query result as a bean and use JSP to present it, or use XSLT to convert the query result in XML format, which can be generated in native SQL with newer release RDB, to HTML. XSLT will be used more and more in this kind situation.
But things are not always that straight forward. Unlike what is illustrated in the diagram of the article, the model should include both the data model, and business model(Action classes, which should not be in the controller part as in the diagram, EJBs etc). Of course, these all can be mapped(or bound to) XML and then use XSLT to combine them and transform into HTML(Multiple passes are very likely). But in many cases, it will be more effective to use JSP to glue them together and emit the HTML directly.
Even if XSLT would gain all the ground in presenting the result(or generating HTTP Response), JSP is still needed in helping the form beans to capture the data from the form, fascinating the processing of HTTP request etc.
As far as the performance and productivity go, JSP are still ahead of XSLT, at least for now. Debugging a XSL style sheet is much more difficult than debugging a JSP, and JSP page compiler definetly has smaller footprint than XSLT engine and parsers. Anyway, JSP can be (and was designed to be) used by web master. But I really don't think XSLT can be used by a non-programmer effectively unless some kind of tools are developed for that purpose.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Paul:
I think they are trying to say that XSLT without Java is only doing presentation but if you add Java then it is doing business logic.


Example from another JavaWorld article: XSLT doesn't have a built-in function to get current date. If all I want is to insert today's data in my output, I am doing presentation or business logic?
Another example, my favorite. I need to list all guys on our contact page sorted by number of posts. I cannot keep number of posts in an input XML because it changes every minute. So I call my Java function from XSLT. Is it presentation or business logic? For me, it's pure presentation.
To avoid calling Java code, I would have to write a full-blown application that would read my XML, get number of posts and update each element. But it's an awful lots of code! With XSLT all I have to write is:
<xsl:sort select="user:getPostNumber(userNumber)/>

They have a point. We try to keep Java code out of JSPs as much as possible for the same reason. Personally, I think it is wise to keep Java out of the XSLT. XSLT is confusing enough already
To add Java to XSLT means to add incredible power. And you do not really "add" Java code in JSP's manner you add only function call. User-defined function call differs from standard function call only in an prefix added, so instead of:
<xsl:value-of select="someFunction()"/>
you write:
<xsl:value-of select="java:someFunction()"/>
Isn't too confusing, is it?
I think they are talking about the loss of portability across XSLT transformers and there they have a point. If I use the extensions of one transformer then I can't go to another one. What is needed is a standard for extensions.
That's a good point. It also occurs to me, that they may be talking about Struts itself, who indeed is doomed to nomadic life. Struts users may want to use different XSLT processors. Both major XSLT processors, Xalan and Saxon, support extensions, although use slightly different syntax. I was able to find a variant that satisfied both. This, however, doesn't prove portability among processors, because according to XSLT spec. they are not required to support extensions at all I checked current draft of XSLT specification version 2.0 and to my big surprise they did not standardize extensions. I read somewhere that W3C authorities decided that it should be a separate specification or something.
[ February 16, 2002: Message edited by: Mapraputa Is ]
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As to the power of XSLT, I agree. You can do a lot of neat things but the power comes at the cost of complexity.
Where this myth about XSLT complexity originated from? It is much much much easier than Java. Idea about functional programming and pattern matching is enlightening and highly recommended for every programmer to learn. My own humble experience with XSLT was way more satisfying than with Java. Some things do look impossible to accomplish with XSLT and it can be a source of frustration, but there is a great source of "ready-to-use" solutions, and if nothing else works, go to Wrox's XSLT forum where world-class expert on XSLT Michael Kay offers free service in solving folks problems.
[ February 16, 2002: Message edited by: Mapraputa Is ]
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Lin:
But things are not always that straight forward. Unlike what is illustrated in the diagram of the article, the model should include both the data model, and business model(Action classes, which should not be in the controller part as in the diagram, EJBs etc).


Tom, what is it? Now there are three people who understand this technology and whose advice JavaWorld authors need!
Even if XSLT would gain all the ground in presenting the result (or generating HTTP Response), JSP is still needed in helping the form beans to capture the data from the form, fascinating the processing of HTTP request etc.
Pardon my ignorance, is JSP a requirement for all this? Cannot we just use a servlet? I also thought about HTTP request processing. If servlet can do that, than we have more reasons to replace JSP with XSLT
Debugging a XSL style sheet is much more difficult than debugging a JSP
That maybe just a matter of experience. I debugged only few JSPs and for me it was more difficult than to debug XSLT.
[ February 16, 2002: Message edited by: Mapraputa Is ]
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Where this myth about XSLT complexity originated from?
The complexity of XSLT comes from the lack of user end tools to create output documents. Products like Interwoven can dynamically create JSPs in a way that an end-user can learn in a one week class. The Java developer writes the custom tag libraries and the user can handle the view portion of MVC. For the avis.com project we were able to train 3 users in one week to generate JSPs using Interwoven. The Java developers only supported them when new functionality was needed in the custom tag libraries.
I debugged only few JSPs and for me it was more difficult than to debug XSLT.
Debugging of JSPs is gretly simplified by the use of tools designed for that purpose.
Tom, what is it? Now there are three people who understand this technology and whose advice JavaWorld authors need!
Frank Lin is incorrect about one thing. Struts Action classes are considered to be part of the controller because they should not have business logic. The ActionForm objects should be in the Model portion. He is right about the model portion including EJBs. The model should include any JavaBeans that include business logic as well.
To add Java to XSLT means to add incredible power. And you do not really "add" Java code in JSP's manner you add only function call.
I think it makes sense to think of XSLT calls to Java the same way that we think of JSP calls to tag library functions. The issue then becomes one of standardization which as discussed is a problem in XSLT.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Thomas Paul:
For the avis.com project we were able to train 3 users in one week to generate JSPs using Interwoven.


But this is user abuse! Why did you make users generate JSPs? So maybe according to your plan every one who wants to read a review in our new bunkhouse will have to generate JSP for it? :roll:
Debugging of JSPs is gretly simplified by the use of tools designed for that purpose.
I suspected there must be something... Well, we have free XSLT debugger, and new tools appear every day. Today XMLhack reported XSL profiler release Or this XSL generator
I think it makes sense to think of XSLT calls to Java the same way that we think of JSP calls to tag library functions. The issue then becomes one of standardization which as discussed is a problem in XSLT.
We can conduct an exstensive scientific research for our new bunkhouse project. Implement both JSP and XSLT presentation solutions and investigate all issues in details
[ February 17, 2002: Message edited by: Mapraputa Is ]
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mapraputa Is:

But this is user abuse! Why did you make users generate JSPs? So maybe according to your plan every one who wants to read a review in our new bunkhouse will have to generate JSP for it? :roll:


For the simple reason that generating JSPs allows then to create dynamically generated pages. Now when a page that contains dynamic data needs to have its appearance revised, it is not an IT issue.

Originally posted by Mapraputa Is:
I suspected there must be something... Well, we have free...

What I am referring to is that the same IDE tools that we use to generate our JSPs can also be used to debug them remotely.

Originally posted by Mapraputa Is:

We can conduct an exstensive scientific research for our new bunkhouse project. Implement both JSP and XSLT presentation solutions and investigate all issues in details

At the rate we are going we should be happy getting one solution completed!
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And this argument that JSP demonstrate superior performance. Doesn't network latency contribute enough in overall response time, to make any difference in HTML generation time negligible?
Of course, your new signature made our old discussion suspicious, to say lest.
[ February 20, 2002: Message edited by: Mapraputa Is ]
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm sad that I missed most of this discussion. Too many other forums to look at I guess. Any way, here are a few comments to add my views to this debate.
I use both XSLT and JSP every day, and JSP certaimly frustrates me the most of the two! Mostly I use XSLT to generate JSP pages from XML specifications (which sometimes include CDATA chunks of HTML/JavaScript/JSP). I love XSLT for this because I can do it at "build" time, before deployment, when the bulk of my Java is also compiled. I hate JSP for this because I have to go and "poke" the deployed application after deployment to make sure that the JSPs even compile
I have toyed with the idea several times of generating raw servlets rather than JSPs from my XML page specifications, to bypass the JSP stage completely, but have never quite found the time to get it working. And I guess that I would mostly be duplicating the JSP code anyway.
The initial version of my current project did the XSLT transformations at run time, and even with all the clever XSLT cacheing offered by Resin, it was still noticeably slower, so I moved the XSLT stage to build-time.
One option I would like to follow, but have found irritatingly unsupported by most XSLT vendors is to dynamically build an in-memory XML document (using DOM, JDOM or whatever), and pass it pre-parsed straight to an XSLT engine, which has in turn cached a compiled version of the stylesheet. This should go a long way toward improving the horrible "spit it all out as XML, then parse it all in again" way that XSLT seems almost always to be used.
Similarly, does anyone know of a "reverse SAX" equivalent which I can pass to an XSLT engine and calls out to my supplied Java code while traversing a virtual DOM? I would love something like this, as I could leave evaluation of potentially complex operations (retrieving EJBs from a remote DB etc.) until actually needed, rather than having to pre-populate an XML document with every value which the XSLT might possibly need, just in case the presentation layer decides to show it.
I have never encountered the select="java:someFunction()" which Map mentions, and would be really interested to learn more if anyone can provide any pointers. All my XSLT to date has been "pure" using only the built-in operations, which may be why I still feel the need for JSP/Servlet code to access session data, HTTP parameters etc.
On balance I guess I side more with Map than with Tom, and would ditch JSP if I could.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Carver:
I'm sad that I missed most of this discussion. Too many other forums to look at I guess.


Absolutely. Maybe we should start a thread somewhere (JavaRanch forum?) where moderators or just everybody could point to threads they think may be of interest for many people

One option I would like to follow, but have found irritatingly unsupported by most XSLT vendors is to dynamically build an in-memory XML document (using DOM, JDOM or whatever), and pass it pre-parsed straight to an XSLT engine, which has in turn cached a compiled version of the stylesheet.


I maybe do not understand this part... Cannot Xalan do that? They said:
"The input may be submitted in the form of a stream of XML markup (from a URI, a character or byte stream, or another transformation), a SAX InputStream, or a DOM Node."
http://xml.apache.org/xalan-j/overview.html
And here is Saxon:
"Saxon has an option to work with a source tree constructed using JDOM. Saxon is validated with JDOM version 0.7; it does not work with earlier releases."
http://saxon.sourceforge.net/saxon7.0/index.html
And here is how Xalan works with compiled stylesheets.
I never tried it but it should work... Or do you mean something different?

I have never encountered the select="java:someFunction()" which Map mentions, and would be really interested to learn more if anyone can provide any pointers.


XSLT blooms with Java:
http://www.javaworld.com/javaworld/jw-12-2001/jw-1221-xslt.html
I was amazed how easy it was to call Java function from XSLT.
[ February 21, 2002: Message edited by: Mapraputa Is ]
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for those great links.
I guess I must have got out of date - the last time I looked at XSLT processor's capabilities, I couldn't find any that worked properly with user-created DOM nodes. I shall have to check them out again.
And as for that article about calling Java from XSLT. You sure are right it's easy. A ten-second tweak to my main stylesheet and I was calling Java from XSLT under the control of Ant.
Wow!
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have to admit that I can't see why JSPs would frustrate anyone. When used as a view-only they are very simple. The last major internet application I wrote used a struts-like MVC structure and was a breeze to setup. Plus a big advantage is that the JSPs were so simple that they could be built completely by the end users using Interwoven.
[ February 21, 2002: Message edited by: Thomas Paul ]
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seems that we haven't come to the definite conclusion: what is a better view: XSLT or JSP. And for good reason. Neither is perfect. Today I was reading about Velocity template engine, and it looks cool. Here is one opinion "Why Velocity is Better Than JSP". I would still prefer XSLT for specialized tasks of XML querying because it was specially designed for this purpose. For all other purposes, Velocity would work better. And it does work with Struts, then why all this talking about Struts+XSLT?
Maybe I am missing something? For unknown reasons Frank did not mention template solution either, even though his WikiFootSteps were noticed on WebMacro site
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would like to point out that Cocoon uses XSLT extensively but still finds in necessary to define a JSP-like XSP process to carry out logic too hard or impossible in XSLT.
Bill
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why do I think JSP is a superior solution?
1) It is simpler in a Java environment to use Java. Why require your staff to learn an additional language when the additional language is not markedly superior and is very complex?
2) The JSP can simulate an HTML page with specialized markup. This makes it easy for non-developers to do what they do best... markup pages. How would a graphics/HTML expert work with an XSLT solution?
3) Performance will always be superior with a JSP solution because the underlying technology is servlets.
 
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Why do I think JSP is a superior solution? (snip valid reasons


Well, first of all, I wanted to let you know that there's at least one more person who understands both technologies Me.
I once worked for a company that wanted to place all of it's web content in XML and then use XSLT to translate that content into standard html, or html that was specially formatted for blind people so they can use their screen readers more effectivly (Until you've listened to a screen reader try to read you Amazon.com's home page you have no idea how important it is to reformat the page for a reader)
We also wanted to take the same content and morph it to WML so it would be viewable on PDA's and WAP phones.
As Tom mentioned before, Speed was a big issue. Using xerces and xalan to translate every page hit was a mess. We did a lot of checking to make sure that we only translated the page once because the XSLT translation was SLOW. On the plus side, it was easy to concatenate several XLS files together to make custom pages from component pages. On the minus side, speed speed speed.
But then again, there's no guarentee that we were doing things in the best possible way. It could very well be that we were all new at this whole XML/XSL/XSLT thing and that we wern't writing very optimized code. But it sure did seem that JSP's were WAY easier to work with than XML. And JSP 1.0 is WAY WAY easier to deal with than 0.9 was.
Now I use XML for property files, ant build files, and OFX message sets. I use JSP for dynamic presentaion.
So, I guess we still all agree. Let's go have a beer.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
XSP: I must be missing something. As a passionate follower of D.Hofstadter, I admit that turning Java into a template language triggers some deep warm feeling inside me, but practically... What is so good about mixing XSLT and Java code?
Look at this ugly example from Apache Cocoon site:
<p>
   Good
   <xsp:logic>
       String timeOfDay = (new SimpleDateFormat("aa")).format(new Date());
       if (timeOfDay.equals("AM")) {
           <xsp:content>Morning</xsp:content>
       } else {
           <xsp:content>Afternoon</xsp:content>
       }
    </xsp:logic>!
</p>
There were two beautiful, well-designed languages, Java and XSLT. This is neither Java, nor XSLT. This is like to add salt to your tea. :roll:
How are you going to debug all this?
And what are reasons to put Java code in XSLT "as is", well, not exactly as is, now "<" sign has to be escaped as "&lt;" ? There are extension functions, designed specially for this purpose. The Ugly Example Above can be written as
<p>
   Good <xsl:value-of select="user:greeting()"/>
</p>
much cleaner.
Where greeting() function is defined in a separate file, pure 100% Java...
public static String greeting () {
   String timeOfDay = (new SimpleDateFormat("aa")).format(new Date());
   if (timeOfDay.equals("AM")) return "Morning";
   else return "Afternoon";
}
- to be tested and debugged with any available tool...
Not to mention that extension functions can be used where "Java markup" cannot, like in attribute values:
<xsl:sort select="user:getRank(name)"> or something.
So why do we need this Molotov cocktail? :roll:
[ March 16, 2002: Message edited by: Mapraputa Is ]
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ugly stuff, ain't it? Problem is, no matter how you try to extend HTML, you end up with the same thing: a ghoulash of presentation code mixed with application/object-access/server-side code, all in the name of standardizing on the browser.
Realizing that you, my sweet, are only moments away from rebutting your own argument, it still eludes me why so many people find XML compelling.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Map Wrote: Maybe I am missing something? For unknown reasons Frank did not mention template solution either, even though his WikiFootSteps were noticed on WebMacro site..
Tricky one, this. I like the template approach, and use it at many levels in a typical complex project. I have yet to use one of the major web templaters (WebMacro, Velocity, FreeMarker etc.) for the main user-interface of a large job, though.
Part of this is political; JSP is part of J2EE, and XSLT is XML - and both are easy to sell to technical management. Part of it is laziness and fear - and it's the same reason which keeps me from using JSP as pure presentation - it's so easy to throw together a JSP, embedded code and all, but moving that logic out into custom tags or resources available to a templater is a step which is a little harder to take.
All this is a little strange, though. In regular java code I'm an avid refactorer, duplication-remover and framework-builder. I can only offer the notorious difficulty of testing web look-and-feel changes; without a trustworthy test harness, I'm much less likely to refactor, so all that crud stays there.
 
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ugly stuff, ain't it? Problem is, no matter how you try to extend HTML, you end up with the same thing: a ghoulash of presentation code mixed with application/object-access/server-side code, all in the name of standardizing on the browser.
Um... Are you talking about server-side code?
Because if to think about it, client-side HTML is pretty well organized, all orthogonal aspects can be accurately vivisected and separated (in the spirit of aspect-oriented programming.) We have CSS for visual representation and scripting languages for interactive behavior. Both can work against HTML that "doesn't know" that it is being styled or scripted: both CSS and DHTML can address HTML tags by names, P A IMG or whatever. Then, if you specially design your HTML to be styled and scripted, you can add "class" or "id" attribute to almost each tag (where it makes sense) and write styles/scripts for abstract classes of HTML tags, or for one particular tag. You do not even have to pollute your HTML, you can put styles and scripts in separate files and include them with <script> or <style> tags. In this mental framework HTML tags become abstract logical units of information, independent of style and behavior.
There are only two problems that HTML with all extensions cannot solve.
First, set of tags is fixed, you cannot add your own (actually you can, but browsers will ignore them). This is from where XML started to be. New tags were intended mostly as a tool to express semantics.
Next problem, most important for our conversation: how to combine data and HTML markup?
Currently there are two choices, "data driven" and "HTML driven". To see an example of the first approach you do not need to go too far: this very UBB employs it. The program consist of data flow with hard-coded
System.out.println ("<p font='Arial' size='+1'>" + "some data here" + "<//p>");
In UBB case there is its Perl's eqivalent. Now if we want to slightly change UBB appearance, we need to find corresponding place in Perl program and correct it! Ha! Nothing more will be said about it :roll:
"HTML-driven" approach is when we have an HTML file with "holes" in it, HTML processing engine reads the file, find holes and put data in them. This is essentially what server-side disunited xSP family of scripts (JSP, ASP) are doing, this is where other template engines can be used and this is what you call "a ghoulash of presentation code mixed with application/object-access/server-side code". Ugly? Maybe. But what alternatives do you see? If we do not provide markup for each element of data, we simply rely on some default presentation mechanism without any way to affect it, no?
Realizing that you, my @#$%^, are only moments away from rebutting your own argument, it still eludes me why so many people find XML compelling.
This is the most mysterious statement I read last weeks.
Which my argument I am only moments away from rebutting? I have many arguments, which one do you mean, oh better Canadian than all Canadians?
And how the first part of your statement, the one before comma, is connected to the last? Do you foresee XML meet the same problems HTML has now? But XML processing model is totally different from HTML processing! Theoretical foundations of it were laid out in Roman Jakobson's famous "Poetry of Markup and Markup of Poetry" work. Current state-of-affair is reflected in this paper.
"Why so many people find XML compelling" is a very interesting question, but it is tangential to this discussion, I am afraid. Do you want to start a new topic?
 
Thomas Paul
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What a great conversation this was. Amazingly, a year later nothing much has changed.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic