!About ztemplates

ztemplates started 2 years ago as a hobby project and just for fun.

The first approach was to declare pojos with properties and operations and to map the operations to urls and the pojos  to templates. The approach soon ran into problems. Mapping pojo operations to urls means the framework must create initialized pojos before calling the operation. Because the framework had no control over how the pojos were created I tried to assign ids to the pojos and to cache the pojos on server side. The framework needed full control over the url format. Well, because of the back/history button, the state could become corrupted. So I intoduced version numbers, but now bookmarks would fail. And what if the user opened two browser windows?

So there were a couple of problems:

* the url carried not enough information to create a fully initialized pojo
* the framework claimed full url format control
* there was the server side state that was always hard to keep in sync with the client

But not all was so bad. I really liked the fact that the render-pojos exposed their data to the template. It was so easy and straightforward to write a html fragment and include it into another. Also the autodiscovery feature was cool,  I did not have to edit any configuration files.

So I dropped the first approach.

I split the pojos into render and action pojos. In fact I found that the two are completely independent. Now you can use only the action-pojos, or only the render-pojos, or both.

Then I made the framework completely stateless. No more serverside ids, versions or the like. But then the information must all come from the url. I needed expressive urls. Also I did not want to constrain the urls. So I decided to create the url-variables. Now the programmer can create urls as he likes and can also conveniently match the urls and extract his values from the url. The url matching process also offers natural points for callbacks. So I introduced before and after callbacks on the whole process, as well as for each url variable. 

Now the action-pojos contain the logic and access the data layer, the render-pojos are passive view-data holders, the templates contain the layout skeleton.

But what about css? So I added features for [css] fragments.

And [AJAX]? Luckily this fitted very well with ztemplates. The render-pojos declare in annotations which css/js they need and the framework collects the declarations and computes the script declarations. It turns out that you won't even see the AJAX when using a ztemplates component. In fact components can be packaged completely selfcontained into one jar file. A component programmer includes in his component-jar the css and js and the action-pojos that return those js and css. Because ztemplates scans the classpath it will find the pojos and so will dispatch requests for js and css from the jar to the action-pojo in the jar.  Also, as mentioned before, ztemplates computes all <script> tags based on the render-pojos it uses for a particular response, so the programmer using a component does not have to keep track of all these. Just drop the jar into WEB-INF/lib and use it.