I’ve always been a fan of component oriented web frameworks. At least since I had contact to the first one: It was Apache Tapestry in 2003. What I liked in the way component frameworks work was the ability to divide complex web sites into simple, handy parts – the web components. In contrast to other then common approaches like Struts + JSP, a single page’s complexity was not growing exponentially with each newly introduced feature.
But why does component orientation make sites more manageable?
Global models and controllers
All frameworks have some concept for reuse of web markup. Usually it’s possible to transfer a piece of markup – often called “partial” – into a separate file and include it in many pages.
Of course it is not enough to reuse a partial in another page, as this snippet of markup will need some data to render and some logic on the server side to call when a link is clicked or a form submitted. Every time you add a partial to another page you also have to extend the page’s controller and model, i.e. add some attributes in rails or ‘managed beans’ in JSF. This often leads to overloaded controllers and models.
Although duplication of code can be avoided by some means of reuse, e.g. inheritance, mixins, concerns, it is not always obvious what code is called from a given partial or for which partial a controller loads some model values.
The way of CoWF
Component oriented web frameworks, in contrast, encapsulate markup and corresponding code as one unit – the component.
The component’s markup gets all data to be rendered from the component’s own logic. And the markup will not call any functions outside the controllers code and thus has no dependencies to any global controller or model.
Component interfaces and reuse
Good components have a well defined interface to their environment. They should declare which data they need to render and which business functions they need to call.
In Apache Wicket this interface is mainly expressed by an “IModel”, which defines only what data is needed but leaves to the environment, how, when and wherefrom this data is loaded. The “business logic”, which the component will call is usually injected by a CI container like Spring or CDI.
This encapsulation and the interface contract allow to create simple and complex UI building blocks, that can be reused inside an application or even in different applications.
Component Frameworks and ReST
A common criticism of component frameworks is, that they try to hide the request/response nature of HTTP. Although this actually only applies to JSF, it is true that most component frameworks store the component tree in a server side session and use it over a sequence of user interactions. So browser requests depend on the server side state and hence none of the yet existing component frameworks is really REStful.
This missing REST conformance is certainly not a problem in itself. But the dependence of server side state implicates a need for session replication which in turn limits the amount of clusters and servers.
Of course, for most application scenarios this limited (horizontal) scalability will be negligible, but it prevents the use of component oriented frameworks for really huge distributed web sites.
I’m still looking for a web framework or even better web toolkit, that combines the advantages of reusable UI building blocks with those of ReSTful applications. If you find one, please leave me a note…
Ticesso 