Custom Tags as the Prevalent Choice
Custom tag technology has become the most prevalent tool in developing dynamic JSP user interfaces. It gained acceptance because it promised to separate the presentation from the content, eliminate Java programming from JSPs and let HTML designers use familiar tag syntax.

Tag libraries work really well in many cases, but become less usable in more complicated cases, particularly when JSPs need to implement the non-trivial presentation logic often required by compartments. That's why publications promoting tag libraries never go beyond the simplest examples3. Sun's implementation of Pet Store illustrates this point perfectly. Pet Store serves as a blueprint for building applications using J2EE technologies like JSTL tags, but the most complex table is limited to static columns and doesn't have any presentation logic.

A Real-Life Example
To see how this works in the real world, consider the P&C Compartment presented in 0 that came from an actual application.

The compartment is designed to present a collection of contentlets arranged in a one-column table, one object per cell. Contentlets are considered renderable as long as they have one core attribute defined. The following requirements should also be satisfied:

• Invalid and unrenderable contentlets should be omitted
• If no contentlets were rendered, the entire table with its header, footer, frame and background should not be rendered
• Visual attributes should be arranged vertically in the following order: image, followed by name, then description - if an attribute is undefined, it should be omitted.

• If an image is present, it should be rendered as the link
• If there is no image, the name should be rendered as the link
• The description is never rendered as a link.

The actual JSP code is too complex to be presented here although it's available online, along with a more in-depth analysis in the form of a whitepaper. This implementation would not be significantly simplified by using portlets or Tiles templates.

Using this approach to develop a page with 10 or more compartments will result in thousands of lines of JSP code, making it highly inefficient for implementing applications similar to the ones presented in Figure 1.

Why Tags Fail
The reason custom tags lead to such complexity is that tag libraries are designed to cover the basic HTML constructs like anchors, tables and forms.

They are effective when the layout doesn't depend on content. The later tag library extensions supporting loops, conditions and other control flow constructs inside a JSP (i.e., iteration, choice and choiceMethod) have very limited capabilities and poor expressive power for programming presentation logic.

In other words, tag libraries force developers to program in a primitive language that lacks clear structure and doesn't allow code reuse beyond simple includes and cut-and-paste. To complicate things, there are many incompatible flavors of this language, each with its own quirks and limitations. For example, BEA's netui-data library let one use choice statements only inside a loop, while a c:url tag in a JSTL doesn't support named anchors.

It has been firmly established that a JSP is not a good place for exercising imperative programming, be it java scriplets programming or tag programming. A new approach is needed that can solve the problem of developing dynamic compartmentalized applications effectively.

Success Criteria
How would you measure the success of this new approach? Previous analysis has helped formulate key criteria for its success.

1. Direct support for key abstractions from the problem domain - compartments, contentlets and Presentation Logic.
2. Produce clean, simple, easily maintainable JSPs free of any logical programming.
3. Use appropriate means to express different presentational aspects - let programmers implement logic and data manipulation in Java, while allowing Web designers to define visual design using familiar syntax and tools.
4. Facilitate both physical and logical reuse, allowing presentation components to be used in multiple places and combined into more complex ones, as well as reuse of common functionality through inheritance and delegation.
5. Increase developer productivity.
6. Ensure compatibility with a wide variety of existing J2EE platforms, MVC architecture and mainstream frameworks.
7. Remain complementary to existing presentation technologies, and allow combining them when appropriate.

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7
• Table 1