Questioning Jsp

Looking at JavaServerPages, I am not so sure it is worth the effort or overhead. The idea is to separate the presentation and implementation layers. Yet the presentation layer is so obviously a mapping to implementation structures is there any advantage over using clean Java (or whatever) code in the first place? The presentation layer looks like a giant attempt to do Java in another syntax that is supposed to be cleaner.

Using standard tag libs (JSTL), you can now get much farther in writing (almost) programming-logic-free pages than you used to. Seems like a big win to me.
Plus, what is the big overhead of JSPs when compared to directly putting out HTML from Java (Yuck!)?
- Java loses over Perl because it is so much harder to include a chunk of text. You can't run the String over a newline, and you always have to quote the quotes. Compare the HereDoc? for ease of use.
JakartaStruts and the ModelViewController philosophy can make things much cleaner.
The runtime overhead of JSP has been reduced quite a bit in recent versions of ApacheTomcat.

The answers are starting from the assumption that you'll be using Java, of course. Let's not start the language HolyWar again.

Using standard tag libs (JSTL)

But look at JSTL. It's just Java with a different syntax. A syntax that isn't as powerful as Java. Why bother? Is the code that much cleaner? Will page makers and programmers really be able to be separated for anything non-trivial? I directly output HTML from Perl code all the time. It looks more honest and simple than the JSTL.

...when compared to directly putting out HTML from Java (Yuck!)?

Please explain what the problem is with directly putting out HTML from Java.

Just try to give that Java file to your graphics/layout person and have him load it in MacromediaDreamweaver.

My experience has been that people who know HTML but not Java see JSPs as easier to modify than straight Java code. Someone in marketing has been lying to them. The only nice JSP feature I've encountered is that they are compiled on demand by J2EE app servers. -- EricHodges

I haven't used JSP, but I have used other templating languages. (In particular, lots of RubyLanguage rhtml.) These sorts of approaches don't make sense in all contexts, but they do in a setting where your client has an extremely visual conception of the web site, and you get handed stuff that abuses tables and generally doesn't care about that tidy SemanticWeb stuff that geeks like. Even with the spread of CascadingStyleSheets and the like, there's a lot of web design in the world that doesn't at all parse well on any semantic level, so it's a pain in the ass to try to program. You end up writing method and class names like RightColumnBlackSpacer. Ech.

So templates are good for keeping that garbage out of your code and on the presentation layer. It's tricky, of course, finding the right balance between what elements go in your underlying objects, and what goes in the template. But in the work I do it's really helpful. -- francis

My experience has been that the you don't keep garbage out of your code by using JSPs; you put code in your garbage. Instead of having all of the code in .java files, some is sprinkled in .jsp files. Refactoring and maintenance are more difficult as a result. -- EricHodges

It's certainly not a perfect situation; it's the best I can figure out with the constraints I have. When you get HTML documents that have tables nested six times deep, and layouts that get drastically rearranged every week or so, life is much easier if that garbage is kept in its own place. -- francis

I'm not familiar with Ruby and rhtml. How much code actually ends up outside of Ruby source code files in that environment? -- EricHodges

I don't think this stuff is that language-specific. (Perhaps somebody who's used both rhtml and JSP can share their experience.) When I write rhtml I try to keep the interaction with code to a minimum:

Iteration through collections
Calls to member properties that return variables that are strings, or other classes that convert intuitively to a string output

There's often the case of writing a special class to just to handle the more data-driven aspects. For example, if you have a page that needs to show the top 30 discussion threads, I'll probably create a class called DiscussionThreadCursor that handles querying the database.

It's difficult to find the right balance. Sometimes I let too much code into the template, and testing becomes a hassle, so I have to fix it. But I think overall it's the right way for me to do it. HTML is not structured data, not the way most web clients want it. HTML structure makes less sense than any other way of structuring graphical data. It's garbage. I don't want to try to write code that makes sense out of it. -- francis

I agree it's difficult to find the right balance, and I may be too absolutist in my dislike for JSPs in an effort to simplify that balance. I'm curious what you mean by "HTML is not structured data, not the way most web clients want it". Isn't HTML data structured precisely the way web clients want it, since web clients are HTML viewers? What other markup languages make more sense than HTML? -- EricHodges

Sorry, I was being unclear. By "web clients" I meant the people who pay you. Client as in customer, not client as in program. -- francis

One thing I should mention by way of comparison is that rhtml doesn't try to make Ruby look like HTML, with irritating little brackets around every statement. It's more like PHP in that sense than, say, JSP or ColdFusion. -- francis

The HTML used by your average web shop is not structured data

[Therefore Francis doesn't want to go near trying to do anything with it but spew it to the browser]

Put code in the HTML or HTML in the code?

Reminds me of the LawsOfCrap?.

My experience of JakartaStruts + JSP, and later JSTL with that too, is that it can be a little fiddly sometimes but it works and is clean enough - if you work at it. The code was almost entirely outside the JSP, the JSP was almost entirely outside the code.

My experience of HTML-fragments-in-PerlCgi? was that it's clean enough for me to work on, provided I stuck to the rule FunctionEmitsHtmlElement?. Sadly, nobody else needed to (or wanted to) change the HTML. Whether it would have been different if I'd used some templating library, I don't know. -- ma

Is it the right tool for the job?

JSP+stuff is a better tool than plain Perl, but then it's a bigger tool to learn. Plain JSP may be borderline simply because Perl is actually rather good at all this, and JSP and Java are both a bit clunky.

It seems to be a case of using bigger tools, needing to work with them for longer, but then getting bigger gains. -- MatthewAstley

Just try to give that Java file to your graphics/layout person and have him load it in MacromediaDreamweaver.

This is better?

 <c:forEach items="${paramValues.food}" var="current">
          <c:choose>
            <c:when test="${current == 'z'}"> 
              <c:set var="pizzaSelected" value="true" />
            </c:when>
            <c:when test="${current == 'p'}"> 
              <c:set var="pastaSelected" value="true" />
            </c:when>
            <c:when test="${current == 'c'}"> 
              <c:set var="chineseSelected" value="true" />
            </c:when>
            <c:otherwise>
              <c:set var="invalidSelection" value="true" />
            </c:otherwise>
          </c:choose>
        <c:if test="${invalidSelection}">
          <tr><td></td>
          <td colspan="2"><font color="red">
            Please select only valid Favorite Foods
          </font></td></tr>
        </c:if>

<sql:setDataSource

  var="example"
  driver="oracle.jdbc.driver.OracleDriver?"
  url="jdbc:oracle:thin:@localhost:1521:ORCL"
  user="scott"
  password="tiger"

If you have a SQL password in your JSP template, then that's probably a big CodeSmell.

Even with the bad JSP code above, I think I would say that a HTML designer would still rather edit that than a .java file with out.println's (out.println("<a href=\" + blah + "\">");). I only say bad because making your presentation call a database directly seems at best a worst practice (model 2 JSP design would never have this). Or the first example, where the choose/cset should have been done in java before the view is displayed (is 'z', 'p', or 'c' to determine if you have selected your favorite food a presentation detail? I would think would get back a friendly representation ${current.isFavorite}). JSP is ugly in many ways, but the above is a mischaracterization of the technology (though perhaps not of many programmers out there).

[What's bad about that JSP code? It looks typical of the JSTL code I've seen.]

The code above has clearly business logic in the JSP, where it should not belong. Besides, a straightforward rewrite of above as Java would still be bad OO. One can write bad code in any language and JSP is not an exception. Perhaps bad JSP examples are so common because until recently it has been quite hard to write good JSP code. When you're writing good Java, you're not doing everything in one method. When you're writing good JSP, you're not doing everything in one file, but move all business logic to beans and refactor repetitive JSP into custom tags.

Nobody mentioned the ugliness that happens when you have a compile-time or run-time error in a JSP. The error messages are not much help even to the programmer who wrote it, much less to people who edit HTML and don't know code. It seems like what happens is that the JSP is converted to a Java Servlet, which is then compiled and run. Once that happens, errors reported are related to the generated Java code and not to the JSP.

Also, if you write custom tags that generate any sortof presentation HTML, the HTML developer using MacromediaDreamweaver or a similar tool would not be able to see the page rendered properly inside the tool. --WillCardwell