The genesis of the Jahia Studio
In Jahia version 6.5 we introduced our new Jahia Studio, and while this is now a proven technology, the path to this new feature was actually the result of years of continuously researching and developing new ways to make it easier for users to manage their content and presentation. Because it is different than what most CMS' use as a layout mechanism, this also means that integrators may have to spend a little time learning the new technology in order to fully benefit from it. But once the concepts are understood, it is very easy and especially fast and fun to deliver many projects. In this post I'd like to look at the genesis of the Jahia Studio, since I think that explaining how it was originally conceived will probably help explain why and how it works.
In the early versions of Jahia, the templating system was quite simple. A context object called JahiaData was passed to a JSP for page rendering. This single object actually contained all the page content objects and these were then accessed using scriptlet code to render the page. Also, Jahia, even in its first version, included the notion of an "edit mode", basically a way to activate an editing interface for the page currently being displayed.
One of the tricky parts for the integrators were that in order for the editing UI to render the edit-in-place UI elements, it was their responsibility to add them in the JSP, or the element would not benefit from the possibility to be edited. This could be useful in certain cases, but usually this would be extra work that was not really interesting and could make the JSP harder to read.
The content definitions were also done in the JSPs, although this was usually done using files included at compilation time (static includes). So basically for each template we had one big JSP file, that contained the rendering, the editing UI elements and the content definitions. This made it easy to find things, but it made a lot of other things harder, such as reusing content rendering in multiple templates or reusing content definitions properly. The recommended way to solve this was to use include files, either static or dynamic.
The other problem is that in order to modify a template, you had to use a text editor or an IDE on the server or copy the file to the server once edited locally. So making a modification in the template, such as making an area editable or changing some layout would require the skills of either a template integrator or a system administrator, and would usually require some kind of validation and QA before being deployed to production as any minor error in the JSP code could cause serious issues.
At Jahia, we have long strived to make it easier for customers to edit their content without requiring strong technical skills, and this is why we pioneered in the field of edit-in-place technology since the initial versions of the product. This proved very successful but we were still having limitations with making changes to layout or making it possible for less technical users to be able to control the page elements at a template level (therefore also enforcing layout structure along with content structure). At the same time we were also looking for ways to make developers more productive.
This is how we came to the idea of what is now the Jahia Studio: make it possible, using a simple drag and drop interface, to create, modify and deploy template modifications. Templates are no longer fully developed using JSP files (although that is still possible if required). A Jahia template is now a tree of elements that can be edited using the Jahia Studio, and that can be constructed of reusable components. Components are packaged in modules, and each module is a self-standing deployable element that may contain anything ranging from content definitions to new Java-based service definitions and implementations. For each project developers can then reuse the same building blocks of logic and only have to customize the look and feel (aka views).
Some of the use cases that the Jahia Studio also covers include: making it possible to put "mandatory" elements in pages, use access control to specify who may modify a specific area of the resulting page, or even define relationships between components. This last feature is what we call "bound components": establishing a dynamic relationship between elements, so that components that are not located at the same location in the content tree may still reference each other. This is how the rating and comment components work, making it possible to link them to the related content object using the Jahia Studio when building a template, and the relationship will be dynamically established between the content objects when the final page is rendered.
The Studio also takes care of building all the GUI for editing templates and content objects without requiring integrators to manage any of that when designing a site using Jahia. The same is also true for the integration with our built-in HTML cache, which is transparently mapped to the relationship between page elements at render time, making it possible to manage the embedding of elements and expirations properly.
As you can see, the Jahia Studio is a pretty powerful part of Jahia's feature set. I highly recommend that you download Jahia and start experimenting with it using our training videos and documentation available on our site. I can't wait to see what you come up with. And of course on our side we will continue to improve on the overall experience of developing new web solutions using Jahia. Our next version 6.7 will notably improve the productivity of integrators by a whole new level since more possibilities to work directly in the Studio will be introduced (such as direct integration with source control management systems).
