Friday, February 24, 2006

JSTL - What's the point?

I've been taking a look at Web related stuff in Java lately. Nothing too complex, just your basic Servlets/JSP. The general concepts behind these web frameworks (ASP[.NET], PHP, Ruby etc...) are all similar. The book I'm reading (Head First Servlets and JSP) has a nice way of explaining the components of the Java system. It starts with the simplest way to accomplish your goal, then shows what's wrong with it and finally how to improve upon it.

First you got your basic requests hitting a Servlet that does some processing and spits out HTML to the client. Nice and simple, but writing all that HTML code within the Servlet is horrible. Enter JSP. JSPs can contain the presentation (HTML). So now your requests hit a Servlet that does the processing after which it redirects to your JSP which has all the HTML code. Now there's a nice separation between code (Servlet) and presentation (JSP). But the JSP is pretty static. What if the presentation needs to be dynamic and depends on the processing done in the Servlet. Enter Scriptlets. These are code segments within JSP that can make the page dynamic. Great... you get nice dynamic pages now, but your presentation is cluttered with code. Enter JSTL (Java Server Tag Library). This is a tag library which is to replace those scriplets. So instead of code you have 'html like' tags.

This is pretty new to me, so I was trying to understand the rational behind it all. The progression made sense from Servlets to JSP to Scriptlets. But somehow the point of JSTL was completely lost on me.

What is the logic behind separating presentation from code? Apart from the "MVC pattern"/"loosely coupled principle", it is also to accommodate designers and coders. Designers can work on the presentation and not have to deal with code. But when you look at JSTL, its core tags are <c:if>, <c:choose>, <c:forEach>, <c:set>, <c:remove> etc... It's just replacing code statements with tags. The "logic" is still ingrained within the presentation. It is still code, just with tags, instead of java. How is this any better for designers or code maintenance? Somehow this made no sense to me.

ASP.NET has the right solution for separation with web controls. You can place these components within a page. These are plain tags like <asp:DataGrid>, <asp:Textbox>, <asp:Labels> etc... They are just responsible for rendering plain html. The logic to decide WHAT they render is placed in a 'code behind' page. Complete separation of code from presentation. Designers don't need to see any logic disguised as tags. I've heard of Java Server Faces which is something that's similar to this thats come up recently. Rahul can expand on it. But I can't believe JSTL was considered a solution at some stage.

1 comment:

camel said...

Mohnish,
You're right that JSTL basically replaces scriplets with the JSTL tags. They also introduced an expression language (EL), which works with the JSTL.

But I think the JSTL was meant to be a base framework, allowing developers to extend and write their own tags. They're called "custom tags", and they can be pretty useful.

For example, I can write a tag that handles the logic for displaying a set of page number links. Then the web designer just needs to know how to place [foo:pagination style="xyz"/] on the page, and voila, the pagination comes out. Or, you could log an advertisement impression with a simple tag like "[ads:logImpression position="${pos}"/]. Then the code behind this tag can do whatever it needs to do -- in this case, log an impression to the database. The former example results in HTML output, and the latter doesn't.

(I had to use [ and ] above instead of less-than and greater-than - blogger wouldn't let me enter less-than and greater-than!)

There are some frameworks built on top of servlets/JSP/JSTL that provide higher-level custom tags, such as Struts and JSF, as you mentioned. Components such as "DataGrid" as nice for rapid development, but if you need to customize that component, the built-in tags may not work well. (I don't know much about DataGrid in particular, as I'm not familiar with .NET)

--chris (at indeed)