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:
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.
<!—- declare the directory that our decorators will be
<!—- decorate all page in our web application with “default.jsp” decorator (Decorator Pattern)-->
<decorator name="default" page="default.jsp">
<!—- include a panels in the main window. Create visual windows in a page (Composite Pattern)-->
<decorator name="box" page="box.jsp"/>
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:
<jsp:directive.page session="false" language="java" errorPage="/error.jsp" pageEncoding="UTF-8" contentType="text/html; charset=utf-8"/>
<!-- Some decorations here( header, page layout and so on)-->
<!-- includes decorated page -->
<!-- More decorations here( footer, copyrights and so on.)-->
</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.
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.