Feel of JSTL

[Henri Yandell <ba...@generationjava.com>]

I've just done a small set of JSP pages using various tag-libraries and
thought I'd post comment on the things that felt 'wrong'. I did
almost everything in Dreamweaver MX.

Architecture
------------

My architecture is designed to be very simple and easy for designers.
Unlike things like Struts etc, my aim is to have it feel like a normal
web-site, but still maintain a certain level of MVC. I believe that
obeying the page/tag metaphor for a site will allow designers to
understand a system more easily. I'm also attempting to use only
JSP+Taglibs.

So my design consists of a JSP View, and a hidden [denoted by starting
with an _] JSP Controller. Java Beans are used as the Model, but I'm
wondering how well a Map/List construct would work.

There were three pages in total. The first page was a choose page on which
the user selects an entity from a drop-down. The aim being to see details
about said entity. The second page is an _load page which loads the entity
in from a database and stores it in the session. The third page is a
details page which shows various information about the entity in a set of
tables etc.

A hidden field is used to tell the _load page to goto the details page,
this allows the _load page to be somewhat reusable.

To do all this, I used the JSTL core/sql taglibs [fmt would probably have
been used too if it was an external site], the String taglib [for
str:join, which I haven't committed yet], the Unstandard taglib [for
instanceof] and the Xephyrus Data Structure taglib.

Problems
--------

My first problem is on the first page. It has to contain a bit of SQL to
load the select box. This is essentially a problem with my MVC
implementation. My V always comes before the C, and not vice versa. In
Struts this isn't a problem because a C is always first. I suspect I need
to just fix this by putting a C in front of the first V. I imagine I would
use the Xeph Data library to store a collection of the results in the
session.

Next up is the _load page. I prefer these to servlets due to the
development method. No restarting of the web server and it fits the page
concept as a hidden page. Designers are happy with hidden fields, so why
not hidden pages.

This page is basically a lot of <sql:query>, <jsp:useBean> and <c:set>
tags. I hit the following 'pain's in here:

1) Loading just one row. If I'm not going to use forEach on an sql result,
I can't find a neat way of accessing it. It seems to come down to either
doing:

  <c:set var="row" value="${result.rows[0]}"/>
or
  <c:set target="${entity}" property="ID" value="${result.rows[0].entity_id}"/>

both of which feel a little clunky. I can't think of any logical solutions
though, just pointing out something I think designers are likely to
complain about.

2) Too much sql.

This is again an architectural issue. My _load page loads lots of things
in and tree's them all off the 'entity' bean. It might be better for
myself if I chain _loads together and invent a tag which hides the
complication the hidden goto field will have to go through.

3) Indexed properties.

I've mentioned this before. Basically I can't do:

<c:set target="${entity}" property="nercRegion[0]" value="${foo}"/>

4) Shawn's reference chapter.

This is a great resource with, for me, one problem. It doesn't cover the
the objects returned. So I don't know what is available in the
c:forEach varStatus variable, or what is available in the sql:query results
variable. Hopefully it's something a 2nd edition can resolve :) Or maybe
Manning will let Shawn produce a 2nd edition of just that chapter for
online viewing.

5) database NULLs break setting.

I found the following would crash when alertRow.ignore was database NULL:

<c:set target="${alert}" property="ignore" value="${alertRow.ignore}"/>

so I had to protect it with:

<c:if test="${not empty alertRow.ignore}">

Ignoring the crash, it would be nice if ${not empty alertRow.ignore} could
just be said as ${alertRow.ignore}, but I can see that that might cause
issues in the implementations, ie) how to know you are in boolean context.

6) <jsp:useBean> is not overridable.

While looping, I wanted to reset my jsp:useBean. The solution for this was
provided by Hans, use <c:remove>, however this doesn't seem the most
obvious solution. Would be nice if the JSTL folks could be given control
of the <jsp> tag library and start to improve it :)
<jsp:useBean .... overwrite="true"/>  is my obvious way.

7) <c:redirect> does not pass parameters on.

It would be nice if the <c:redirect> had a feature allowing me to push the
get/post parameters onwards. It's possible this may be there and I'm
missing it, but it would make chaining JSP a lot nicer. Maybe it would be
a feature of <c:param>:
<c:param/> would pull in all parameters.


Onto my display page. This is a basic page which the designer is intended
to work on [as was the choose page but not the _load page]. This is where
JSTL shines and I had only two problems.

1) <str:join> does not handle ${..} EL notation. Not a complaint, I'm just
being honest that some problems were in my own code :) Basically JSP 2.0
solves this and I expect JSP 2.0's arrival to herald a resurgence in
Taglib development. I really think that the arrival of JSTL-EL has
stagnated taglib development as it is such a pain to access the features.

2) Remembering to use value="${..}" and not value=".." in the unstandard
taglib's instanceOf tag. This is really an example of a generic problem I
kept coming across. I'm not sure if there are any easy solutions, but it
would definitely be nice if the 'JSP Compiler' [ie web server] was able to
warn me in this case. I expect this to be the cause of many designer's
problems with EL.


Architectural problems
----------------------

JavaBean models. These are a pain as they involve restarting the server,
or if .wars worked well, redeploying [which is still a slow feedback
loop]. I'd like to get rid of using Java for my model, but am unsure if
there's anything better/easier. It would be nice if I could define Structs
in the JSP to be honest. Basically an inline interface that would be
generated, have a dynamic-proxy set against it and put in the session for
me, all by the 'JSP Compiler'. I could use Maps, but I'm uneasy about
losing the strong-typing, and don't know if JSTL-EL even supports them.

Conclusion
----------

I think things are nearly there for a nice separation of developer and
designer. Dreamweaver is still a bit clunky, but is getting a lot closer
now and JSP is fast becoming an XML-syntaxed version of Velocity or PHP
[without lots of the painful programmer bits of PHP].

I know this ramble is largely opinion-based, but hopefully it contains
some items of interest. My wife is a designer, so much of my architectural
choices come from working out the simplest way to work with her, whilst
maintaining a high feedback loop, so it's not a big silver bullet, just an
explanation of the context in which I'm using JSTL.


Thanks for listening.

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org