Scriptless JSPs


In the last 2 years I’ve been working with CMS solutions. Actually creating Templates to display the content retrieved from the CMS.  So, basically we need to retrieve the content from the System. And having this content we need to apply some business logic to then diplay the content.

For presentation we use JSPs. In the basic archtecture we have the JSP as presentation, the classes with the business logic and the classes to access the data (via SQL or CMS API). As we are working with the CMS framework and we are working only the presentation, not with redirecting or something like that, we don’t use any MVC framework (Struts, JSF, WebWorks…). So, on the JSPs that will display the content we use the Business classes to get the content and display the content in the HTML.

LayersBefore

So, with this approach we had too many Java code into the JSPs, what is a really bad practice. Even having the Business Classes to encapsulte the business logic in the Java classes we still had too many java code in the JSPs. And this was causing too many problems for us because the anytime we needed to change a jsp to add a new logic more java code was added in the JSPs and they were becoming too much complex to maintain.

Then we started adding the JSTL into our project, it helped a lot avoid Java Classes, but as we are not using an MVC framework, we didn’t have a class responsible to make the information available to use in the JSP and for JSTL. So, we still need to have the Business Classes in the JSPs and set the expected content to be displayed in the pageContext to make them available to the JSTL. Well, it helped but we still had too many Java Code in the JSPs.

Then a guy from our team started testing a new approach to remove the java code from our JSPs. As, we were not using any MVC framework, what he thought: “Why not have a class that represents the page we are building that will be responsible to make the content expected to be displayed available to the JSP?” So, based on this, he created a Helper class, this class is called in the JSP and makes all information needed available to the JSP through pageContext attribute then they are available to the JSTL.

LayersAfter

Basically the only Java code we have in the jsp is:

<%

new PageHelper(pageContext).methodToMakeTheInformationAvailable();

%>

With this approach we could eliminate almost 99% of the Java code from the JSPs. As we were working with a old Application Server, we hadn’t the EL available in the JSP, we had it only for JSTL. So, when we needed to use our taglibs we needed to use scriptlets to pass the parameters to the taglib.

As benefits of using this approach we can list:

  • JSP with the minimun java code possible, that makes their maintenance easier and the jsp clear;
  • As all logic is inside a Java Class, we can JUnit test the helper class 🙂 so, we can test the if the logic is correctly implemented
  • As the jsp has more html than java code there was a redution of HTML bugs, like a unclosed div 🙂

But, for this approach works we need to discipline the developers to avoid the unecessary Java Code in the JSPs. For this, it is needed have someone (like a technical leader) to be responsible to do a code review and reject the code that doesn’t follow the approach.

So, that is just a simple example how we could make our jsps cleaner 🙂

Thanks,
Junior

Advertisements

2 thoughts on “Scriptless JSPs

  1. Java Code in JSPs is not necessarily a bad practice, as long as that code is concerned with “presentation” logic and not business logic.

    JSTL and other tag libraries tend to simply replace Java with another syntax that still allows developers to smuggle in business logic.

    What has worked for me and my team mates is to generate a ViewObject in the Controller and pass that on to the JSP that can then be very simple.

    ViewObjects can be subclassed and shared across various JSPs to reduce redundancy as well.

    The generation of the ViewObject is also easier to debug than a JSP.

    But, rather than write TagLibs and pass Strings around, we just use POJC (Plain-Old Java Code) and scriptlets to access ViewObject properties.

    No new lingo to understand, no new artifacts and dependencies, just Java and JSP.

    As for the MVC pattern, I see it as recursive; we treat the ViewObject as a Model for the JSP that acts as another (simpler) controller to generate another View, which delivers yet another Model and View to the browser, along with JavaScript controller code… and so on.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s