Igor's Blog

Using SiteMesh versus Struts Tiles

by Igor Stoyanov

I needed web-application integration system to aid in creating the many pages of the web site for which a consistent look/feel, navigation, and layout scheme is required. Such frameworks are Struts Tiles and SiteMesh. While Struts Tiles are wide spread used and known, SiteMesh is an open source web-page layout and decoration framework and web- application integration framework, which is very powerful but not so popular.

Although, I still have some thought about my decision not to use portlets (at least for now), I am more than sure that choosing SiteMesh rather than Struts Tiles is not the right but the only decision than someone who has worked with both technologies could choose. The reasons are more than many but there are some that were very decisive. Some of the main reason is that SiteMesh is much easier to configure and use (less typing and easier to understand). Using Tiles, you need to have your forwards go to a "tiles page" versus the direct JSP. SiteMesh takes the approach that your page (your JSP) doesn't even know or care that it's being decorated. Using Tiles, each individual page you want to go to has to be associated with a layout - Major pain! Every time you create a new JSP that you want to forward to, you have to create another tiles definition and associate it with a layout and forward to the Tile page (versus the JSP).

The problem with most of the available frameworks for solving this type of business requirement like Struts Tiles is that they are either platform- or framework-specific. When you're using Tiles for decoration, you have to create tiles definition in tiels-defs.xml. Inside of your struts-config.xml while declaring forwards, you will have to use these tiles' definition instead of actual JSP.

The easiest possible solution is to let each of your web applications create plain HTML content without knowing about how it is being decorated, and only then have something else choose and apply appropriate decorators. This is precisely what SiteMesh does.

Although, SiteMesh is ideal for use with J2EE applications, however it can be integrated with server-side web architectures that are not Java based such as CGI (Perl/Python/C/C++/etc), PHP, Cold Fusion, .NET etc...

SiteMesh intercepts requests to any static or dynamically generated HTML page requested through the web-server, parses the page, obtains properties and data from the content and generates an appropriate final page with modifications to the original. This is based upon the well-known GangOfFour Decorator design pattern.

SiteMesh can also include entire HTML pages as a Panel within another page. This is similar to a Server-Side Include, except that the HTML document will be modified to create a visual window (using the document's Meta-data as an aid) within a page. Using this feature, Portal type web sites can be built very quickly and effectively. This is based upon the well-known GangOfFour Composite design pattern.

My experience with SiteMesh was incredibly positive and I would not look for any alternative framework anytime soon. The installation and the set up of SiteMesh includes:.

· SiteMesh is based on Java, J2EE, and XML and depends on filters, a very useful feature introduced in the Servlet specification 2.3, so we have to inform our web application about the SiteMesh filter. Adding the following lines to web.xml can do this:

<filter>

<filter-name>sitemesh</filter-name>

  <filter-class>

com.opensymphony.module.sitemesh.filter.PageFilter

  </filter-class>

</filter>

<filter-mapping>

<filter-name>sitemesh</filter-name>

  <url-pattern>/*</url-pattern>

</filter-mapping>

Here we are telling the container that all requests to this web application
should go through PageFilter. The PageFilter class is part of sitemesh-2.1.jar, which you can download from the SiteMesh downloads page. Once downloaded, you should copy
sitemesh-2.1.jar to the /WEB-INF/lib folder.

· Create a decorators.xml file in the WEB-INF folder like this:

<!—- declare the directory that our decorators will be -->

<decorators defaultdir="/decorators">

    <!—- decorate all page in our web application with “default.jsp” decorator (Decorator Pattern)-->

<decorator name="default" page="default.jsp">

          <pattern>/*</pattern>

</decorator>

    <!—- include a panels in the main window. Create visual windows in a page (Composite Pattern)-->

<decorator name="box" page="box.jsp"/>

</decorators>

The decorators.xml file is used to define decorators for your application. In this file, each < decorator> element defines one decorator. The name attribute is used to define a name for that decorator, while the page attribute defines the JSP page that should be used for decorating. The <pattern> child element defines when a particular decorator should be applied.

The last thing to do in order for SiteMesh to work is to create the decorators. The most important elements in a decorator are:

<?xml version="1.0"?>

<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" 

xmlns:c="http://java.sun.com/jstl/core_rt"

    xmlns:fmt="http://java.sun.com/jstl/fmt_rt"

xmlns:decorator="http://www.opensymphony.com/sitemesh/decorator"

    xmlns:page="http://www.opensymphony.com/sitemesh/page" 

version="1.2">

    <jsp:directive.page session="false" language="java" errorPage="/error.jsp" pageEncoding="UTF-8" contentType="text/html; charset=utf-8"/>

<html xmlns="http://www.w3.org/1999/xhtml">

   <head>

<title>

        <fmt:message key="webapp.prefix"/>

<decorator:title default="Structure"/>

     </title>

<decorator:head />

  </head>

<body>

    <!-- Some decorations here( header, page layout and so on)-->

.......................

<!-- includes decorated page -->

        <decorator:body />

<!-- More decorations here( footer, copyrights and so on.)-->

        .......................

</body>

</html>

Of course, this is just the basic but I think that even this could show
how easy, straightforward and in the same time very powerful is the
SiteMesh framework. I implemented everything that I wanted very easily
for my web interface without any compromises. I just wish that all
tools and frameworks that I use are so simple, easy to use and
intuitive like SiteMesh.

Discussing the implementation of a user web based interface using JavaScript, CSS or Java Portlets.

by Igor Stoyanov

Note: This blog entry was before AJAX era. It sounds funny reading it today, but I would say it was kind of advance at the time when using javascript was considered evil.

Properly done web page design could be very important for the success of a given web application project. There were a couple of alternatives here which includes different compromises between portability, user satisfaction as well as performance issues. One possible way of implementing user web interface was using a new java specification for building web portals, called portlets. After very basic examination of this technology I decided not to use it for a couple of reason:

1) A request to the server is post every time a user wants to minimize, maximize or do something with the appearance of a particular portlet. This makes the overall performance of the web site to appear not very satisfactory. As an example I could give the new Loyola web based system – LOCUS. I don’t know if the provider, PeopleSoft, had used portlets but the site responding in such a way. Even for very simple operation as expanding of a tree structured menu, which doesn’t need any processing by the server, a request to the server is made and the whole page should be loaded again. This makes their web site looks very slow and a user experience is not very satisfactory, especially if the user uses dial up internet access. Since, I want a user to fill the web site very alive and responsive this was a major issue against using portlets. However, I suspect that later in the project I could encounter some transactional and other issues related to a web portal to be achieved in not so elegant way as if I decided on using portlets on first place. I have to come back to this particular choice later in the project in order more fully to estimate the benefits of using or not using portlets as web interface framework.

2) Another side of using portlet is that as a new technology, there are many different implementations and portable issues related with that.

Because of all stated above, I decided on using CSS and JavaScript as primary user interface technology. Although JavaScript and CSS are not very portable among different browsers and some of the users could disable JavaScript, I decided on using them only for web interface operation related to the feel and look of a web page. This would make the web site look more responsive for the users and overall more users would be satisfied than having problems with the web site.

In the process of implementing the web interface, I succeed in achieving my goals about the look and feel of the web interface. I believe that working with JavaScript together with CSS was sati factorable for me and the combination of these two technologies could enable you with the ability to implement very powerful features for your web site interface.

I used JavaScript and CSS for minimizing, maximizing and deleting of a different box window. Also, the state of the page layout and the different box windows are stored as cookies, so that every time a user go to the web site, he/she we see the same page layout that he/she left before closing of the web browser.

However, I didn’t implement with JavaScript any essential function concerning processing any user information. Even if JavaScript is disabled, a user would be able to use all major functions of the web site; just the experience of using this web application would be a little less satisfactory.

As a conclusion, I would like to say that looking at other very popular web portals like http://my.yahoo.com and Road Runner using JavaScript, CSS and other not so portable technologies like Java applet, Macromedia and so on are very heavily presented in order to make user interaction very fulfilling. Thus, I believe that I made a good choice with JavaScript but I will see how it would integrate with Java Server Faces in the later phases of the project.