• 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

JSP Vs (XML and XSL)

 
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I came to know that if we have model(or data to be displayed in page) encapuslted in XML file , We can display page using XSL files.
Advatages
-- Your middle tier can be nething J2EE/.NET (Flexibilty)
-- You can change presentation tier with more ease.
I have few questions regarding this.
-- In compared to above mentioned approach is JSP obsolete?
-- What's Java support for above approach?
-- Any tools in market that generate XSL fiels required from HTML screens? (Generally we do protoype in HTML pages)
Thanks
Manohar
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No replies??
common guyz ....
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using XSLT + XML rather than JSP has some drawbacks :
1. The transformation is quite expensive process comparable to compiled JSP to Servlet, so it might be slower.
2. You cannot use TagLib in XSLT, instead you have to create a template instead of TagLib. But XSLT language is quite annoying to use when you're building quite complex logic for you tag.
3. The integration with JavaScript is not as perfect as in JSP. As we know Javascript itself it's not really XML.
4. Your application becomes harder to debug rather than JSP.
Of course it has a lot of benefits also as you mentioned... in some cases it's nice to use XSLT and in other case JSP is still better. So my opinion JSP is still needed.
You can try StrutsCX tool, it's quite nice...
[ September 27, 2003: Message edited by: Amin Rais ]
[ September 27, 2003: Message edited by: Amin Rais ]
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Amin,
Thanks for your reply.

Regarding two points you mentioned as drawbacks,
Slowness -- I agree with this point.
Tag Usage -- If page is specifically meant for presentation , IMHO there should not be any complex logic.
The tool u menationed Struts CX , Is this useful for generating XSL files from pure HTML pages?

One more question....How one can handle Javascript in XSLs?
Any sugesstions or guidance is appreciated.
TIA
Manohar
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can understand what Amin said about complex logic. I had problem when I created a tag with XSL for displaying list of months and years. It's quite annoying with XSLT.. for example how can you display year 1900-2000 into listbox. since xslt doesn't have iteration.. except you put this number into source XML ? a lot of other examples especially the variable is only bound one time and cannot be changed, so i have to repeat a lot of logic.
 
Gus Mus
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Put your java script inside this :
<xsl:comment>
<![CDATA[
]]>
</xsl:comment>
But still have a drawback, you cannot use xslt inside it.
Or the best is to put the javascript in other file.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
performance: a lot can be done with caching (even precaching) compiled XSLT stylesheets and XSLT processors.
This can speed up your XSLT processing by a factor 100 or more.
taglibs: should be used mainly for presentation logic anyway, which can be expressed in XSLT.
Javascript integration: link in your Javascript instead of embedding it. Same with stylesheets.
Debugging: could be, but most XSL processors can provide extensive logging to find problems, and having everything that gets sent to it in an XML Document which you can log as a single entity makes logging actually easier.
I've done what you seem to be looking at last year Manohar, and came in contact which each of these points and found them to be little trouble indeed.
The performance was the biggest hit until I got my caching mechanism for precompiled XSL stylesheets in place, after that there was little or no performance impact (the XSL parsing was faster than the database operations and numbercrunching needed and those didn't take long).
The idea was to use a series of servlets to generate the XML, which forward the request (after placing the XML and the name of the desired stylesheet in the HTTP session) to a single central servlet which executes the XSLT processing and renders the output to the client.
The compiled XSLT stylesheets are stored in a Hashtable indexed on their filename, if one exists there it is used else a new one is compiled and put in the cache after use.
It was a quite simple mechanism, didn't implement timeouts and connection pooling (had some ideas for a next version but never got around to implementing those and the system was sufficient for the application as it stood).
I've not found reverse engineering tools to create XSL from HTML, didn't need them really (the HTML I produced was relatively simple).
 
Gus Mus
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right about caching, but caching only works for static page. For example there is one page to display the user information stored in DB. You cannot cache this, because it's different from one user to another.
I agree to use xslt as tag for simple / presentation logic only. Even like this I still have problem. For instance to fill one ListBox - List of years - with year 1900 - current year.
I think this logic should be placed into taglib - not in other place.
So tell me how XSL do it without taking this list of year from XML.
I trick it by using Recursive - like PROLOG does... but it's not convienence.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not quite. I don't cache the generated HTML, but the precompiled XSL.
This can then be reused to generate new HTML from different XML (as long as that XML confirms to the DTD the XSL expects of course).
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,
Thanks for ur replies.
I have one more query regarding XML+XSL Presentation tier.
I worked so far with JSP based presentation tiers. When I need to submit data using JSP i use JSP:setProperty '*' approach...
How one can handle using XML+XSLT approach?
Like If I want to update status of each order displayed in table (n rows- n orders - n statuses) , Is there any better way of doing thisd thing in XML+XSL approach rather than parsing request params in server?
TIA
Manohar
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
jsp:setProperty effectively does just that, it parses the request parameters to the fields of the bean.
You could write a similar mechanism yourself and use that as part of your framework, passing in an HttpServletRequest and an Object and classname, then using reflection to match method names to request parameter names (which is probably what the JSP engine does under the hood too).
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic