XML binding to Snippetory templates

Once, a while ago I discussed a rapid prototyping solution. It consists of three parts:

1. A way to mount pages of fragments
2. A way to bind XML data to these pages including a way to edit the data using forms defined in these pages
3. A framework for fine grained substitution of this primitive persistence layer by full featured persistence, validation and arbitrary logic.

This time I'd like to detail the XML binding.
Snippetory templates are passive. This means they do not contain any business nor any data binding logic. And this in turn means arbitrary logic can be used to bind the data. Additionally, Snippetory provides a reflective interface. This allows generic logic to analyze the structure of Snippetory templates to be able to handle the data binding at least in simple cases. On the other hand XML provides pretty much the same features. So binding the XML data could be done like this:

This is pretty generic code. And, when implementing such complex logic, it's really nice to have recursion at hand. As such Snippetory offers completely new ways in templating.

Plugging pages

In my last post I descriped some ideas for a prototyping solution based on Snippetory. One of the modules it builds upon is the mounting of re-usable parts. Now I want to provide further details on this part based on the Snippetory site as an example. 
Things start with the base.html. It contains the things, that are used for the entire site. And it provides sockets to plug the parts that are different. These sockets can be mandatory, or provided a sensitive default, optional. They're represented by simple location marks
<title>{v:title default='JProggy'}</title>
or if there's some more code used as default as a region.
<t:region_logo>
<div class="region-logo">Source
<div class="tagline">for developers</div></div>
</t:region_logo>
To get a meaningful page we have to add some content. As there are a number of plugs this is not bound to a single location, but can spread throughout the entire page. 

Of course this is a very simple page. Who ever been on the site knows, the most pages have an additional navigation area on the left. This is achived by adding the menu.html. The menu.html plugs into some sockets of the base.html, provides some new and, wraps the 'content' plug, so that content is injected into the code of the menu.html. 

 So far this is a solution, that allows quite some possibilities to share repitive code. However, for a modular application this might not be enough. So stacking several files similar to menu.html. The algorithm supports that. 
In addition some kind of component provider can be stacked even on top of the content file. This would make sense to encapsulate components, that are placed on different pages, but not on all. Like a comment function one want only provide to some of the pages, or an advertisement block, that's used to fill spare areas. Hm, the examples might be not that brilliant, but I think there are better ones out there.
As the pages are simply stacked the definition of a page type only needs a list fragment files to be included in order.
base.html;snippetory/menu.html;<page>
For all the pages in the snippetory directory.

A prototyping system based on Snippetory

In web application design it's good practice to create a prototype before the real implementation starts. This helps in the communication with the customer and allows some fine-tuning of the user interface before changes get more expensive as all the logic has to be changed. As this is quite a bit of work to create it's annoying that most web development environments can't build on that prototype. They need their own branch to mix the logic in. This process, called make it dynamic, effectively destroys the prototype in it's function as prototype. This hinders a parallel evolution of prototype. If it evolves complicated merges are necessary.
That's why I plan to build a prototyping solution where the prototype grows to an application. The intended users are technical oriented designers who are used to code HTML and CSS and are used to deal with code reuse. In addition there are developers who do user interfaces, too, like myself. Though, the plan is not to support graphical design tools or even create them, but rather the possibility to let the HTML code grow to a complete web application without any break in process and a high degree of functionality of in early project phases. In particular I'm talking about generic xml persistence and localization. The great advantage of xml persistence is to work without schema definition. Though, no scheme to update when you add another field. Just extend the front end and continue saving the data.
The foundation of this plan is Snippetory. It's syntax is simple enough to be used in a prototype.
The interface of Snippetory templates is explicit and reflective. This allows to create generic functionality. Though, by defining some criteria how to place and, more important, name location marks and regions it should be easy to deal with them in any context.
At the moment this site is generated from a bunch of Snippetory templates. I use formats for syntax highlighting and links to javaDoc. The latter will help me when relocating my javaDoc and will make my generation fail if I renamed the linked class. And ot makes my code more readable as I have to annotate less information. However, the main functionality is to plug the snippets.
At the moment there are 3 different types of snippets:

1. The base frame is responsible for the top navigation, and header base information like style sheets.

2. The folder specific frame part provides the left, menu the folder specific 'icon' on the top, right corner. This type might be skipped if not needed.

3. The page definitions contain the content, including the content for the title tag and the description mate tag for basic SEO support

The snippets with lower number provide one or more buckets where those with higher number are plugged into. This is a very simple process and just needs a few line code to be implemented.
Additionally I have a Servlet that can provide single generated page on request. This allows me to locally review my changes while developing. Though, for the moment it is pretty nice to build a documentation, consisting of passive pages. Not too interesting as there are so many CMS. But except the ability to combine this with the possibility to inject XML data a number of interesting use cases will pop up.
For example this is the first stage I would call a prototyping system with the ability to grow seamlessly to an application. It can view production ready templates without the ballast of logic and database binding. Just some xml for providing the actual data. Okay, this is quite a bit of work to maintain, too. Even though the binding will not break just because of an additional field. Just no data for this new field, but at some point in time one will have to correct those data. This is way the entire system will get much more convenient once the XML persistence is complete. I.e. saving the data from the forms you create is supported, too. A paging module and a simple filtering facility will make the solution quite complete and should be sufficient for numerous applications.
Hm. This makes up the templates. Nice solution, but no complete application. Yes, some kind of web framework will be required, too. I didn't decide this for now. But maybe Spring MVC is flexible as well as simple enough to fit here. However, especially the simplicity is a problem. It provides so many classes. Another class for any special case. For the moment the most important thing is an URL to action mapping. No matter how, there will be some kind of facility to take over implementation in small steps. Maybe some validation first, some logic in data binding next. For example marking of negative values. The switch of the persistence to database would replace the prototyping solution finally. However, on an additional prototyping server the templates are still running with XML persistence. Which still allows much more convenient changes on the data structure. The most important pieces of logic are installed there to provide the best preview. Of course the switch of persistence technology is done object by object. And where XML is sufficient it might even be skipped.