How would the communication between the web editing tool and the backend work, then?
First of all, the web editing tool has to understand the contents of the page. It has to understand what parts of the page should be editable, and how they connect together. If there is a list of news for instance, the tool needs to understand it enough to enable users to add new news items. The easy way of accomplishing this is to add some semantic annotations to the HTML pages. These annotations could be handled via Microformats, HTML5 microdata, but the most power lies with RDFa.
RDFa is a way to describe the meaning of particular HTML elements using simple attributes. For example:
News item title News item contents
Here we get all the necessary information for making a blog entry editable:
As a side effect, we also manage to make our page more understandable to search engines and other semantic tools. So the annotations are not just needed for UI, but also for SEO.
This JS would work across all the different CMS implementations. Backbone.js provides a quite nice RESTful implementation of communicating with the server with JSON, but it can be easily overridden with CMS-specific implementation by just implementing a new Backbone.Sync method. Look for example at the localStorage Backbone.js sync implementation.
The purpose of the content repository layer is to separate the server side business logic from the actual storage. By doing this it becomes possible to reuse the same business logic with radically different storage implementations. For example a CMS like Drupal that is used from very small sites to some of the biggest CMS sites in the world faces a difficult challenge in trying to find an optimal solution for all user groups. In the end the storage layer ends up being a compromise rather than an optimal solution for each target group. If Drupal would leverage a clearly defined storage API, ideally based on an independent standard like PHPCR, users would be able to choose the implementation that best fits their scalability requirements that also match the available hardware and software infrastructure.
For example smaller sites might choose to use SQLite for persistence, while a larger site might prefer to leverage a solution like Jackrabbit. Yet other sites might prefer using the file system for persistence but want to hook in a full text search indexing solution like Solr or ElasticSearch. The key thing is that any of these choices should only require changes in the configuration, but not in any actual business logic. Via a feature discovery API the business logic can automatically adjust itself to leverage optional features.
All of these would be quite hard to implement by an individual CMS project. But if we have a common JS layer available, the effort can be shared by all CMS projects implementing these ideas.
In the same way once a CMS is using a content repository it suddenly becomes possible to collaborate on its implementation with other projects, thereby increasing the choices for users and reducing the required development resources from each project.
Obviously when decoupling the content authoring experience it is critical to also ensure that content is actually
managed as content rather than as “final pages” with a specific representation linked to a single page (on a single
for editing, it is not necessary to use a WYSIWIG approach. In this sense even when using tools like create.js it
might still make sense to explicitly not use inline editing or use inline editing without WYSIWIG. As such the concepts
described on this page obviously apply to not only editing in the frontend but also editing in a backend system. For
example a key advantage to using inline editing over form based, specifically
textarea form fields, is that many
users find it needlessly constraining to use a fixed size field for editing when in the end the content on the pages
is allowed to flow freely. Furthermore browsers still lack many widgets f.e. for maps, dates and more application
specific content. However it should be noted that the key here is decoupling and not the specific representation of
editing tools in the client. As such even when using RDFa or other similar semantic markup to describe the content it
can at times still make sense to render the editing UI using standard HTML form elements.