JSP Technology -- Friend or Foe?
By Brett McLaughlin2003-03-07
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.
Tutorial Pages:
» A critical look at JavaServer Pages servlets as a viable presentation technology
» A bit of history
» The premise
» Segregation vs. integration
» Work vs. rework
» The promise of JSP technology
» Content vs. presentation
» Code vs. markup
» Designer vs. developer
» The problems
» Portability vs. language lock-in
» Mingling vs. independence
» Blurring the line between content and presentation
» Single-processing vs. multi-tasking
» HTML vs. XML
» Summary
» Resources
First published by IBM developerWorks
