JSP, XSLT and Separation of concerns

I was reading on Apache Tapestry web application framework. It seems to me that the main advantage of Tapestry is this: HTML authors ("page designers") can use standard HTML editing tools and view the page in webbrowser -- without requiring any special edit tools and/or webserver along with that. Dynamic portions of HTML page are identified by a special attribute used with standard HTML tags. Because browsers ignore attributes that are not understood, these special attributes are ignored while viewing. Server side components replace/modify the tags with these special attribute to generate the dynamic content. This way, roles are very clearly separated. Page designers don't even need to know or use any special tags or scripts.

With JSP and JSTL, we can completely avoid scripts in dynamic web pages. But, still the dynamic webpages can't be edited/viewed with standard HTML editing tools/browser. We have to use a webserver. More importantly, page designer is not isolated from JSP tags. i.e., s/he needs to know/use JSP/JSTL tags for dynamic content.

How can we achieve Tapestry-like separation of concerns with JSP/JSTL model? I think that is where XSLT can help us. Page author uses standard XHTML editing tools and identifies dynamic portions of the page by special attributes (jsp:id?). Then, we transform the XHTML page using a XSL stylesheet. The XSLT sheet transforms the XHTML page into a JSP page. i.e., dynamic content writer writes a XSLT sheet that transforms page author's XHTML page into a JSP page. Contract b/w page designer and dynamic content author is list of special attributes and values of the same.

This transformation mentioned above can be done either at development time or at runtime. In development time transform, JSP generation occurs by a build step in ant or other make tool. The XHTML page is kept in the webapp only for future static content editing -- not for serving clients. In runtime transformation, XHTML page is translated by JSP page to put dynamic content in it at request time. We may use JSTL XML transformation tags in the JSP page (instead of XSLT). To make runtime XML manipulation faster, JSP container implementations may have to "inline" JSTL XML tags (i.e., specially compile JSTL XML tags instead of calling Tag classes) -- may be, generate XSLTC-like code in the resultant servlet? or is it possible to compile such a XSLT file (that transforms input XML into JSP) as a servlet directly?

Apart from separation of concerns, there is atleast 2 advantages I can see with this style.

  • As of now, a JSP page is compiled into one method in a servlet class. If the page is huge, at times the resultant JSP servlet's _jspService method reaches JVM maximum method size limit (which is 65534 bytes with JVM spec. second edition). At that point, user to resort to techniques like HTML-frames or using JSP include feature -- not a very pleasant situation. With transformation happening at runtime, we will not have any such limit (other than memory needed for keeping internal representation of input XML).
  • runtime transformation style may also be used to implement (messaging style) webservices. Such a webservice will be written completely in XML files. (no Java code at all).

Comments:

Post a Comment:
Comments are closed for this entry.
About

sundararajan

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Links

No bookmarks in folder

Blogroll

No bookmarks in folder

News

No bookmarks in folder