OpenCms Architecture
OpenCms has a modular architecture centered on a VFS. The file system is
considered virtual as it resides inside a database and not on a hard disk. The
VFS is similar to a real file system that supports folders, file types, and
permissions. Access permission masks on the fi les and folders, and controls
access that users and groups have to the files. The OpenCms VFS also provides a
feature very similar to symbolic links in a Unix file system. A link is a
directory entry that contains meta-information which is kept separate from the
file contents.
The core also provides support for basic features such as publishing, access
control, and revisions. Layered above this are application level features such
as confi guration, the user interface, and module support. Module support is a
key feature of OpenCms, providing the ability to extend and modify it. Module
support is layered on top of OpenCms. A logical view looks like this:
![](Images/Open-CMS-3.JPG)
|
Book Excerpt: Overview
Chapter Contents
This excerpt from chapter 1 of
OpenCms 7 Development by Dan Liliedahl, is printed with
permission from Packt Publishing,
Copyright 2007.
|
|
It is interesting to note that although OpenCms is a web application, it comes
with a shell application that provides an interpretive interface to the API
from a Java command line interface! Furthermore, it is possible to script this
interface to install content into the VFS.
Extensibility through Modules
M odules are a key aspect of the OpenCms design. They provide a way to package
together necessary components that may be easily plugged into OpenCms. Modules
are the way that new content types, templates, or web capabilities are added to
OpenCms. Later in this book, we will go into the details of creating an
administration module for OpenCms.
The OpenCms Web Request Process
It would be useful to understand how a request made to OpenCms results in the
display of content. The structure of a typical OpenCms URL looks like:
http://[server]:[port]/[context]/[servlet]/[parameters]
For example:
http://mydevserver:8080/opencms/opencms/system/logon/index.html
Server: mydevserver
Port: 8080
Context: opencms
Servlet: opencms
Parameters: /system/logon/index.html
The request will invoke the opencms servlet with the parameter /system/logon/
index.html. When the servlet runs, it goes through the following
sequence:
|
1. Uses the passed in parameter to locate the item in the virtual fi le system
2. Determines its access permissions, and see if it can be accessed by the
requestor
3. Determines its file type
4. Based on its fi le type, locates a resource loader for that type
5. Invokes the resource loader to load the file
There is a bit more going on; but for our discussion we will consider only the
previous steps. It can be seen that after permission has been established, a
resource loader is utilized to load the file. Resource loaders are responsible
for encapsulating the knowledge required to load and execute items requested
from the VFS. There are several types of resource loaders provided by OpenCms,
and there is a one-to-one mapping between an OpenCms fi le type and a resource
loader.
Most site content is structured XML, and the assigned loader for this type is
the CmsXmlContentLoader. W hen this resource loader is invoked, it examines the
properties assigned to the resource, specifi cally looking for the
template-elements property. This property must contain the full path to a
template used to render the XML content. The resource loader passes control to
the template. When the template runs, it takes the responsibility of parsing
the original XML resource, and displaying it. Most templates will be JSP fi
les, but they are not restricted to this type. In fact, when a template is
invoked, it follows the same loading process, resulting in its corresponding
resource loader being invoked. This allows for new template languages to be
plugged into OpenCms, by writing and adding new resource loaders.
As resource loaders act on file types, the extension of a fi le in the VFS is
not signifi cant. This means that a fi le with an HTML extension in the VFS
may, in fact, be run as a JSP fi le, or vice versa. A useful way to leverage
this, is to create a fi le with a .CSS extension that is in fact a JSP file.
The JSP could then dynamically generate the CSS based on browser type.
Page
1 | page 2
|