Here is Joe's brainstorm for all the flashy new features of SM 3.

Customizable HTML processing.

This is complete. The new HTMLParser is faster than FastPageParser and allows pluggable rules.

Types of rules you can add to the parser:

• Data extraction. Pull relevant data out of a page for later use.
• Transformation. Changing the content of tags.
• Block removal/insertation. Modify regions of the page.
• Text filter. Run non-tag text through a filter to change it somehow.

These are things I've already used the HTMLProcessor for, outside the context of SM:

• url rewriting
• processing macros (like JSP taglibs)
• screen scraping remote sites
• generating outlines of document structures (h1-h6 tree)
• converting documents to wiki text
• building Lucene indexes
• stripping HTML docs down to bare bones

Todo:

• Split this into sub-project that can be used independently of SM.
• Allow different rules to be selected on the fly based upon the current request.

Offline support

Many users (myself included) use SM as much to build offline websites as through a servlet filter. This is very powerful but requires custom code to be written. It's not feasable to create an out of the box solution that can be configured to build any kind of website, however it would be good to deliver:

• A simplified API to allow users to rapidly build their own SiteMesh based offline website generation tools (with a pluggable view layer such as Velocirt/FreeMarker/WebMacro).
• A set of starter applications for common skinning scenarios (look at StaticMesh and my own MiniMesh (Example).
• Some convenicence launchers for these: java -jar sitemesh.jar, javabean, ant target, maven goal (shudder)

Integration with other frameworks:

Velocity/FreeMarker/WebMacro

• Provide comprehensive macro suite to mirror all tags available for JSP (decorator tags and inline decorators).
• Allow to play friendly with other MVC frameworks (for example, deal with the WebWorkVelocityServlet versus SiteMeshVelocityServlet dillema).
• Pure Velocity/FreeMarker/WebMacro mode: When used exclusively as views on website, the Servlet RequestDispatcher can be bypassed completely resulting in great performance improvements and the ability to run out of the Servlet container (i.e. for offline site generation). As used by Atlassian.
• Defacto tutorial.

Tapestry

• Incorporate Erik Hatcher's work SIM-165, allowing Tapestry to be used as the decorator.
• Puzzle: How do event handlers work in decorators that require a post back?
• Defacto tutorial.

JavaServerFaces

• Puzzle: Can JSF be used in decorators? How does it handle postbacks?
• Defacto tutorial.

Tiles

• Puzzle: How can users make the best of both SM and Tiles?

Portlets

• Puzzle: How does SM relate to Portlets? (Hani?)

Architecture changes

These architectural changes will simplify parts of SM and allow for more customization. It should not effect most users but us (the developers) more freedom going forward.

Apply SM filter to RequestDispatcher.include() calls

The same filter that is used at the top level could also be used on all include calls. This would mean the need for page:applyDecorator would practically go away as you could use a standard include. This makes SM friendlier to non JSP technologies
and allows inline decorators to be as non-intrusive as top level decorators.

Component coupling

At the moment, many of the components of SM are very tightly coupled and hard to change for custom scenarios - it is very much geared towards J2EE web-apps with specific XML config files. I intend to break the design out into simpler objects that can be reassembled and customized as necessary. Environment specific things (such as Servlet API interaction, configuration files, classloading and instantiation, etc) will be provided by strategies that are easy to change.

Other misc things:

• Decoration of error and login pages.
• Ability to decorate include files using a filter rather than through a custom tag. Less intrusive.
• Ability to turn on filter and response-wrapper debugging.
• Regular expressions in decorator pattern matching.
• Finer grained control of exactly what is matched in url patterns (path info, request uri, querystring, etc). Example '/blog/errata/' - want to map decorators on that path, but /blog/ is a servlet-mapping and errata is the path info.
• Page composition - Puzzle: how can we make it easier to assemble pages from multiple components with lots of reuse?
• Support for using decorators across web-apps on the same server.
• Out of the box support for pulling in content from other servers, allowing a SiteMesh site to act as a front end for other sites.

And remember...

SM 3 is evolution, not revolution. The core design and usage will remain the same. Full backwards compatability will be adhered to.

Constantly improving performance, fixing bugs and supporting more servers will always take a HIGHER priority than adding new features.

Notes

Snippets from the mailing list that should be taken into account for the next release.

—
From Matt Payne

However, you only need to map the sitemesh/freemarker servlet, if you
only use the freemarker result type in webwork(don't "dispatch" to
freemarker from ww).

Anyway we have the same problems with velocity. Also, a couple of keys
are inconsistent between the two(one has $base, $req vs. $request etc).

Your other option is to just "roll your own servlet" that subclasses one
and adds the functionality from the other one.
—
From Jason Carreira

I'd love to see the ability to chain decorators together, so it would go through decorator1 then through decorator2, etc.

Right now you have to copy the entire contents of decorator files too
often to change little things...
—