| By Alexey Yakubovich, Alex Maclinovsky | Article Rating: |
|
| March 9, 2005 12:00 AM EST | Reads: |
29,608 |
The latest trend in information portals and Web applications has been to build complex Web pages. To present large amounts of information and functionality without compromising usability, designers have imposed a clear structure by grouping related elements together. Such cohesive, visually distinct constructs, or compartments, often with their own presentation logic, have become an essential feature of complex Web applications.
The first half of this article introduces the notion of compartments as a fundamental concept that pervades the layers of many Web applications and stages in their lifecycle. It defines compartments and analyzes their structure and key characteristics. Then it will examine the existing presentation layer technologies for building compartmentalized appli-cations and demonstrate their weaknesses.
The second half of the article proposes an architecture and framework that directly support design and development of compartmentalized applications and improve their performance. It demonstrates how the use of this framework improves developer productivity, facilitates reuse and yields more flexible and maintainable applications.
Introducing Compartments
Figure 1 includes screenshots from some well-known Web sites. These sites all have a different look-and-feel from one another, serve different purposes and address different audiences. However, they use the same approach to organizing and presenting a wealth of information in regular, visually distinct blocks or compartments. Such compartmentalization is common throughout the Web; a quick survey of a number of prominent Web sites shows that many of them use easily identifiable compartments as primary structural elements.
Definition
Despite visual and structural diversity, all compartments share fundamental elements. We define
a compartment as a rectangular area on the page that presents dynamic content and has the following characteristics:
- It has regular structure and layout
- It contains related content elements
- It's visually and functionally distinct from the rest of the page
- It has internal presentation logic (i.e., layout depends on the content displayed)
- It behaves atomically within the page.
- On Travelocity - Great Getaways, Fare Watcher, Cruises & Vacations and Travel Tools.
- On FirstGov - Agencies, Information by Topic and In Focus.
- The grey left navigation bar on the BBC site because it's static
- "Find me the best priced trip" on Travelocity because it's static and doesn't have regular structure or presentation logic
- "E-mail This Page" on FirstGov and the round navigation buttons at the top of the Yahoo page (i.e., Personalize and Finance) because they lack regular structure or presentation logic.
The Programs & Campaigns (P&C) Compartment presented in 0 came from one of the systems developed by the authors. It will be used as an example in this article.
Typically a compartment consists of a header, footer and a body. The header and footer together define the visual elements, including frame, background, title and global links such as "All Programs" and "All Campaigns" and the other elements that belong to the entire block.
The body consists of a series of contentlets, elementary units of dynamic content presentable on a Web page, separated by optional spacers or other structural elements. A contentlet has a number of core attributes: Name, Description, Image and Display Order. Additional attributes, such as Date, Type and Source, may be represented as needed for a particular problem domain or implementation. All these attributes are optional.
One important type of contentlet is a Content Reference, which adds another core attribute, a URL. Any dynamic content targeted to a compartment can be represented as a collection of contentlets.
In contrast to static page elements, a compartment has intrinsic behavior, which is governed by its presentation logic. Presentation logic is a set of rules determining how to render each contentlet, which contentlets are considered renderable and how to render the entire compartment, depending on the collection of contentlets it receives. Such rules may include:
- Lay out contentlet attributes in four columns in order - Image, Name and Description, Type, Date
- Consider a contentlet renderable if one of the core attributes is defined
- Remove the Date column if none of the rendered contentlet defines it
- Change the compartment title to "Programs" if all contentlets are the Type program;
- Remove the entire compartment if it doesn't have any renderable contentlets.
Role in Application Lifecycle
The role of compartments isn't limited to system design and construction. Normally, compartments are identified early in the development process and used to construct wireframes, capture functional requirements and design prototypes. They also play an important role in testing as a basis for individual test cases.
Presentation Technologies
There are a number of JSP-based technologies currently available to develop the presentation layer of compartmentalized Web applications. Portlets, different flavors of templates and tag libraries are commonly used. Each has inherent strengths and weaknesses.
Portlets are the most direct realization of compartments, but they can only be used in a portal platform. Using a portal platform is not always appropriate because of the cost, performance or technical limitations in the URL structure, as well as problems with bookmarkability, navigation, the lack of visibility by Web search engines, layout restrictions and other issues.
Template approaches like SSI, ColdFusion and Tiles2 make page layouts flexible. They help to reduce the complexity of JSPs by breaking them into smaller, more manageable fragments that can be reused between pages. This decomposition can be taken to the level of individual compartments. However, such a mechanism can only be applied to identical JSP fragments; it can't be reused for similar compartments. Although templates can simplify the maintenance of small JSP applications, advantages disappear as the number of pages and compartments on each page grow and developers have to manage thousands of individual JSPs.
Neither of these approaches addresses the rendering of dynamic content or the implementation of presentation logic inside the compartments, leaving the developer to rely on tag libraries.
Published March 9, 2005 Reads 29,608
Copyright © 2005 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
About Alexey Yakubovich
Alexey Yakubovich works as a framework architect at Roundarch, Inc. He received his PhD in mathematics in Moscow State University for research in mathematical logic, and has published more than two dozen articles in mathematical magazines. Alexey has spent 20 years in software development.
About Alex Maclinovsky
Alex works at Sun Microsystems as the Engineering Manager for Sun SOA Governance Solution. For nearly two decades he architected and built distributed systems on enterprise, national and global scale. Alex specializes in SOA Infrastructure, Security and Composite Applications. He blogs at http://blogs.sun.com/RealSOA/ and can be contacted at maclinovsky@yahoo.com
![]() |
Alex Maclinovsky 04/07/05 01:15:09 PM EDT | |||
I understand how immodest it is to leave feedback to my own article, however: |
||||
![]() |
Jack C. Holt 03/30/05 11:49:23 AM EST | |||
I just tried to send email to the email addresses for the authors and my email server is telling me that those email addresses don't exist. How can I reach the authors? |
||||
![]() |
Jack C. Holt 03/30/05 11:34:31 AM EST | |||
Unfortunately, I noticed some typos in this article. For instance the white paper for Vitrage is actually at http://www.roundarch.com/features/vitrage.html. I would have appreciated a link to where I can download the code Vitrage code. |
||||
![]() |
Marina Prikaschikova 03/22/05 09:54:46 AM EST | |||
>The reason custom tags lead to such complexity is that |
||||
- Performance of Java Compilers: An Empirical Study
- Java Kicks Ruby on Rails in the Butt
- Ulitzer’s Amazing First 30 Days in Public Beta
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- REA Is Where RIA Becomes the Norm
- Why an Application Grid?
- Will Ulitzer Dominate News Content on The Web? -Gartner
- Clear Toolkit 4: The Road Map
- Profiling Netbeans within Amazon EC2
- Java Persistence on the Grid: Approaches to Integration
- Performance of Java Compilers: An Empirical Study
- Java Kicks Ruby on Rails in the Butt
- Developing Rich Client Applications Using Swing - II
- The Right Time for Real Time Java
- Xpress Suite Adds Automatic Java to iPhone Conversion
- Ulitzer’s Amazing First 30 Days in Public Beta
- Initial Thoughts on IBM Acquisition of Sun Microsystems
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- Maximizing Java Performance with Bespoke Programming
- REA Is Where RIA Becomes the Norm
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- What's New in Eclipse?
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate






































