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:
The base frame is responsible for the top navigation, and header base information like style sheets.
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.
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.
