webdeco is providing a dynamic decoration capability for JavaEE web applications. It is a flexible framework build around a Servlet filter. Using webdeco helps you to separate the use case code (markup and logic) from eye candy and reoccuring stuff.
I think most web pages, especially in web applications, consist of more than one visible part with different affinity to the real usecase.
As an example in this guide I will use a web blog application since that is the original use case WebDeco was developed for. The web blog has some use cases which are
Pages that are generated by these use cases have some differences but also a lot of similarities. See the lists below below. Every element listed in there is placed on a single HTML page.
| Element | Description | Affinity to use case | Occurs on which pages | Influence from use case |
| Site wide menu | The site menu listing the channels like "Blog", "Article", etc. | Not related to any UC | All | It needs to highlight the entry the user is in. "Blog" in this case |
| Tag cloud | Shows relative importance of tags on blog entries | Small use case in its own | All blog pages | None appart from show only on blog pages |
| Time list | Shows time intervals and count of blog entries posted in that time | Small use case in its own | All blog pages | None appart from show only on blog pages |
| List of 5 lastest entries | Shows the latest 5 blog entries and is supposed to be the entry point to the web application | Full use case | Only the latest 5 blog entries use case page | None |
| Show a single entry | Shows a single blog entry in all its beauty | Full use case | Only the single blog entry use case page | None, appart from links of other use cases pointing there |
| Show entries by time interval | Shows short entry versions grouped and sorted by time intervals in which they were posted | Full use case | Only the single by time list use case page | None |
| Show entries by tags | Shows short entry versions grouped and sorted by tags the got | Full use case | Only the single by tag list use case page | None |
Seeing that yet very short table with page elements generated and used by the listed use cases we get the finding that the elements can be put into three groups:
Use case content is content directly related to one single usecase. The lower 4 table rows fit into this category. Is is output that might be defined in the concept or user story describing that single use case. To keep our example user story for "Show a single entry" might be "Only a single blog entry's data is shown. Blog entry data is title, subtitle, message with media and links." In a MVC application a use case is addressable by a url.
Common page content is content that reoccurs on more than one page, mostly channel or side wide. I count menus, banners, clouds, etc into that category. It is just unusual to have a use case "show the menu" or "show the tag cloud" (except perhaps WAP content :-) ). So this kind of content is often dependend on the state of the use case but without knowledge of the use case itself. In a MVC application a common page content element is not directly addressable using a url.
Finally the template data is the skeleton that holds all these content elements. The choose of the template is often dependend on the use case called and sometimes on the response of that use case (e.g. use special css for blog entries having special tags).
WebDeco provides the glue to put all the elements together. The use case would be bound to an external url and called by the user. The WebDeco filter intercepts the call but let it pass to complete its work. Now it takes the outcome and searches its configuration for common page elements and a template to use. It assembles a new response with the template and passes the content of the use case and the common page content into that. As soon that has finished everything goes back to the user browser.