Discussions

JSPs allow you to separate front-end presentation from business logic (middle and back-end tiers). It is a great Rapid Application Development (RAD) approach to Web applications. A new series of articles on TheServerSide.com provides a hands-on tutorial explaining how to develop modern Web applications today using JSP technology.

I find this to go radically against my own experience. JSP is probably the worst choice if you need a very stringent separation between presentation and business logic. The fact that you are embedding Java in your pages mixes dangerously those two extremes. When you do a Home look up of an EJB in a Web page, how separate are your two tiers?

Not mentioning the risk that the HTML designer might unsuspectingly alter lines in your Java code, and reciprocally.

Don't get me wrong, JSP pages are an incredible tool to set up Web sites, and I have used them myself with a lot of success and satisfaction, but I find they work best when the same person is in charge of both the front-end and the back-end.

If you are going to have distinct teams implementing those, templates, CSS and servlets are probably your best friends.

Well it is always debatable which methodology presents better separation between Presentation and business logic.

I work extensively with two approaches
1. JSP
2. XML/XSL.

While developing solutions using JSP we develop the procedure for the development. We develop the Web Pages first followed we start inserting taglibs in it. As you said once we insert tabligs it is risky to hand over pages to graphics designer for any modification.

In XML/XSL approach our whole web site have nothing but XSL (NO HTML at all). We have multiple XSL for a particular XML generated at run time. No JSP's and everything is handled by servlet. But again the problem of involving Graphics designer at any stage after initial design is near impossible in this approach.

So what are we missing ? The better development tools.

In absence of tools involving graphics designer in JSP approach is less risk compare to XML/XSL approach.

A look at model2 architecture etc might help. Also what this article states is that it can be combined with second generation(Java Servlets)solutions to give the required distinction between the layers.

The best approach, in my experience, is to use a templating
engine. Check out Velocity on the Jakarta site.
Basically, it let's Java developers embed Java objects into the page, and there is a very simple scripting language to access these variables. In fact, there's no java code on the web page!

Paresh Shah brings up the pretty good point of using Model 2/MVC architectures. Besides velocity, people might take a look at Struts from apache. However, for smaller projects, Struts seems to be overwhelming.

If you don't want to get into struts, writing building a simple MVC pattern/architecture is relatively easy, and it does a better job separating content than the traditional Type 1 architecture. It has the advantage of making apps more extensible (if well written), in that its very easy to add methdology. The down side is that, at least in my experience, development is a little slower.

Im certainly not saying its perfect, but its a start, as is templating engine.

I think there is more than one approach, which fits the task of presenting web data. It nearly always depends on the certain circumstances of the project. If you have a design company involved, which do the html-layout, then the best approach is to use a parser based approach as XMLC from enhydra for example. Next, if your data are yet in a xml format, the xslt with xsl is probably best. And last if your design and presentation logic is made of the same team, then use template approaches as jsp or velocity. A sentence to the template approaches. I think, if you use a strict layering as described in the sun blueprints and tag-libraries, your mixing of logic and design in a jsp is very small and therefore as good as velocity.

I concurr with the opinion that JSP provides marginal separation of presentation and business logic. In a Model 2 system, there is really no reason to have code in the views at all. Yet it's often impossible to avoid.

Tag libraries don't help enough. As soon as you run into something that the tag library designer had not already planned into the system (e.g. try formatting a floating-point number as a percentage with Struts) you have to fall back to scriptlets.

IMHO, XSLT is much more powerful and elegant solution for view templating. A friend and I have published an open source MVC framework called Maverick which allows XSLT (or JSP, or possibly other templating solutions) to be used for view rendering. The key points:

. You can configure an arbitrary number of successive transformations for each view.

. Your JavaBeans models are automagically adapted (using java reflection) to a DOM representation which the XSLT engine can use directly; there is no need to use JSP or XSP or anything else to generate XML. This also eliminates the overhead of generating and parsing XML.

. You can halt the transformation proccess at any step and output static XML for designers to work with.

. You can use the framework with JSP and static content as well. Both can be configured for XSLT transformations.

It's intersting that a BEAman (not Bahamen :-) ) is complaining about jsp.
Personally I was involved in projects that used various approachs for web/logic separation (webmacro, jsp taglibs, xml+xsl using Cocoon for WML/HTML output, etc) and I think overall Enhydra's XMLC approach is the neatest of all.

Question is: why BEA and other vendors do not try to provide an XMLC-like standard+impl?

I simply think it is 100% possible to achieve pure separation between business layer and presentation layer by using JSP taglibs. The problem is simple: people want to code web sites quickly and do not spend enough time designing the solution and then complain. You just have to know how to use the technology.

"Analyze this" dynamic table generation fragment which we have in our company:

No Java, looks like HTML/XML and designers do not have a problem with it. In the background it uses Swing TableModel to store table data and tag lib implementation uses it. It is generic 100%!

What's wrong! Hacking around. Even BEA in their Personalization and Commerce server infrastructures give you JSPs which contain huge fragments of Java code, instead of educating the community how to develop properly. Unbelievable...

I think this might be an answer - design, design, design...
and only then code - talk to your users a lot.

If you are willing to write application-specific custom tags, then sure, you can have complete separation. But how much time are your engineers willing to spend painfully hacking out tag libraries? Application development is going to be very slow going. Also, you're at risk of inverting the problem by pushing presentation logic into your business layers.

If you think general-purpose tags are going to accomplish everything you need, what are you going to do in your example if you want to change the formatting of certain cells? Lets say you want all negative numbers to be colored red. What are you going to do?

Another problem with taglib-based systems is "templating" of the sort where you define common look-and-feel elements (title, navigation, etc) in files separate from the content pages. Examine the Template Tags in Struts. It works but it's incredibly akward, and it gets orders of magnitude more so if you want multiple layers of "containment".

XSLT addresses the templating/containment issue nicely because successive transformations can simply "wrap" the output of the previous step. And the featureset is rich enough to provide all the manipulation of presentation elements you like.

WebWork, unfortunately, suffers from both a thin tag library and a neat but nonstandard way of accessing beans (you can't use jsp:useBean). The consequence is that when you have to fall back to scriptlets (which is often), the code is especially ugly. I wrote a large web application using WebWork and found that (for the reasons I mentioned above) it just didn't do a very good job of keeping code out of the views. Now I'm in the proccess of rewriting my app in XSLT (using Maverick, of course) and I am much, much happier.

XSLT also does not fully address application specific formating logic - same issue that has been attributed to JSP taglib implementations. Let's face it - even in the old client-server GUI systems these issues were purely application specific matter. Period. No remedy - there will always be application specific business rules even if they deal with purely presentation.

Regarding JSP taglibs what we need are dynamic Java backed up HTML equivalents in JSPs - dynamic tables, dynamic hyperlinks, dynamic check boxes, selects, etc. They shall look the same just have one or two more parameters for addressing where dynamic content shall be taken from.

So where to put the code for making the cell red? In the tableRowGenerated event listener of the table tag.

First, let us set aside stupidity of using HTML for what it was not designed to do.
Second, let us look at the established methods of the desktop, web and mainframe development.

As the result, one can see that component based model works just fine for the UI development on various platforms and architectures. This model allows for all this features that one strives for such as layout, styling, event handling, IDE support, 3rd party components, custom components, composite components and so on. Now tags are the components for the JSP. It is possible to create IDE that will allow for easy and efficient creation and utilization of tags and JSP to build web applications. Therefore, it is just a matter of time before we will see such an IDE.

On the other note, while XSLT is powerful mechanism it is very much generic, which means that it is costly performance wise. Moreover, one has to generate XML first to use XSLT and one needs something like JSP or persistence mapping tool to do that. In addition, there are even less good tools for web application authoring using XSLT then using JSP.

So are you suggesting that the presentation logic of "all negative numbers in table X should be colored red" should be placed in the tag code? What about designers who use the tag that don't want coloring, or want the color to be blue, or want the numbers to be italicized... I could go on endlessly with the number of presentation options.

It is *NOT* necessary to generate XML to use XSLT. Just as <jsp:getProperty> and <jsp:setProperty> use java reflection to access bean properties, the Maverick framework uses java reflection to build a DOM facade of an arbitrary graph of JavaBeans (your model). The XML generation/parsing step is completely omitted, and all transformations (except the serialization at the end, of course) occur on DOM trees. Between this feature and XSLT precompilation, an XSLT-based web application should perform quite reasonably. And soon we will have bytecode translet compilers which should be even faster!

I don't want to sound like I completely discount JSP, but there are two myths I would like to disperse:

1) JSP provides good separation of presentation and business logic.
2) XSLT is too slow to be used in the real world.

So are you suggesting that the presentation logic ... should be placed in the tag code?

> ...

No! I suggest tag to be a component with events and such. So however wants to color whatever just provides an event handler that just does so. This event handler is not a part of JSP.

> It is *NOT* necessary to generate XML to use XSLT.
> ...

Well, this is quite neat! I was not aware of this. But still XSLT is generic hence in principle slower.
BTW: Does reflection come chip? But anyways one can alleviate reflection with generation of code.

>I don't want to sound like I completely discount JSP, but there are two myths I would like to disperse:
> 1) JSP provides good separation of presentation and business logic.

The way one uses JSP can provide any degree of separation.

> 2) XSLT is too slow to be used in the real world.

So we probably need to see some benchmarks JSP versus XSLT. Can it be done as the part of the Maverick project?

In my opinion, when you use XSLT you just transfer complexity from JSP into XSL!
Your Java data objects become XML data representation and all your layout, formatting and style issues slide from JSP into XSL.
And once that is done you will need XSL components, XSL inheritance, reach XSL script and so on to infinity.

Jeff,
With regard to your WebWork comments:
The tag library may be thin, but it is constantly evolving, and is definitely "good enough" for most purposes. I personally have found that the core tags fill pretty much all needs.

Why you want to use "useBean" I don't know; the WW tags fill exactly the same need, but with a cuter syntax :-) Nevertheless, if you want to the valuestack, which the WW tags wrap, is always available to use by scriptlets (which I'd never use myself, but if you want to you can).

As for using scriptlets, I've found that all those cases where I'd want scriptlets are solved by either
a) finding the design error (very common)
b) putting it in a JavaBean and use the "bean" tag
So it aint a problem.

And as for using XSLT, I'd say the largest problem with it is that it's non-intuitive for most people to write declarative code. That and performance. I haven't worked with XSLT much myself, but these two drawbacks keep coming back in all discussions around XSLT, on various lists.

I'll certainly agree that XSLT can be abused, and a lot of stylesheets are arcane tomes :-) However, when used simply (matching only on the document node), XSLT looks pretty much like JSP:

<xsl:for-each> works just like an iterator tag
<xsl:value-of> works just like a bean property extractor tag (additionally you get nice syntax like this: <input type="text" value="{propName}"/> rather than having to put tags inside tags... yuck).
<xsl:if> is the equivalent of the usual <ifGreaterThan>, <ifNotEquals> type tags but has a more elegant (and powerful) syntax.

If they choose to stop there, there is no reason why designers should have any more trouble with XSLT than with JSP+tags, and in fact the pages look pretty similar. The parallels go further when you consider that Maverick can present your JavaBeans as a DOM tree, therefore <xsl:value-of> really *is* a bean property extractor. The advantages of XSLT are that a) you have a lot more power and flexibility at your disposal when it is convenient and b) you don't need to have the live site running to do development. Static xml substitutes nicely for the dynamic input.

For WebWork (and Struts), I offer these problematic use cases (all of which I pull from a real-world example):

1) Some JavaBeans (which ultimately originate in the EJB system) return a floating point number which I want to present to the user as a percentage.

2) I want to greenbar a table: two rows on, two rows off.

3) I have a table of numbers. All negative numbers should be colored red. Numbers between 0 and 25 should be colored yellow. All numbers greater than 75 should be green.

How would you solve these problems in WebWork? Maybe you could write beans to use with the <bean> tag, but a) that requires java code development for simple presentation logic and b) the <bean> syntax isn't especially intuitive or pretty. I think in most cases scriptlets are easier to understand and write, but we may differ in this opinion :-)

Ok, the Struts people are going to say that they have <greaterThan> and <lessThan> tags. All I have to add to cause problems is any sort of mathematical operation which needs to be performed on the number before comparison. The custom tags just aren't that powerful.

BTW, I do think the ValueStack is cool, but it's quite akward to use from scriptlets. This is the nice thing about <jsp:useBean>; when you have to fall back to scriptlets, there is relatively little pain involved.

I find that most people can't play with xml/xsl ... let alone web page designers. It's all about roles... I personally use WebWork (the best framework IMHO out there as it is small abstracts a powerful concept in a small package). We have recently integrated webwork's valuestack with OpenSymphony formtags too.. (http://www.sourceforge.net/projects/opensymphony) so forms are not a problem...

The thing is that we're all trying to reinvent the wheel and come up with "my framework is better than yours" and what have you...

I for example, try to use what's good out there and integrate/build components as needed. But I try to focus, on the following question... "Can my people work with this if I'm not around???" ... If the answer is no, then it doesn't go in.

I have been thinking about releasing a set of tools in an integrated form to guide the clueless... It mainly consists of Webwork+OS-Sitemesh+OS-Formtags+OS-TransformTags ....This combination provides pull hmvc, great separation of content and code, automatic page decoration for layout, "pagelet" support, and on-the-fly jsp-xml transformation...

BTW, All of the features presented by Maverick are easily implementable (in less then a day) in webwork as extensions, including the pipeline...

And to answer your 3 questions...

1. outer "formatting tag"
2. any xslt-transform tag with a predefined set of "utility" xslt's (since you can't expect the designer to deal with this)
3. same as above.

Jeff,
Thanks for your comments. They are very valuable, and important, and I'm sure you're not the only one wondering about these things.

Here's how I'd solve your proposed problems. But first of all there are some decisions one must make. The one I have made for me is: coding is done by coders, and it is done in Java code. No scriptlets. This gives that all extra web-design code (as the cases you have shown represent) must either get help from a coder, use pre-defined JavaBeans, or do the coding themselves. In my experience these various solutions have a natural temporal flow: in the beginning of a project the designers need help all the time. In the middle some JavaBeans are refactored to cover common needs, and thus handles more cases. In the end, the designers have enough example JavaBeans to be able to copy/paste one that is similar to what they need at the time, and modify it to solve their problem. And this is just for the first project using WebWork, or any JavaBeans/reusable/refactorable framework. The second project can then build upon the first one, especially with regard to the JavaBeans that have been found to be generically applicable to a particular set of problems.

Now to your given use cases:
1) Use a formatting JavaBean. Initially you would probably do it the direct way:
<webwork:bean name="Percentage">
<webwork:param name="value" value="ejbdata:status"/>
Status: <webwork:property name="result"/>%
</webwork:bean>
This particular pattern (bean/param/property) is a common solution to all custom formatting.
After some time has passed in the project you will notice that the above bean can be generalized into the following:
<webwork:bean name="Multiplier">
<webwork:param name="factor value="100"/>
<webwork:param name="value" value="ejbdata:status"/>
Status: <webwork:property name="result"/>%
</webwork:bean>
and thus you now have a bean that covers more special cases, so your needs for custom coding is less.
The situation where some initially seemingly custom code has to be very case specific, but later is found to be a special case of more general code, is very common. YMMV.

2. Not sure what "greenbar a table" means. I'm guessing you want to do a table where two rows are green, then two are white, then two green, and so on. Let me know if I misunderstood this one.

For this problem you could solve as 1, but I have a neater solution that unfortunately doesn't work with the current dist, or even CVS, because I'm working on it Right Now. Anyway, I'd use the new iterator generator tag like this:
<iterator:generator id="tablecolors" values="green,green,white,white" separator="," count="-1"/>
<table>
<webwork:iterator name="mylist">
<tr>
<td bgcolor="<webwork:property name="tablecolors@next"/>">
<webwork:property/>
</td>
</tr>
</webwork:iterator>
</table>
This will render a table as outlined above.

3. See 1. Similar solution, and which can also be generalized if you think about it (=converting values based on ranges).

So, all these cases can be handled by the bean methodology. Yes, some coding has to be done, but I definitely prefer that to writing scriptlets, and as stated above the need for custom coding typically decreases as more generalizations of JavaBeans are done. YMMV of course, as this is very project and use case specific.

To conclude, yes I see your point, but I choose to solve it in a way that gives good results in the long run. Using scriptlets is the quick way, and I might do it myself for prototyping purposes, but is probably not a good decision for large long-lived projects.

I think the meaning of this is quite clear to anyone that looks at it, and I submit that this is easier to read and write than your <iterator:generator> code. I confess that I have trouble groking how that works, and I have a pretty good programmer's understanding of WebWork.

Furthermore, in XSLT, neither of these tasks required the assistance of a Java engineer. It didn't require the designer to stop designing, walk over to someone else, and wait while they interrupted their current task to code up a bean. Maybe the frequency of this sort of disturbance would fall off over time, but it would be worst at the critical beginning stages of a project.

IMHO, one of the best characteristics of XSLT is that it doesn't have to be complicated. Simple XSLT is not much more complicated than simple JSP. But it offers an enormous amount of room for designers to "grow into".

BTW, I wish some of the Velocity people would jump into this discussion, because I have a feeling that their syntax for the greenbar would be even more elegant.

To the guy who said that all the features of Maverick could be implemented in a day as WebWork extensions: Maybe you should set down the crack pipe when using the computer.

Jeff,
This is very interesting, as it seems we just have different opinions about what is easy and what is not. Which is cool.

First of all, I thought your first example took a float in the 0-1 range, thus had to be converted to the 0-100 range before display. Your XSLT example does not do this, and hence becomes simpler. *rickard goes away and thinks* However, this is yet another case of having to think extra because someone puts a challenge in yer face :-) I just found the neat little class "java.util.DecimalFormat", which does exactly what you want. So, here's my updated example:
<webwork:bean name="java.text.DecimalFormat">
<webwork:param name="applyPattern" value="###.##%"/>
Status:<webwork:property name="format:*{ejbdata:status}"/>
</webwork:bean>
This would be ok for most designers too I think.

While scouring through the java.text API (recommended, boy are there lots of goodies in there), I found a neater/other solution to 2):
<webwork:bean name="webwork.util.Counter" id="colorcounter">
<webwork:param name="last" value="4"/>
<webwork:param name="wrap" value="true"/>
</webwork:bean>

That said, all of this is not really relevant since all cases could be accomplished in both WebWork and XSLT using existing functionality. The interesting point is of course what to do when that is not possible. In WebWork you write a bean. Do you write code in XSLT, or write a bean too? If coding in XSLT, what language? Not Java I guess. And then we're back to my choice: all code is done by coders and in Java. And note that I mean the "coder" role, and not "coder" person, since a person primarily doing webdesign could very well be a coder too. It's that this could be the case, but in many of these discussions the definition of "coder" and "webdesigner" often are thought of as actual people, rather than roles.

I see you have been busy! The ability to call non-get/set property methods wasn't in the last version of WebWork I used. I remember at the time wanting to use java.text.NumberFormat but was unable because it didn't fit the standard JavaBeans conventions :-)

I will grant that you have removed the *need* for scriptlets, but I don't like the reliance on Java programmers for presentation logic or the fact that designers are going to have to get cozy with the javadocs for a wide array of beans. I think we're going to have a difference of opinion regarding the aesthetic virtue of bean methodology; I am not fond of the way one "programs" the beans, especially with the perl-esque reliance on special characters. "format:*{ejbdata:status}" thrills me not at all. I'll admit that I've seen some pretty obscure xslt, but at least it's not necessary to use the cryptic stuff.

You ask: What do you do when it is not possible to express your presentation logic with XSLT? For truly patholoical cases, it is possible to write extensions and scripts in Java or other languages. However, the general nature of XSLT provides an enormous amount of leeway. As I rewrite my web applications I am constantly being astounded by the power and flexibility of XSLT, not just for web publishing but for data manipulation in general. It would be absurd to say that XSLT can handle any possible presentation logic, but I'm hard pressed to come up with problem cases. This contrasts sharply to my experience with taglib-based solutions - I started hitting brick walls right away.

BTW, the % in the XSLT format-number(ejbdata/status, '###.##%') does scale the 0-1 float to a 0-100 percentage.

Jeff
Today, for the first time, I decided to work on a fairly complicated dynamic web page offline instead of loading it in the app server. Halting Maverick at step 0 produced source xml, and all I had to do was run a command line xslt processor for each run-though. I am tickled at how easy it is; designers don't even need a running app server :-)

One more advantage of going with XSL approach is..The latest browsers have already started supporting client side transformation. This will relieve the load on server side.
But JSPs cannot be so easily rendered from client side..since we have already mixed up business logic like (EJB lookups etc) in JSPs..and atleast Microsoft is not going to do it (:-)!!

It is true that, practically it is the developer who maintains user interface. Either JSP or ASP will only provide means to separate the logic and user interface. They can't force the architecture.

You need some glue between HTML and the application logic code. If you minimize that interface then the graphic designer will be able to learn it easily. You also can use CSS along with JSP.

Incase of JSP, custom tags and Java Beans will give you the ability to minimize the code in JSP. But it becomes tedious to do the code. I find Struts framework to be extemely convinient since it hides all the tedious code. I am hoping that someday, somebody will create an IDE which uses Struts and simplifies developers task considerably. (Don't know if it is already there)

Another way is to use XML/XSL. But XSL is not popular yet and I don't think graphic designers will know XSL now. If they become experts in XSL then XML/XSL gives a better separation I think. (though I have not used it extensively)

Have any of you even tried to use xslt for content display? This is not a tool for designers! This is a tool for developers or document people who want to convert one tree into another. Our current system uses xslt for some presentation, jsp and tags, and here are my feelings:

1) when debugging I always ask myself, "does the html I am seeing come from the xml, the stylesheet, or the jsp?"

2) why would I even want to mix the previously mentioned 3 content sources just to get a result?

3) jsp allows scriptlets therefore people will use them and the jsps will be a mess. ("oh yeh, dont worry, just do a quick fix and put a scriptlet here that does that thing you want")

4) there is no consistent way to manage page flow without a Struts or Barracuda like web-tier framework

I have been studying Struts and Barracuda. They solve alot of problems. Turbine, Velocity, and a host of others also exist. Try struts if you want to work with Tags and jsp. Try Barracuda if you want to work more in an OO development project appending tree fragments into larger trees. If I had my way we would be using Barracuda, but everyone here is jsp crazed ;^>

Just to let everyone know that I am now jobless. Our top level management blew away our VC on a new marketing campaign, nobody bought us, and we didn't have any customers. But I know we built a great team and we had a cool service - all great things come to an end I suppose. I'll be moving away from Munich and probably on to London in May/June.

With the JSP 1.2 spec, you can specify JSP Tags as XML. So combining XHTML with JSP XML tags, your JSP actually becomes a XML document.

Thats an interesting notion - JSP is an XML document.
This sort of opens up interesting possibilities. One, we can use several XML technologies(DOM, XSLT, etc..) very easily since a JSP is an XML document.

I will be interesting to know if anybody has experimented with JSP 1.2 and XHTML combintation.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.