Posted by lamine_ba on June 5, 2011 at 1:56 PM PDT
One thing can have several representations but each of the representations means the same thing. Everything is an object and every object has a virtual representation. You don't believe me! Well, look at your shadow... Anonymous
When describing a feature, one must always show to his users the set of contexts in which its use can bring a significant value for them. The feature I'm about to present is called "Multi-templating with JSF 2" and I'm starting today with a simple question. Does it make sense to have a dynamic templating system for the Java Server Faces Framework? What are the set of contexts in which its use can bring a significant value for its users? The answer is self evident for those who are in the right perspective to see the rationale of it. For the others, it might be wise to take the time to find it through the story of this web designer named Jim. So let's start by reading his profile.
Jim is working with a team of 19 web developers and they have the mission to build a web application using the JSF framework. The separation of concerns has been made as easy as to assign to Jim the simple task of designing the master page and to define its look and feel. The web developers in the other hand, have the heavy duty to build the application logic broken into a set of modules and to create the views that will use the master page. Since the release of JSF 2.0 and the advent of its resource handling system, the life of Jim has never been so easy. Where to store the css, the js and the images files was not anymore his question.
And since he has found with his team the right convention about where to store the master page, their integration process has never been so easy. The root directory has been chosen.
And Jim, like any perfect innocent was living in a perfect world until.........
Until his boss came one day with a new requirement : their lovely JSF application must now be able to change its look and feel at runtime. And Jim to wonder how he could achieve such miracle without a little bit of programming but fortunately he has already understood that changing dynamically the look and feel of a web application means only to build several templates for it. And that a template is nothing more than what we often call a master page or a theme. And that for each template, he has only to create its facelets page and its resources (css, js,images) and store them in the right places.
But what Jim didn't know was, the right places he thought they were, were not in fact the right places to achieve a clean separation. The proof is the message he was getting. His IDE was warning him that there is a file that already exists in the selected destination and that if he wants to overwrite it
And Jim to exclaim "Oh! what a bad and monolithic approach!" and then Jim to ask " How can I do it in a modular way? How to avoid a resource name collision?". And surprisingly the inspiration which came to him was to create a folder for each template and to store the whole thing in a directory named "templates".
But again what Jim didn't know was, all he did were just the beginning of a great inspiration. And he couldn't help asking himself " Hey! If a template has a thumbnail, who can stop me to build a gallery for one to have a preview of it and see what it looks like?"
And to complete his work, Jim brought the rule that a template must always have a metadata for one to know its designer.