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.
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.
Basically the only Java code we have in the jsp is:
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 🙂