writing mvc framework in cq4 (part 1)
In the next few articles I would like to give you some guidance in writing a MVC framework for Communiqué 4.2. Why 4.2 you ask - good question. With the version 5.1 finally out, I should probably be concentrating on it. The main reason is that clients still like CQ4, and most likely in 2009 there will still be a lot of new projects written on the old version of the platform, while we will be learning how to write in CQ5 and how to do it right.
Why would I want to write this framework? The default approach presented in examples provided with the default installation is lightweight, easy and quick - that’s true. In the long term, however, I’ve found it hard to scale and manage. It’s hard to force standards and QA Ecma scripts, plus, they tend to get complicated while developers hack they way through issues. Separation of concepts and putting them into layers simplifies architecture, and the cost of creating bloated codebase is compensated by the ease of supporting such a project. And the only way I know to help development team avoid messy projects is to create a framework.
Before I continue let me explain what I understand by framework. A framework is a solution to a high-level problem (here - creating web sites in CQ). This solution is provided incomplete but it can easily be extended and adapted to a given case (web site X in CQ). The spots that will be extended / overriden by the developer are clearly specified by the framework. Framework must be general enough to be reusable across the projects, while strictly enforcing solving similar problems in the same way, it must be easy to learn and hard to bypass.
Now, let’s have a look at CQ and see if we can define Model, View and Controller here.
- Model - data displayed on the page. These data are probably persistent somewhere, have some business rules, are associated with default values and will be displayed somewhere - but the model is unaware of all that. It just stores plain data - no logic, no formatting - it’s raw.
- View - a JSP page generating HTML, CSS, JavaScript and so on. It is responsible for formatting data and displaying them correctly. View doesn’t care about where the data came from and has as little logic inside as possible.
- Controller - A Java class responsible for calling the persistence layer to retrieve the model, applying business rules and default values to it and passing it to the view. It doesn’t care what the view is - it just creates the model and exposes it so that it is visible to the view.
The problems that lie ahead are:
- How to combine controller and view? In Communiqué the page is associated with the template, and template defines one entry point - the JSP script (view). How to define a controller while keeping the logic away from the view?
- How to pass the model to the view? How to expose Java objects to the JSP file so that it would be impossible (or at least hard) to modify them from the view?
- How to solve persistence in an easy and effective way? Most of the data will be stored in the Content Bus. How to enforce a standard but flexible mechanism for mapping them to model objects? This operation seems easy but is very error-prone when done manually (especially when refactoring).
In the next article I will answer those questions and try to provide some examples for improved readability, so keep reading!
Cheers,
Jan