Are JSP tag libraries still relevant?


Figure 1
Figure 2
Figure 3

Figure 4



 Dump JSP tag libraries and switch to JSON.

 I often see development teams using JSP tag libraries when they shouldn't be. I wrote this post to explain why it's best to view JSP tag libraries as relics of the past.

 Most non-trivial web applications store data in a database on the server side. These applications need mechanisms that allow the clients (web browsers) and servers (e.g. Java application servers) to exchange data. Typically, either a) data needs to be displayed for the user (so, the client sends the look up criteria to the server and the server responds with the relevant data) or b) the user changes data in the browser and the client needs to submit the data modification to the server for processing and/or permanent storage.

 Until recently, most Java web applications have used JSP tag libraries as a client-side mechanism to extract data out of Java objects (JavaBeans) passed back and forth between clients (web browsers) and servers as part of the JSP/servlet paradigm offered by Java. (Note: JSPs are HTML files that get converted into Java servlets so that they can contain Java code for manipulating server-side Java objects.) In each case, the server responds with a new page (with embedded data), also known as a full page refresh.

 In 1995, AJAX came along and changed the full page refresh paradigm described above. AJAX allows for partial page refreshes and data exchanges between the browser and the app server without having to do full page refreshes.Since then, AJAX has continuously gained momentum with support built into popular frameworks like Spring (for Java) in v3.0/2010 and jQuery (for JavaScript) in v1.5/2011. 

 The data exchange format that works best with AJAX is JSON, since JSP tag libraries cannot be invoked unless a full page refresh is involved. There are several options for mapping between the server-side Java model objects (JavaBeans) and JSON, which can easily be consumed by JavaScript running in the browser. (Note: Since JSON is the literal representation of a JavaScript object, the conversion from JSON to JavaScript object is trivial.) The option I recommend and have been using is Spring MVC's @RequestBody and @ResponseBody annotations as part of the controller method definitions (which leverage the Jackson library for JSON processing) to automatically map JavaBeans to JSON and back (see figures 3 and 4). (The alternative is to use a proprietary framework like Direct Web Remoting or DWR, which I do not recommend for obvious reasons.)

 As a result, I recommend to most teams I consult with that it's best to abandon JSP tag libraries entirely in favor of a pure AJAX/JSON based approach.

 Here's a summary of the reasoning behind my recommendation to use AJAX/JSON exclusively (even for full page refreshes).
  1. Unless, you have a very simple application, you will likely need to support partial page refreshes using AJAX (rather than do a full page refresh each time that some data needs to change on the page). To do so, you need to map between Java objects (JavaBeans) and JavaScript objects (JSON) in order to exchange data between the browser/client and the application server. Therefore, it probably doesn't make much sense to support two channels for data exchange (JSP tag libraries for full page refreshes and AJAX/JSON for partial page refreshes). And if you have to pick one it has to be AJAX/JSON, since JSP tag libraries don't work for partial page refreshes. Hence, my recommendation to go head first with AJAX/JSON and abandon JSP tag libraries. But if you need more incentive, please read on.

  2. I have worked with teams that have analyzed the size of the data being shuttled back and forth across the network and found that JSON consumes a lot less network bandwidth than the JavaBeans/JSP tag library approach or even XML payloads. Their analysis seems to make sense to me since JSON is a bare bones pure text format without the syntactical overhead involved with XML or the rich object overhead involved with JavaBeans.

  3. Relative to the acrobatics required for manipulating JavaBeans using JSP tag libraries (see figure 1), the JavaBeans to JSON mapping is completely seamless with Spring MVC and requires no coding whatsoever (see figure 2). Whether or not you're using JSP tag libraries, chances are that you need to populate JavaScript objects with the data in order for the data to be consumed by jQuery widgets. In other words, the JavaScript object(s) are required in regardless of whether you use JSP tag libraries or not. Abandoning JSP tag libraries allows you to skip step 2 (see figures) and go straight to JSON and the corresponding JavaScript object(s) without having to muddle through the manipulation of JavaBean objects using JSP tag libraries.


Thanks for reading. I hope I've made my case adequately. However, I'd like to have your feedback, especially if you believe I've overlooked something.

Comments

  1. AnonymousFriday, May 24, 2013 at 2:27:00 PM EDT

    So how do you render the HTML part once you've binned the tag library?

    ReplyDelete
  2. AnonymousFriday, May 24, 2013 at 3:13:00 PM EDT

    your client side code figure 3 slide is wrong. You should be performing a GET

    ReplyDelete
  3. Puneet Singh LambaFriday, May 24, 2013 at 3:41:00 PM EDT

    Although I've specifically only advocated against JSP tag libraries in my post, by extension the JSP expression language (EL) and JSPs themselves no longer serve a useful purpose. And, as we know, Spring MVC makes it unnecessary to explicitly create servlets to handle the various URLs we wish to intercept. But perhaps that's the subject of a separate post. As for HTML rendering, I recommend you use HTML, CSS, JavaScript, jQuery etc for that. All we're doing above is replacing the data binding mechanism (JSP tag libs are being replaced with Java-to-JSON binding, courtesy of Spring MVC).

    ReplyDelete
  4. Puneet Singh LambaFriday, May 24, 2013 at 3:51:00 PM EDT

    I took the code snippets from a working example I created. And POST worked fine for me. You might be recommending GET in order to be REST compliant. However, many organisations don't allow data to be passed in the URL for security reasons. Also, the amount of data you can pass via a GET is a lot smaller than what a POST will permit.

    ReplyDelete
  5. Michael BSaturday, May 25, 2013 at 1:03:00 AM EDT

    "most Java web applications have used JSP tag libraries as a client-side mechanism"

    wait.. client-side? jsp-tags are part of a jsp page which are transformed into a servlets which are server side.
    http://docs.oracle.com/javaee/5/tutorial/doc/bnahe.html

    Directly returning json is a perfectly fine approach but as Anonymous points out you still need a way of describing how the data(JSON) should be rendered on the client, since bigger sites will have different layouts for different pages there will be repetitive code(html/js/control flow) that you should probably stick in a tag to keep it DRY.

    JSP-tag's and JSON are hardly competing technologies 'ditching' one for the other seems like a weird thing to contemplate.

    ReplyDelete
  6. Puneet Singh LambaSaturday, May 25, 2013 at 9:00:00 AM EDT

    Michael, JSPs were created as a client-side facility to allow UI developers to have one place where they could access data from Java objects (EL, JSP tag libraries) and place the data into the desired HTML elements all in one go. I've acknowledged in my post that JSP are converted into servlets -- that's how they are able to access data from server-side Java objects. Once you're got your hands on the data (via EL or JSP tag libraries or JavaScript) you still need to place the data into the desired HTML elements. When using the JSON channel, jQuery offers elegant mechanisms for placing the data into HTML. And, if needed, JavaScript can certainly be modularized into reusable code so that should be no challenge to the DRY principle.

    Some of my colleagues were also having trouble wrapping their heads around my recommendation. While other colleagues were agreeing with me wholeheartedly. So, I figured I'd write this post to see if anyone could point out a serious gap in my thinking.

    Thanks for engaging but so far you have not caused me to revise my recommendation. For now, the only exception to my recommendation that I can come up with is in the case of the Spring Security tag library. But I'm not done thinking through that one yet.

    ReplyDelete
  7. NomsSaturday, May 25, 2013 at 2:23:00 PM EDT

    Jsp tags are definitely useful where we want to make decisions based on session data . For example let us say i am storing user entitlement in session and i do not want certain data to be loaded / or want certain data to be loaded etc since i have access to session data i can so this easily in the jsp. Why delay it it page loads and make an extra ajax call for this ?

    ReplyDelete
  8. Puneet Singh LambaSaturday, May 25, 2013 at 4:41:00 PM EDT

    Noms, that's an interesting use case, but it doesn't necessarily imply a dependency on JSP tag libraries. Since the session is available on the server-side, the server-side code can either (a) inspect the session data and determine what to make available in the model based on user entitlements/authorizations/roles or (b) include the relevant session information in the model so that the client-side code can use it to make decisions on what data to display/hide. Option (a) should be the preferred option.

    ReplyDelete

Post a Comment

Popular posts from this blog

Milwaukee Appliance Hand Truck

Image
Milwaukee Appliance Hand Truck, leaning against my shed Also known as a cart or a dolly. The model is HDA700. I paid around $120 for it. Here's a list of the features. Wrought iron frame 800 pound load capacity 6 inch non-marking wheels (solid, non-inflatable, never go flat) Stair climbers to help move loads up and down stairs and curbs Padding to prevent the cart from damaging the appliance (this is the white strip in the picture above) Belt or strap that goes around the appliance to secure it to the cart and keep it in place Manual ratchet belt tightener, the buckle-like part at one end of the belt (more on this below) Belt tightener handle (this is the red handle in the picture above) to add more tension to the belt once the manual ratchet has been used to the tighten the belt  I recently used this hand truck to move a big ass 320 pound refrigerator out of my garage (where it was delivered) and up a couple of steps to the deck, up one more step through the doubl
Read more

My Experiments with the PICAXE 08M2+

Image
PICAXE 08M2+ I generally prefer to do things the hard way. For example, you can either microwave a frozen dinner or cook from scratch. The microwave option is a good backup plan, but cooking from scratch has far too many advantages, as I outlined in a recent blog post on the do-it-yourself way of life. In the electronics and robotics world, the analogy of cooking from scratch is to build circuits using a bare bones micro-controller chip (e.g. the PICAXE ) rather than a fancy board (e.g. the Arduino ). Therefore, once I get a circuit working with the packaged Arduino approach (e.g. this robot I built recently), I usually try to replicate the circuit using more basic components like the PICAXE. My decision to consider the PICAXE was influenced by Charles Platt's coverage of it in his awesome book Make: Electronics . But essentially, I am a minimalist and I want to see how much I can get done with a bare bones chip rather than a bulky board-based micro-controller like the Ar
Read more

Utility trailer buying guide

Image
Introduction I recently bought a utility trailer . (I'll explain momentarily what that is and why you might consider buying one.) Going through the process (research, preparation, purchase, registration, setup and maintenance) has taught me that it's not a simple endeavor and very little good documentation exists in the public domain (e.g. on the Internet). Hence, this post. Research In dictionary terms, of course, "to trail" means "to follow" (or to trace the path of a primary vehicle). Alternately, Wikipedia defines a trailer as an unpowered vehicle pulled by a powered vehicle. So, let's get acquainted with what a utility trailer is and why you might consider buying one. If you're a hardworking, blue collar American you probably already have one -- it's the back half of your pickup truck . Well not quite, but that's the reason Australians refer to a pickup as a utility vehicle. A pickup is characterized by the presence of a flat
Read more