An Introduction to CQ5 for Architects
Monday 20 February 2012 at 12:00 This is all really elementary stuff, but as an introduction to CQ5 it may help to put in context by identifying the requirements to run CQ5, the basic terminology used, and how certain areas operate.
System requirements
I'm not going to go over the product specification here as it's really well covered on the Adobe website and in more detail than I would care to add here, but basically CQ5 runs on Java. It should ideally use a Java 1.6 JVM.
The author will need to use a supported browser - on CQ5.4 this means IE7, IE8, Firefox 3.6, or Safari.
CQ5 does not require a separate database; it stores it's data in a CRX repository. By default this uses a file based persistence manager.
Components are not templates
Some factoids about components which are significant in terms of designing solutions using CQ5:
- Components are scripts which do something, and dialogs which allow the author to edit properties.
- Component scripts are usually JSP.
- Pages are rendered with components.
- Components can inherit from other components. When this happens they can replace the script or dialog from the parent component, or they can add extra scripts.
Users can add content components to the page by dragging components onto the page, and can move them around according to rules set in the components and the page design. Users can edit the components they have added and those embedded into the page by double-clicking or right-clicking on the page - this is where the component dialog comes into play.
Templates are not components
Templates are different to components in two major ways:
- Templates are items that authors can pick when creating a new page. Components are added to a page which already exists
- When a page is created, it basically copies the template into the content tree. This allows the page to be prefilled with data, contents, default page settings, and so on. Once a page is created, the template is not referenced (except to display the template name to the author in the list of pages).
A paragraph system is a special component that allows the authors to add and remove components. It operates much like a list and can be reordered by the author.
Author & Publish instances, and page activation / deactivation
Running copies of CQ5 are often known as instances. The main differences between author and publish instances are replication agent settings, anonymous access, workflow launchers, and the presence of author accounts. This is all set up automatically during installation.
Replication agents send the content to the publisher when the author activates or deactivates the page. It sends notification to the dispatcher from the publisher when a page is modified. This all happens using standard HTTP requests.
Dispatcher Cache
The dispatcher is a web server (Apache, IIS, and others) that caches content on disk so that it doesn't need to be requested from CQ5 every time. This improves performance. Effectively, it works in a similar manner to a reverse proxy. The publisher notifies the dispatcher of changes.
Pages with query strings and form post requests can not be cached. Scripts can also mark pages as non-cacheable by the dispatcher.
Workflows
Workflows can be triggered automatically using workflows launcher triggers, or manually by the authors. Steps can be manually actioned by users or process steps that run code or scripts. These processes can be developed in Java and placed in OSGi bundles or written using EcmaScript, a close relative of JavaScript.
Some workflows are considered special, such as 'request for activation' - this runs when an author tried to activate a page when they do not have sufficient permissions.
Java Code
The rules for Java in CQ5 are fairly simple:
- Java code for business logic belongs in OSGi bundles, as does anything that's more complex than basic output.
- The code is packaged in standard java.jar files either complied in a special way or with extra files added to specify the OSGi services. These jar files are known as bundles.
- New services are identified by their Java interface name. It is possible to extend the core product using dependency injection by creating Java classes that implement specific interfaces.
CQ5 uses Apache Felix as the OSGi framework, and Apache Sling as the web framework. The content repository conforms to the Java Content Repository specification 2.0, aka JCR2.
Conclusion
This is a fairly broad overview of the requirements and technical features of CQ5.There's much more to it than this short article could possibly hope to cover, especially the CRX repository which is a topic in itself. There's plenty to read on the the Adobe website about CQ5, and on the Apache Sling to cover the framework.
Antony |
Post a Comment |
Apache Sling,
architect,
archtecture,
cq5,
crx,
guide,
introduction,
jcr in
CQ5,
Content Management,
Development,
Guides 
