Alfresco Surf is an application framework for developing and delivering dynamic websites. Surf enables the rapid creation of next-generation, productivity-focused web applications designed to deliver your content to websites and web users.
Alfresco Web Editor is an application developed using the Spring Surf platform. It provides in-context editing capabilities for Alfresco repository content. In this chapter you will learn:
Alfresco Surf is a lightweight, scriptable web framework built on top of the Alfresco web scripts technology and Templating runtime. It provides a highly extensible and customizable web framework for page layout and a component framework for building web applications. It works well with web scripts, can remotely call web services (that is, REST), and also has multiple programming options. Applications built using Surf can be deployed on a standalone server. It has zero dependencies on the Alfresco repository but use it as a backend "model". A web application built using the Surf framework has many objects in places like pages, templates, themes, and components. Any application built using Surf can be deployed from the Alfresco Web Project, taking full advantage of Alfresco WCM's enterprise features.
Surf has been designed to leverage web-enabled tools that expose powerful capabilities such as inline editing, drag-and-drop positioning of content, point-and-click template selection, and so on. These tools make it possible for users with little technical training to manage dynamic websites. Alfresco Surf is a lightweight, scriptable Java-based web framework that provides the ability to quickly create dynamic websites using concepts such as pages, templates, themes, and components. The Surf platform was designed to specifically make it:
Applications built with Alfresco Surf can be considered as standalone and deployed on any application server. The application can also be used in Alfresco WCM and deployed from Alfresco Web Project spaces to production servers while making use of Alfresco WCM features. This gives the advantage to use many features of Alfresco WCM that are required for developing any website. Some of the features are listed as follows:
The Surf platform consists of several integrated parts. To help facilitate this, the Surf platform uses a lightweight XML-driven model to store all model objects that make up the website. Model objects are things such as pages, templates, components, themes, and chrome.
Alfresco Surf RESTful platform uses Yahoo's YUI AJAX library and Adobe Flash for a more interactive user experience. Surf allows you to take a page and split it up into template and components. This allows for a total separation of the look and feel and the components. Both the template and the components have renderers to generate outputs. You can even use PHP renderers, that is, you can use the model of Alfresco but the actual page is rendered in PHP. Most of the Surf components are envisioned to be written using web scripts. With web scripts and their rich underlying API for extension, no Java coding or server restarts are the most common, and the most powerful, rendering facility. You can also build your own renderers or make use of the out-of-the-box renderers such as JSP, Java Bean FreeMarker Templates, and HTML available. Templates make it possible to define a page layout once and then reuse it across a large set of pages. In each of these template languages, the essential goal is to layout the placement of regions (or slots) into which components can be bound. You can create single- and two-tier applications.
The Surf platform is used by the Alfresco 3.0 release of products to provide a uniform suite of interchangeable functionality. These applications include:
All of these applications are presently being built on top of the Surf platform. The Surf platform itself is a product that our community and customers may wish, and are encouraged, to use in building their own web applications.
Surf architecture shows a deep appreciation for the Web 2.0-inspired architecture and web application mash-ups. It's important to point out that although tools exist to reduce the need for technical skills, the platform does not eliminate or discourage access to its internals for those who need it.
Surf utilizes the MVC pattern using various components and objects. MVC stands for Model-View-Controller.
The Dispatcher Servlet can be considered as a controller. It is responsible for rendering the view. It considers the incoming request context and decides what and how to render. It constructs the page view by looking at the related model components or templates to render using different possible rendering engines. The dispatcher can receive requests for the following:
The XML is stored in sub-directories in the specified location:<install-application>/WEB-INF/classes/alfresco/site-data
.
Within this directory, you will see the following sub-directories, one for each type of model object that is managed by the Surf platform:
/site-data/chrome /site-data/component-types /site-data/components /site-data/configurations /site-data/content-associations /site-data/page-associations /site-data/page-types /site-data/pages /site-data/template-instances /site-data/template-types /site-data/themes
View (Renderers): View is for the presentation layer. The model objects such as components, templates, and page can be rendered using any of Surf's supported rendering engines, which internally return data in HTML, XML, JSON, and many more.
The view can be constructed using several rendering engines. These include:
Web scripts: Web scripts are used most commonly to render components. Web scripts themselves follow MVC architecture. The Web scripts take advantage of JavaScript (behaving as a controller), FreeMarker (for presentation processing), and model objects (for business logic). They can be stored in the specified location:<install-application>/WEB-INF/classes/alfresco/site-webscripts
.
JSP: The JSP renderer is used to render either components or templates, and provide you with access to the Java language and the Surf platform Java API. JSPs can be stored in the specified location:<install-application >/tomcat/webapps/alfresco/jsp/components
.
FreeMarker: FreeMarkers can be stored in the specified location:<install-application>/WEB-INF/classes/alfresco/templates
.
By using the Surf framework you can create both single-tier and two-tier applications. Tiers can be considered as the physical deployment of different application layers.
The user interface of a web application, the middleware, and the data access all are contained in one package. A system where all the layers are bundled together on a single server is generally single tier. Single-tier architecture has the interface, business logic, and database highly coupled. Installing Surf as is, with just the page layout and component framework, is single tier. A one-tier application also follows MVC. Here, model represents objects like pages, components, and templates, controller represents Dispatcher servlets, and renderer represents FTL and Web scripts. In this case, FTL code will be heavy, and rather than depending on other parties, it will call the User Interface framework optionally and will message data. It will also create data in the form of HTML or XML. If we have a complex User Interface, it is not advisable to keep the complete logic in one Web Script. In that case, we can develop the application using two tiers.
With two-tier client/server architectures the user system interface (Client) is usually located on the user's desktop environment and the database management services are usually in a server that is a more powerful machine that services many clients. Processing management is split between the user system interface environment and the database management server environment. The client performs most of the business logic as well as the presentation, updating shared data by communication with the database. Here we separate the data retrieval and data presentation part. So, one set of web scripts (Data web script), will be responsible for data retrieval and sending them in JSON, XML (ATOM), or other serialized data format present on the Repository tier. Another set of web scripts (Presentation web script) with some UI framework, may be YUI (Yahoo User Interface), will call those Data web scripts and will be responsible for rendering data present on Presentation tier in HTML format. In case of two-tier FTL or presentation web scripts, the code will be minimal and will be more centric to creating data in JSON/XML format. Consider the client is on one server (Presentation tier) accessing the Alfresco repository on a different server (Repository tier) using remote calls. Alfresco Share and Web Editor are two-tier applications, as they remotely connect to a different Alfresco repository using remote calls. The Alfresco Web Editor performs most of the business logic and presentation. It uses the Alfresco repository to fetch and store the data using Alfresco web scripts.
In the Surf framework models are represented in the form of XML. XML files are effectively bound together to allow a page to be loaded and rendered. A model object contains information about site construction. Model defines pages, page layouts, and components within the page. We already had an overview about model in the previous section. Let's have an overview about these elements:
Objects |
Description |
---|---|
Configuration |
A Configuration object is a collection of XML, mostly used by the internal system. It is defined for a site. |
Component Type |
A Component Type is something that the website builder can grab at and instantiate in many places across the web application. They bind the new instances into pages by snapping them into regions (or slots). They can be considered as widgets. |
Component |
A Component is an instance of a Component Type that has been "bound" into a region. |
Template Instance |
It points to Free Marker renderer classes. |
Template Type |
It specifies FreeMarker or web scripts as the renderer. |
Template renderer |
It defines the look and feel of the page. |
Page |
A Page is the navigation page in a web application. It consists of templates and components. |
Page Association |
The Page Association objects allow you to link two pages together. |
Content Association |
It associates a document to the page. It can associate either a specific document or all documents of specific type and can be associated to a page instance or page type. |
Chrome |
Chrome describes border elements around a region or a component. Using Chrome, you can also include styling elements and drag-and-drop capabilities into a Page. |
We will learn some of the surf APIs used by presentation tier. The objects and methods are available to templates and components within Alfresco Surf. The main point to be noted is that these methods are not available for Repository-tier web scripts. Both FreeMarker template API and JavaScript API use the common object model. The list of commonly used root objects and methods is as follows:
Root objects |
Properties and Methods |
Description |
---|---|---|
context (context of current page) |
|
The internal manage ID for the current request. |
|
The ID of page and page object being rendered. | |
|
The ID of template and template object being rendered. | |
|
The ID of theme and current theme object being rendered. | |
|
The current user. | |
|
The ID of content and content object being rendered. | |
|
Associative array of all context values. | |
|
Returns true if current user is not a guest. | |
user (current user) |
|
User identifier. |
|
Associative array of all user values. | |
|
The details related to user identification. | |
|
The details related to user's organization. | |
|
The user's online contact details. | |
|
Saves changes to the user's properties. | |
|
Retrieves user object. | |
content (only available if an object ID is provided as part of the page URL) |
|
The ID of content object. |
|
The | |
|
Associative array of all object properties. | |
|
The time when the object was loaded. | |
|
The ID of endpoint from which object was loaded. | |
|
Whether the object is successfully loaded. | |
|
The status code and message when the object is loaded. | |
|
The content in text and XML format. | |
Page (available within context of page renderer) |
|
The URL helper object. |
|
The ID of page object. | |
|
Title of Page definition. | |
|
Description of Page Definition. | |
|
Theme ID. | |
|
Properties of custom page definition. | |
url |
|
Page root context path. |
|
Page root servlet path. | |
|
Page URI. | |
|
Page URL. | |
|
Query string for the URL. | |
|
Map of URL arguments. | |
remote (connect to remote services, that is, repository tier) |
|
A |
|
Default end point connector. | |
|
Connector to specified end point. | |
|
Invokes specific URI on default endpoint. | |
|
Gets the name and description for an end point. | |
|
Gets the URL for an end point. | |
sitedata (site construction helper) |
|
Root Page object for the website. |
|
Configuration object for the website. | |
|
Arrays of all these objects. There are many more methods available. | |
|
Maps of all these objects. There are many more methods available. | |
|
Creates new objects. There are many more methods. | |
|
Looks up objects and returns array of results. There are many more methods available. | |
|
Binds object together. There are many more methods available. | |
|
Unbinds objects together. | |
|
Looks up individual objects. |