JSP Technology -- Friend or Foe?

Segregation vs. integration

The primary purpose of presentation technology is to allow a separation between content and presentation. In other words, business logic units (presumably in some programming language like C or Java) don't have to generate data in a presentation-specific manner. Data, or content, is returned raw, without formatting. The presentation technology then applies formatting, or presentation, to this content. The result is an amalgam of data surrounded by and intertwined with graphics, formatting, colors, and logos.

Look at the examples in Listing 1 and Listing 2 to see at a glance the difference between raw content and content combined with presentation technology.

Listing 1 shows raw content, with nothing but data, that could be used in a variety of ways.

Listing 2, which is much more complex than the one above, shows the same data wrapped in presentation technology and ready for display in an HTML-capable browser.

While the content in Listing 1 is clear and easy for the uninitiated layperson to both use and understand, the content in Listing 2 is very specific to the task of display in a browser. It is tricky to extract data from it or manipulate it for any other purpose.

This fundamental difference, the process of segregating content from presentation instead of integrating the two (at least until the user needs the information), is the basic premise of any presentation technology, including the JSP technology. Further, any presentation technology that does not accomplish this basic goal does not truly accomplish the goal it was created to achieve.

Work vs. rework

Besides the separation of content and presentation, another measure of a presentation technology's usefulness is the amount of rework that it eliminates. The divergence of presentation and content enforces a divergence in the roles of those developing the content. A programmer can focus on the raw content presented in the examples above, and a graphic artist or webmaster can attend to the presentation. A slight overlap of roles remains, however, in the process of taking the presentation -- or markup -- designed by the artist and applying it to the content the programmer's code delivers.

In the simplest case, the artist supplies the markup, and the developer provides code and also plugs the markup into the presentation technology. The application is "started up," and the content magically becomes a user interface. Of course, as we all know, development rarely ends there. Next come revisions and changes to the interface and new business rules that must be coded. This is where the true test of the presentation technology's flexibility comes into play. While it is usually simple to update the raw content being fed into the presentation layer, rarely can the graphic artists easily edit their original work. Changes to the presentation layer are common (we've all been victim to marketing departments changing this or that). So now a problem arises: what do the designers change to tweak their work? The original markup language page they gave to the developer? Probably not, as that page has most likely had custom tags or code inserted (JSP pages, template engines), converted to a Java servlet, or changed into something totally unrecognizable.

Often the designer must rework the original page and resubmit this page to the developer. Then the developer has to reconvert this page to the specific format needed for use in the presentation technology. Alternatively, the designer has to learn a scripting language or at least know that which areas of the page's source code from the developer are off limits. Of course, this is an error-prone, dangerous way to operate. Once you've determined that a presentation technology allows a clean split between content and presentation, you should try to ensure that a minimum amount of rework is necessary in order to make presentation changes.