Last week I started a new project to bring a better music and radio experience to my company's customers. One of my tasks this time around was application setup and base configuration using our in-house application framework. This is the first time I have done the initial setup myself as all other projects I've worked on were ready to start building on.

In the last few apps I've helped develop, the Atomic pattern has been the primary JSP pattern used. This pattern uses distinct code components responsible for individual "modules" in the view. These atomic modules can thus be shifted around in the view and still perform their functions because they are not tied to a "place" in the model in order to work.

Before I go any further, let me drop some quick definitions for clarity. These words will be used in this manner for these meanings in the remainder of this post. The author makes no guarantee that anyone else uses these defs, but they are close to real-world and this is free after all.
View - the visible rendering
Module - an atomic portion of the view
JSP module - the code that represents a view module
Module definition - the configuration (usually in XML) of the JSP module
Decorations - Simplified here to mean parameters, attributes and flags that alter minor changes in the view. (Could be text transforms, toggles for list ordinals, etc)

Sharing Pain
Implementing this pattern in the past produced two extreme ends of the spectrum for me. On one end we have too few code components, basically JSP files, responsible for handling too much view. The components became massive switch cases of EL tags (we try to keep scriptlets out of the view-producing JSPs) that tried to cover, say, 3 or more ways a module could look. On the opposite end we took atomic units and made multiple levels of smaller code components responsible for the view. This produced an overwhelming number of files, mostly lower-level includes that rendered things like an artist name or image. The problem stemmed from creating JSPs that were trying to be reusable and extendable when they didn't really need to be either one of those things to meet the business requirements.


The happy medium
Before starting to write any code and just after I set the app core up, I decided that this time we should take a new approach. On this project I wanted to not just follow the standards we had in place already, but look at how and why we write JSP code. An Atomic pattern again makes sense due to the modular nature of what we're building. I also chose to change some precepts of other devs on my team that it really is OK to build JSPs that did one thing or two rather than "everything" or breaking them up into tiny fragments. But how to convince them?

The epiphany
I began to write a document outlining the project structure, conventions and why we should seek this happy medium. The hard part was how to find it. Thinking back on the previous projects and their SODs, it occurred to me that they were all missing one very important (and now obvious) thing: There were no guidelines for developing atomic units in JSP! No one had ever mentioned how to make the decision on how to write a JSP module, only what they would look like and where they fit into the app.

Clarity raises its hand
I was excited! I wanted to build a clean app and now I had the vehicle to describe HOW that could be done. A quick yes/no test would help the developer to decide wether the JSP module they are working on should do more than just handle its view.

It went a little something like this:
During development, and even refactoring at a later time, if it naturally fits to reuse one JSP module for another, by all means do so if you can answer yes to these questions:

Does it make sense?
For example, will the data will be represented in the same way excluding any decorations?

Will it happen quickly?
Will the work to build one JSP module or merge two (or more) be faster than the work to build both individually?

Are the view modules able to coexist in a single JSP?
If the views are drastically different, it may cause problems in implementation.

Can the module definitions work with a single JSP?
If modules are defined/configured differently and you need to use different methods or bean properties, you must answer no to this question.

Are view modules you want to merge context independent?
That is, can this JSP module that contains logic for more than one view work on any page without each view having to know which page it is on?

... and no to these:

Is this an attempt to make one module do "everything?"

Will it bloat the base code in the JSP you're starting with?
Nobody likes bloat, but what is it? In this case, bloat is not the code the modules themselves require, it's the handling code that surrounds them, helping to live in a single JSP module. If it takes more code to make your modules "fit" in the same space, you've got bloat. Break them up and use them individually.

Can it survive changes that alters the view of any given module?
Ah, so this one is key. If you are going to make one JSP module do the work of multiple views, keep in mind the requirements for the view modules can change on you. If the view requirements do change, read back through the list of questions and if your answers have changed- it's time to split it out into a new JSP.

Similarly, you can use the opposite approach to determine wether or not a JSP should be split into more than one JSP module.

With guidelines now in place, we'll see how development goes. I am hoping smoothly. In any case, I'll update on this topic as we go along in the process.