Scriptlets Can Be Better Than Tags

On JavaServerPages...

There is a powerful movement against scriptlets and in favour of custom tags. But there are plenty of problems just with understanding a page that makes extensive use of tags. (Never mind the performance issues.) Sometimes it is simpler=better to use embedded scriptlets.

Tags make you think the page is comprehensible to HTML/XML authors. But it just looks a bit more like HTML - if the tags do processing then you still need to understand the processing to understand the page.
Scriptlets in a page can normally be puzzled out within the page. To understand what the tag does you may have to look elsewhere.
Tags try and fit the hierarchical structure of XML. But the things we do with them often require branching - which doesn't fit a hierarchy very well. For example, a common requirement is for an if-else, or switch-case section. With tags these get implemented by an if-A tag followed by an if-not-A tag, which does not communicate the intent nearly as well.
Tags make debugging hard. Scriptlets are inlined in the generated java code, so if there is an error you can easily track down the line in the java file and see what went wrong. But tags are very hard to understand in the generated code because:
- The tag instance will have some meaningless generated name.
- The same tag instance may be reused multiple times within the method.
- Parameters are frequently passed to the tag by name - so you cannot tell by looking at the code exactly what they refer to.
- The tag implementation may make use of state such as request attributes - but this is not apparent in the generated code because it is hidden inside the tag code.
- The tag library has probably been compiled with optimisation, so if you have access to the tag source, you won't get a line number to tell you where it failed.
Tags are hard to develop. The constraints on the tag developer are not immediately obvious. And tags don't form part of the normal line of development, and so are unlikely to get refactored much.
When tags are used to create HTML elements, you can only supply the attributes that the tags support - not the attributes that HTML and JavaScript support. ie Tags limit the functionality available to your HTML author. (Encountered with fine-grained struts tags, but also with larger-grained tags according to the discussion below).

I would lump together a lot of this wisdom as the following "Don't do small-grained tag libraries". IMHO this is where almost every effort to build a tag library that's been released into the JSP community has gone horribly wrong. I think that instead tags should represent larger-grained reusable bits, either domain specific (like an Account Tag that can render an Account nicely and in a common way) or general things like a generic Table Widget. We've had a lot of success both inside IBM and in our customers in encouraging large-grained tag libraries -- they're a bit harder to build, but they sure make your JSP pages look nicer...

KyleBrown

The big problem we have had with high granulaity tags is that you end up having to parameterise them really heavily to allow variations in their behaviour. Many of the page authors we have given high grained tags to have continually said "I want to get inside the tag and twiddle with it a bit". One particular problen is that so much of the stuff needs to be conditional code - e.g. show this if the customer is registered already but not if they are a guest, and we have found that page authors want to alter the conditions. As this goes on, we either end up adding yet more parameters (i.e. arguments and config files) or split to the tags up into little bitty tags that are a pain to use. In some cases, this all gets so horrendous that the page author is effectively programming anyway (albeit in our "config and arguments" language). In some cases, we just had to abandon the whole thing, then, and shove scriplets in there so that, at the very least, the programmer can sit next to the page designer and twiddle with the conditional stuff on the fly. Unfortunately, we have found, then, that neither large grained tags nor scriptlets allow the page designer to work satisfactorily without continual appeal to programmers. -- AnthonyLauder

Yup. I've seen a lot of what you're describing too, Anthony. However, we've had some success with turning the problem around. Whenever it seemed like we needed an if statement in the JSP we looked really hard to see if we couldn't turn it into a different JSP <include> tag that was provided by the Java Bean. That idea (of using the old OO trick of substituting if..then statements with what is in effect polymorphism) eliminated a good number of the tricky bits. It didn't get rid of all of them of course, but it made things a bit simpler. Did you (or anyone else) ever try the same thing? --KyleBrown

Hummm ... I'm not sure I understand this. Maybe if I give you an example of a problem, you could help me solve it with the <include> technique. Imagine (actually, this is an example from a real system I worked on) we want to display a customer's order details on a web page. Now, we could make an "order details" tag to do this. But, some page designers have stated that if the customer doesn't currently have an order, then nothing should be displayed for this tag, others have demanded that it displays "Your order basket is empty", yet others have demanded that it displays an empty table with a specified number of blank rows. Unfortunately, loads of other conditions were slowly piled on top (for example, whether or not to display a "delete order" button even if the order was empty, and whether or not to allow a "save order" option for a guest (rather than only registered users)). I couldn't work a way around this using tags, and ended up using scriptlets instead to handle all the conditions. Can you rescue me from scriptlets with a tag solution? It would make my life much easier!! -- AnthonyLauder

Whenever it seemed like we needed an if statement in the JSP we looked really hard to see if we couldn't turn it into a different JSP <include> tag that was provided by the Java Bean.

If we are going to use included elements to insert various reusable bits into pages, then why wouldn't it also be simpler to include an Account page than to use a coarse-grained Account tag?

And is it necessarily simpler to move the decision about which page to include (essentially a presentation decision) to a bean instead of making it explicit in the main page? From Anthony's example, it seems that it may not be.

GrahamJenkins

But, some page designers have stated that if the customer doesn't currently have an order, then nothing should be displayed for this tag, others have demanded that it displays "Your order basket is empty", yet others have demanded that it displays an empty table with a specified number of blank rows. Unfortunately, loads of other conditions were slowly piled on top (for example, whether or not to display a "delete order" button even if the order was empty, and whether or not to allow a "save order" option for a guest (rather than only registered users)).

The purpose of tag libraries is to provide easy access to a consistent toolbox of components. It appears that the designers did not want a consistent toolbox - each had different desires. Perhaps tag libraries were not appropriate here. Alternatively, perhaps your designers needed to be taught to desire consistency!

The question is not is it simpler to make the decision in the page, the question is "who is the right person to make that decision". Large-grained tags encourage the idea that the HTML person should be removed from that decision. A second person (a Java programmer) should concern themselves with the decision.

See http://www-106.ibm.com/developerworks/library/j-webdata/index.html for a comparison of DB code in scriptlet versus tag.

But that's a horrible example from both cases. Database access does NOT belong in JSP's. It belongs in Domain or infrastructure classes. Neither approach is worthwhile. It's like comparing the relative benefits of walking over broken glass or hot coals...

CategoryJava