Posts Tagged ‘ SiteMesh ’

Webbit + SiteMesh = …. well, Webbit and SiteMesh

SiteMesh is now available for Webbit Server:

Tutorial here:

Running SiteMesh on AppEngine

Does SiteMesh work on Google AppEngine (Java preview)?

Short answer: Yes.

Longer answer: Yes. It does. So long as you check 2 things…

1. Upgrade

You need SiteMesh version 2.4.2 or greater. Earlier versions do not support AppEngine.

Download here

2. Disable static file serving

If you want decorators to be applied to static content (e.g. to .html files), the following needs to be added to WEB-INF/appengine-web.xml:

  <exclude path="**"/> 

This forces the static resources to be served by the Servlet engine, rather than a separate static web-server. Without this, the files served by the static web server will not be decorated.

Happy AppEngining.

SiteMesh 2.4 released

After a long wait, SiteMesh 2.4 has just been released.

This mostly consists of minor bug fixes and improvements.

OSCon: SiteMesh, SiteMesh, SiteMesh, SiteMesh

Just got back from the O’Reilly Open Source Convention in Portland. Fantastic conference – met lots of really interesting people (and the odd nutter).

It was a good conference for SiteMesh. It opened my eyes to two things:

# SiteMesh rocks. People who have tried SiteMesh, love it and don’t turn back. Their preferred choice for web framework changes, but SiteMesh remains constant.
# Our marketing sucks. Despite it being around for 5 years, most of the Java web app community have never felt the need to try it.

I was there to present a session on SiteMesh but a lot of other speakers beat me to it. It kept slipping into other sessions…

h4. Using AppFuse for Test driven Web Development, Matt Raible (details)

Matt gave an overview of the technology stack used in his AppFuse application. Despite having 5 versions of his app that use different frameworks (Struts, WebWork, Tapestry, Spring MVC and JavaServer Faces), all used SiteMesh. Good!

h4. Integrate: Building a Site from Open Source Gems, Erik Hatcher (details)

Erik walked us through the open source products he used to build his Lucene Book website and what customizations he made. The focus, of course, was Lucene and I learned a lot of great tricks about Lucene that hadn’t occurred to me before – such as using “sounds like” queries with soundex and indexing images by colors. I continue to love Lucene.

A great point that Erik mentioned was the need to become intimate with the projects you use. If you truely want to make the most of your frameworks, understand how they work, join the community and extend them.

Erik chose Tapestry to build the site but he also had Blojsom and some static content, so SiteMesh was useful to integrate these and he created some custom code to build SiteMesh decorators with Tapestry.

He pointed out that despite submitting this useful Tapestry integration to the SiteMesh project, nothing had made it into the SiteMesh release. Feeling embarressed, I committed his changes immediately, inadvertently breaking the build and providing great ammunition for Eric Pugh’s session on the importance of continuous integration.

h4. WebWork vs Spring MVC Smackdown, Matthew Porter and Matt Raible (details)

The basic plot was this… Matthew Porter was arguing why Spring MVC sucks and WebWork rocks. Matt Raible was arguing why Spring MVC rocks and WebWork sucks. The only thing they both agreed on was SiteMesh rocked. A fairly heated and passionate debate – great fun to watch. I would have opted for more violence though.

Matthew Porter got the final laugh when he pointed out that he compared the Spring MVC and WebWork versions of Matt Raible’s AppFuse framework and the Spring MVC version had about 25% (I think) more code, not including comments.


h4. The Evolution of Web Application Architectures, Craig McClanahan (details)

This was an interesting session where Craig compared the approaches taken by Struts, WebWork, Spring MVC, Tapestry and JavaServer Faces. He had done detailed research and, despite his heavy involvement with Struts and JSF, gave a very fair and objective view of the pros and cons of each.

This work could be useful for people evaluating which frameworks to choose and possibly could be overlayed with a guide based on values. The bottom line is there’s no single ‘ultimate’ web framework and depending on your needs and values you should choose the most suitable. I think it would be beneficial to all to have a guide indicating which values each of these frameworks are suited/not-suited for.

So, my question is this: Which values are more important to you when choosing a web framework and in which priority?

These are some example values that spring to mind: commercial support, testability (unit and functional), popularity, extensibility/customization, integration with other frameworks, rich widget support, REST friendlyness, simplicity vs magicness, AJAX friendlyness, learning curve, configuration, etc.

Anyhoo, SiteMesh was probably mentioned enough times to attract another load of people to the SiteMesh session.

I’m really glad these people mentioned SiteMesh and said such kind words about it – it resulted in a lot of interest and a full house for the SiteMesh session. I hope to get these presentations online shortly and write a bit more about how Subversion, Microsoft Word and SiteMesh can be combined to create a rich Content Management System.

h2. Improving SiteMesh’s marketing

The fact still remains that SiteMesh has terrible marketing. I’d love some ideas of how to spread the word more and encourage more people to try it but I honestly have no idea what to do. Any suggestions?

SiteMesh and Content Management @ O’Reilly OpenSource Conference

I’m talking at the O’Reilly OpenSource Conference (OSCON) – Wednesday Aug 3, Portland, Oregon.

Come and say hi.

A problem faced in every web application is how to separate style from content. SiteMesh is a framework that provides an elegant solution to this, resulting in a clean separation that is straightforward to work with, complements other web frameworks, and is easily applied to existing applications.

The first part of this session introduces SiteMesh, including an overview of the architecture and patterns, comparisons with other approaches, and how it can complement existing web frameworks (such as WebWork, Spring, and Struts).

The second part of this session demonstrates how SiteMesh can be blended with other technologies to form the foundation of a rich content management system that distinguishes between the specialized roles of users, their skills, and the most suitable tools. Content writers can use a word processor, web designers can use a WYSIWYG web development tool, and developers can use their IDE.

Allowing these different roles and tools to come together to produce one website is a trivial task with SiteMesh–allowing content management to be easily introduced to existing applications.

Finally, some of the advanced features of SiteMesh are discussed, such as real world tips and tricks, how to create custom strategies for which look and feel to apply, assembling pages from components and building portal style applications.

And for the first time, new features in SiteMesh 3 will be demonstrated, including extending the HTML processor, using it outside of SiteMesh, and offline support.

Looking back at the SiteMesh HTML parser

Before talking about how the new SiteMesh HTML processor works (to be released in SiteMesh 3), I thought I’d write a bit about how the current parser has evolved since it’s first attempt in 1999 – purely in the interest of nostalgia.

The original version used a bunch of regular expressions to extract the necessary chunks of text from the document. This was easy to get running, but very error prone as the matches had no context about where they were in a document. For example, a <title> element in a <head> block is very important to SiteMesh, however sometimes they appear elsewhere, such as in a comment, <script> or <xml> block.

This was dumped, in favour of a DOM based parser, which initially used JTidy to convert HTML to XHTML so it could be traversed as a standard DOM tree. Much nicer, but very slooow. Too slow, so I switched to OpenXML, an XML parser that was tolerant to nasty HTML, giving a slight boost to performance. I was much happier with OpenXML – even though it still added a fair amount of overhead and rewrote bits of HTML that I didn’t want it to.

Annoyingly, not long after that, the OpenXML project merged with the IBM XML4J parser project, rebranded itself as the mighty Apache Xerces and promptly dropped support for HTML parsing. So now I was dependant on a library that no longer existed.

By this time, SiteMesh had been open-sourced, and along came Victor Salaman, who was the third user to discover it (after Mike Cannon-Brookes and Joseph Ottinger). He saw the potential but hated the parser. About three hours later, he’d produced his own version that used low-level string manipulation. It wasn’t pretty, but it went like the clappers – twelve times faster than the OpenXML one, with the bonus feature of not rewriting great chunks of the document. This brought SiteMesh into the mainstream as it was now ready for use on high-traffic sites. 1.0 was released.

This parser really is the core of SiteMesh. It’s been our friend thanks to its speed and reliability. It’s been our enemy because of it’s awkwardness to understand and change. For a couple of years it remained barely untouched, except when we occasionally poked at it from afar with a long pointy stick for the odd change. Three years later, Chris Miller and Hani Suleiman took the plunge and gave its guts an overhaul – making it six times faster! Very brave.

Despite its awkwardness, it proudly lived on and is still the primary ingredient of SiteMesh today. It’s even been ported to VB.Net!

I’ve kept my eye on other HTML parsers, such as HotSAX, NekoHTML and TagSoup, always with the intention of implementing an easier to maintain parser, but I just couldn’t get the performance to be anything like what Victor, Chris and Hani achieved.

The problem is that most HTML parsers try to represent an HTML document as tree of nodes, like XML. This makes sense as that’s what HTML is meant to be, however, to do this, every single tag in a document must be analysed and balanced accordingly. This is hard, error-prone and adds a lot of overhead.

There’s another approach though. The new parser focusses on ease-of-use and ability to customize, without compromising on performance and robustness. I hope you’ll like it…

Update: Sorry, I forget to mention Hani in the original posting of this. how could I forget!

The road ahead for SiteMesh 3

Here’s an update of what’s in store for the upcoming SiteMesh releases and how they benefit you.

Firstly, there are a number of accumulated bugs that we’re steadily working our way through. The recent 2.1 and 2.2 releases have been mostly bugfixes, and this will continue for the 2.x series, including those related to using MVC frameworks such as Struts and WebWork.

Meanwhile, SiteMesh 3 has been brewing. It’s been four years since SiteMesh was first open-sourced (it existed for two years before that as closed-source) and in that time it hasn’t really changed significantly. SiteMesh 3 is going to see the largest set of improvements since it was initially released.

h3. Flexible HTML processing

The core of SiteMesh is based around an HTML parser that is very fast and tolerant to badly formed HTML, however at the cost of being extremely hard to extend.

SiteMesh 3 will contain a new parser, which is easy to customize, without compromising on performance and tolerance to malformed HTML. This will allow extensions to be written that can:

* Extract user-defined properties from the page beyond the predefined ones from <title>, <meta>, <content>, etc.
* Remove blocks of content from the page.
* Transform HTML as the page is parsed.

SiteMesh will come bundled with extensions for popular tasks and it will be trivial to add your own. More on this in a follow-up entry.

h3. Improved Velocity integration

This follows on from some work done by Atlassian and will allow a page to be generated using the Velocity API as an alternative to calling Servlet
RequestDispatchers and the Filter.

This offers significant performance improvements for applications that don’t use JSP and allows more of SiteMesh to be used in environments outside of the Servlet container, which leads nicely on to the next feature.

h3. Offline support with StaticMesh

There has been a lot of demand for using SiteMesh to generate web-sites in an offline manner. A common case for this is a simpler alternative to DocBook style tools, allowing documents to be authored in standard HTML capable word-processing tools (such as MS Word, OpenOffice and Mozilla Composer), giving you the full capabilities of a rich-text word-processor and without the need to learn a special markup/schema.

SiteMesh can then process these raw HTML files and generated another set of static HTML files with the appropriate presentation and navigation added.

Building upon the extended HTML processing capabilities, it will also be possible to do things like generate a table of contents, footnotes, and diagrams from inline syntax.

There have been at least three seperate incarnations of StaticMesh appear over the last few years. We hope to bring the best bits from each of these into the final version.

StaticMesh will have a simple API for configuration, bundled with a command-line wrapper and Ant task.

h2. Backwards compatability

Just to ease your minds, you’re not going to have to rewrite your applications to use SiteMesh 3. Great effort will be taken to ensure that backwards compatability is preserved. The library will have more features, but at the same time a lot of the old stuff can be simplified. Dependencies will be minimized and optional – for example, you will only need velocity.jar if you’re actually using the Velocity stuff.

I’ll be posting more information later.

Watch this space…