1. Introduction and Installation

In introduction to the Alfresco Web Quick Start and demonstration of an install using the Alfresco Installer on a Windows platform.

Documentation – Documentation is in progress and forming here: Web Quick Start Developer Guide , Web Quick Start Install and Config Guide, Web Quick Start User Guide.

UPDATE: Alfresco 3.4.a Community is now available including the Web Quick Start AMP files and web application. See alfresco-community-wcmqs-3.4.a.zip here or the QS is listed as an install option from the main Alfresco installers e.g. alfresco-community-3.4.a-installer-win-x32.exe.

We have just merged the Web Quick Start (QS) files to HEAD in preparation for the 3.4 Community release at the end of September. Once complete, the QS will have its own installers and documentation, however I thought I would provide a quick overview of some of the features that the QS provides for those who want to take an early look.

As with anything within the HEAD code line, it comes with a warning that this is work in progress, and is subject to regular change.

What is the Web QS?

The Web Quick Start is a sample application built on the Alfresco platform. It provides an end-to-end WCM example including an authoring and publishing environment using Alfresco Share and a web application built using Spring MVC, Spring Surf and OpenCMIS. The web site is delivered dynamically using Alfresco as a CMIS runtime.

The primary design goals of the QS are to illustrate the power of the Alfresco platform in an easy-to-install package and to provide developers with a strong starting point for their Alfresco implementations. Both of these goals are fundamentally aimed at getting both business people and developers up and running with the Alfresco WCM platform in as short a time as possible. The Alfresco core product has not been changed in any way, just extended by plugging in content model, behaviours, workflows, etc using the many standard hooks provided by the Alfresco product.

The QS website will eventually be available in three flavours for different vertical markets, however the version in HEAD currently is loosely modelled on a Finance news site, but with the intention that this can be re-purposed very easily.

Getting up and running

Once complete, Alfresco will provide core product documentation for the Quick Start covering Install and Configuration, User Guide and Developer Guide. The QS will eventually run on both Alfresco 3.3 Enterprise and 3.4 however as it currently stands within HEAD, only the 3.4 (HEAD) version is supported, so make sure you build the alfresco.war also.

The QS comprises four artefacts – an AMP file for Alfresco, and AMP file for Share, an awe.war file for the Web Editor and a wcmqs.war file which is the Spring-based web application itself. Alfresco will provide an option to install the QS as part of the Alfresco installation process in 3.4, and also provide a standalone installer to add the QS to a current 3.3 install. Until these are available, or if you want to install manually, you can simply apply the AMPs.

Sync up with HEAD and build Alfresco.war and Share.war. To build the QS artefacts you can use the following build targets:

Alfresco AMP:
ant package-wcmquickstart

Share AMP:
ant package-wcmquickstart-share

The above will build the appropriate AMP files and apply them to the alfresco.war and share.war. You can then simply copy these into your Tomcat webapps location.

EDIT – Maven has now been removed from the web app build process so use ANT as follows:
ant build-wcmquickstartwebapp-war

To build the web application, you must have Maven installed. From root\modules\wcmquickstart\wcmquickstartwebapp run:
mvn -DskipTests install

The above will create the website WAR (qcmqs.war), so copy this into your Tomcat webapps location.

Once deployed and started, login to Share as normal (e.g. http://www.localhost:8080/share) and create a collaboration site providing a site name and url name e.g. “Web Quick Start” and “wqs” respectively. Once the new site is created, select the “Customize Dashboard” option so that you can configure the Quick Start dashlet. Select “Add Dashlets” and you can then add the “WCM Quick Start” dashlet to your site dashboard:

Add the Quick Start dashlet to the Share site dashboard

The QS dashlet simply provides a means of importing the Quick Start site data into a standard Share Collaboration site. Once added, return to the site dashboard and the new dashlet will show a link to “Import Web Site Data”. Click this link and then wait for the success message:

Select the import link from the Quick Start dashlet

Once the data has been successfully loaded, navigate to the Document Library where you will see the default site structure:

You will notice that the site structure is separated into the “Quick Start Editorial” and “Quick Start Live” folders. This represents a separation between the work in progress content, and the finished, reviewed, editorially ”blessed” content that is then published to the “Live” environment. More about the publishing mechanism later.

If your web container is running on port 8080 and the web application is running in the same container as Alfresco, the setup is now complete and you should be able to access the web site on http://localhost:8080/wcmqs.

If you are not running the web application on port 8080 or if the web application is deployed to a different container or host, you can easily configure the site accordingly. Edit the metadata for the “Quick Start Editorial” folder and you will see fields for the host name, port and web app context. Configure these to point to where your web application (wcmqs.war) is deployed.

Editorial Folder Meta Data

The website

The website provides a set of features that demonstrate various aspects of using Alfresco’s WCM services. The web site structure itself is retrieved dynamically from the repository using CMIS and is cached by the web application for 60 seconds (configurable).

The main sections of the site include a Home Page, News landing page and sub-sections, Publications landing page and sub-sections and Blog section, as well as search and contact pages. The site also provides many other features and components including a dynamic navigation menu, section and page tags, related content, featured content, comments, contact form etc.

Quick Start Home Page

The Publications section is designed to allow content editors to easily publish Office document (currently Microsoft, but possibly Open Office also) content and images. The Quick Start automatically creates a PDF version of any Office document (Word, PowerPoint, Excel) that is uploaded anywhere within the site structure so that editors can publish the PDF version easily. Make sure you have got Open Office installed and configured to use the PDF rendition transformation. The web site also provides a flash-based document preview so that site visitors do not need to download the document just to read it:

The Blog section provides a simple blogging mechanism with tagging and comments, posting the user generated content back into a Data List within Share. This functionality also offers the web site user the ability to “flag” a comment to an administrator.

The Contact page allows a web site visitor to submit a contact form which in turn posts the content back to Alfresco. This example triggers a simple workflow.

This is by no means a definitive list of the web site functionality, however provides a high level overview.

Editorial

The Quick Start web site is managed via Alfresco Share and the Alfresco Web Editor (for in-context editing). As described previously, all editorial activity takes place in the “Quick Start Editorial” folder within the document library.

Folders are used within Share to define the site structure i.e. sections. Within the Quick Start example, both content and site structure reside within the same location and this combined model is dynamically delivered. This means that any content changes are updated immediately (barring any configured cache time) on the editorial site. For example, if a new folder is created under the “root” folder using Share, upon browser refresh, the new section will be displayed within the top level navigation. Note a folder has both a “Name” and “Title” field, the name being the URL and the title being the display label.

Creating a new folder within the QS site structure automatically creates two other things below it. Firstly a “collections” folder and also an “index.html” file. The index.html file is the asset used by the section’s landing page. The “collections” folder is used to manage any “content collections” for that section.

Content Collections are simply (as the name suggests!) collections of content assets, grouped as the content editor sees fit. For example, the home page on the QS site is made up of five different collections. Navigating to Quick Start Editorial > root > collections shows the collections used on the Home Page. Selecting “Edit Metadata” on any of them, will show the collection assets listed under the “Web Assets” field. The “news.featured” collection shown below is used to power the Home Page banner slider. You can see that 3 articles have been manually selected:

Web Assets on a Static Collection

Content collections whose content has been manually selected by an editor are referred to as “Static Collections”. Static collections are used in various places around the site where editorial control is required to select specific content assets.

You may also notice that there is a “Query” field within the same metadata dialog. If populated, this then turns the collection into a “Dynamic Collection”, whereby the query is automatically run on a configured interval e.g. every 30 minutes. An example is shown at Quick Start Editorial > root > collections > blogs.latest collection. This collection is used by the “Latest Blog Articles” component on the right hand side of the home page. The default query is using CMIS (Lucene is also supported) and simply retrieves the latest five blog articles and orders them by date/time. Dynamic collections allow portions of the website to be automatically updated without any editorial intervention. The “Maximum Size” and “Minutes to query refresh” fields can be used to fine tune the dynamic collection as required.

The keyword “section” can also be used within native CMIS queries. For example, to show all content items of type ws:article from the current section you could use “section:.” As follows:

select d.* from cmis:document as d where in_tree(d, '${section:.}') and d.cmis:objectTypeId='D:ws:article' order by d.cmis:creationDate desc

You can also reference an absolute section from the site root using ${section:/blog} or for a subsection of the current section you can use
${section:companies} or for the parent of the current section you can use: ${section:..}. You can also access site root using ${section:/}, or you can go really mad and use a combination ${section:/blog/../news/./companies}.

As the query is just standard CMIS, you can also use standard property names such as cmis:contentStreamMimeType, so to return all PDF documents within the current section you could use:
select d.* from cmis:document as d where in_tree(d, '${section:.}') and d.cmis:objectTypeId='cmis:document' and d.cmis:contentStreamMimeType='application/pdf' order by d.cmis:creationDate desc

For each section of the website, content type to template mappings can be controlled from within Share. For example, if you edit the metadata on Quick Start Editorial > root > news, you will see the “Section Config” property set to “ws:indexPage=sectionpage1”. This maps all requests going to this section’s landing page (the index.html asset is of type ws:indexPage) to the sectionpage1 template. Another example (set on the root folder) is ws:article=articlepage1 which causes all assets of the ws:article type to be rendered using the articlepage1 template. This template can be seen when clicking on any news or blog article.

This template mapping is hierarchical in that if a match is not found in the requested section, it will then look for a match in the parent section and so on until the root section is reached. Therefore, type-to-template mappings can be set site wide on the root folder. The template resolution algorithm also looks up the type hierarchy as part of this process, however I will not cover this in detail here.

Renditions, powered by the Alfresco Rendition Service are used extensively across the Quick Start site. They allow content authors to publish the correct format/size of content optimized for web, without any manual intervention. Renditions are defined within a Spring config file (rendition-context.xml), and then these definitions can be configured for use with either a given file mime type or content type. Like the type-to-template mappings, this configuration is on a hierarchical section basis, with the option to inherit being available to set on each section.

An example configuration can be seen on the Quick Start Editorial > root > news folder. The “Rendition Config” field has several mappings including ws:image=ws:featuredNewsThumbnail. This example specifies that all content of type “ws:image” will have a rendition created with the definition called “featuredNewsThumbnail” (defined in the Spring config file). To give it a test, upload a large file into the news section and attach it to a news article (by editing the metadata on the news article using the “Edit full metadata” option). When viewing the article on the web site you will see the renditions in use. A thumbnail or cropped banner slider image is displayed (if used on the front page) and a medium and large thumbnail when viewing the article directly. Using the node browser you can browse all of the generated renditions.

Out of the box, the Alfresco Web Editor is configured for use when viewing either a news or blog article. In 3.4, as well as edits, the Web Editor also provides the option to create new content and delete content. NOTE: currently the HEAD version includes the 3.3 AWE and does not build the 3.4 version yet. UPDATE: The 3.3 awe.war is no longer included as part of the web app build from HEAD.  The 3.4 AWE can be built separately using ant incremental-webeditor. Just drop the awe.war into the same container as the wcmqs.war.

In-Context Editing with the Alfresco Web Editor

The QS also provides two examples of managing user generated content (UGC) with Alfresco. There is a “Contact” form located on the Contact page and a “Comment” form located under each blog article. Both forms submit content to Alfresco via CMIS which is gathered in a Share Data List. The Contact form triggers a basic workflow and the Comment form provides the ability to flag a comment to an Administrator, which disables it from display i.e. visitor moderated.

Publishing

The QS also provides an example publishing mechanism. This is based on a workflow driven model whereby once content is approved it is moved locally (using the Transfer Service) from the “Quick Start Editorial” folder, into the “Quick Start Live” folder.

The QS provides two sample workflows for achieving this. Firstly “Review and Publish Section Structure”. This is designed to allow content authors to easily publish specific sections of the site structure. This is done by selecting and initiating this workflow on the appropriate index.html file for the required section. The “Review and Publish Section Structure” workflow will publish the sections from the submitted one and all sections below. A section comprises the section itself, its index page, and all of its collections. Basically it’s a “publish sub tree” mechanism. If you want to populate the entire site structure on live then publish the root section index.html.

The “Review and Publish” workflow publishes either a single asset or group of assets (multi-select). If you use this workflow for a sections index.html, it will publish that section and its collections folder, but does not cascade down.

It is worth noting you can also configure the web application to view the “Live” site structure by configuring the meta-data properties on the “Quick Start Live” folder. The default configuration sets the host address to 127.0.0.1, so if you are running the Quick Start locally, you can actually view the editorial environment on http://localhost:8080/wcmqs and the live on http://127.0.0.1:8080/wcmqs. Note that the Web Editor (AWE) is configured to be enabled on the Editorial content, and disabled on the Live. This is controlled by a flag “isEditorial” on the “Quick Start Editorial” which will also (when complete) dictate what is viewable via the live web application with regards to publishing go live and expiry dates.

Summary

I have certainly not covered all features here, but hopefully provided enough information to get started. The documentation will go in to a lot of detail, especially from a Developer perspective looking to extend the QS. Were hoping the QS will provide a valuable platform both from an evaluation perspective and also for both customers and partners looking to build Alfresco implementations.

• Release Schedule
• WCM Quick Start
• Project “Cheetah”
• Project “Swift”

The webinar can be viewed here.

The 3.1 JavaSccript API wiki page shows the required parameters:

ScriptNode copy(ScriptNode source, ScriptNode destination, String name)

Download the example web script here.  This web script is based on some example code taken from the Alfresco Forge project – FlexSpaces which contains some great examples of WCM web scripts.

As you will see from the descriptor file, the required parameters are passed to the JavaScript via the following URL:

/crossRepoCopy?sourcenodeid={sourceAdmNodeId}&targetstoreid={targetAvmStoreId}&targetavmpath={targetAvmPath}

In a production environment, the required arguments will no doubt be generated programmatically, however for the purpose of a simple example, we will collect them manually.  Firstly, the sourcenodeid source i.e. the node id of the source item that you wish to copy from the DM repo.  Using the Node Browser for this example, navigate to the source file and copy the node.  It will look something like:

workspace://SpacesStore/371d692f-46e7-4ca8-84bb-81a032ac1363

Strip out the workspace://SpacesStore/ as the example script adds it as required so you are left with:

371d692f-46e7-4ca8-84bb-81a032ac1363

Next the targetAvmStoreId, so the store that we are going to copy to within the AVM. This is made up from the web project dns name and the sandbox user name. Use the node browser once again and look for the store-identifier property. In my example the store-identifier is:

demo--admin

Finally the targetAvmPath which is the folder path to the location within the sandbox of where the content item will be created. In my example I would like to copy the content to the root of my web application folder so I use:

/www/avm_webapps/ROOT


With all of the parameters in place, the final request string looks like:

If the copy was successful, you will see:

Result String - Node was copied
Result Code - true

In this article I will look at deploying and consuming WCM content from a SURF web application.  To make this very simple, we have created a standalone Tomcat 6 bundle which has an example SURF web application pre-configured (thanks to Michael Uzquiano for all the assistance!).  This is the same web app as used in the previous articles, so all previous material is still relevant.

Once the Tomcat bundle is deployed and your WCM instance configured, you will have working examples of:

• An AVM layout separating Surf content (components, templates etc) and Web content (XML content, CSS, images etc).
• Deployment configuration allowing the Surf and/or Web content to be deployed to a local file system directory.
• An FSR – configured for the deployment as above
• A Surf website example of including static content e.g. an HTML file from the local file system.
• A surf website example of dispatching dynamic content from the remote Alfresco repository.
• Web form examples for the creation of example content.

Initially I will describe the steps required to get up and running, and then I will dissect the configuration so that we fully understand how it is working.

Prerequisites

• It is expected that you are familiar with Alfresco concepts such as CIFS, Web Scripts, Web Forms etc.  This is not a beginners tutorial to Alfresco WCM!
• Alfresco v3.x installed with WCM configured and running at http://localhost:8080.  If this address is different, you will need to re-configure the Alfresco endpoint.  This is detailed below within the “Dynamic Content Example”, so do not be alarmed if your “Products” section does not work after the install.
• This article is based on the Surf Deployment Configurations wiki article which I would highly recommend reading.

Download

Download the surf-sample Tomcat bundle and extract to your local file system e.g. c:\surf-sample.

Installation

Download the Surf demo Tomcat bundle and extract to your local file system.  Have a browse through the files and you will see that the following is included:

• surf-sample\sample – The Tomcat 6 bundle directory
• surf-sample\setup\AVM – An example directory structure to be loaded into the AVM
• surf-sample\setup\FSR – An example FSR
• surf-sample\setup\web forms – Example web forms for creating news and product items
• surf-sample\setup\web scripts – Example web scripts for the products section

Alfresco Setup

• Create a new web project with the DNS name – “demo”. If you do not use this name, you will have to make a small change to the “Product” web script. See the “Web Scripts” section below.
• Connect via CIFS to the AVM as the “admin” user.
• Copy the contents of the AVM structure dir from the surf-sample\setup\AVM\ROOT to the admin user sandbox via CIFS. (You could also zip up and bulk import if you prefer)
• Submit this content to the Staging sandbox.

The AVM directory structure should look like the following:

Web Forms

I have included two example web forms with the files so that you can quickly create some example content to be used with deployment, and for testing the example functionality.  There are two web forms which need to be installed, one for the news articles and one for products.

Article Web Form

• Create a new article web form using the C:\surf-sample\setup\web forms\article\article.xsd file.  Add the output path pattern of /${webapp}/content/news/source/${name}.xml
• Add C:\surf-sample\setup\web forms\article\latestNews.html.ftl as a rendition with the output path pattern /${webapp}/content/news/latestNews.html

Products Web Form

The product XML items are read dynamically by the Surf webapp.

• Create a new product web form using the C:\surf-sample\setup\web forms\product\product.xsd. Add the output path pattern of /${webapp}/content/products/source/${name}.xml

Note there is also a article.html.ftl file, however at present this is not used.  Once the web forms are installed, you can test creating some content.  Verify that the output is being populated to the correct locations as listed above.

Web Scripts

The Products section uses a web script which must be installed.

• Copy the C:\surf-sample\setup\web scripts\products folder in to the Alfresco Data Dictionary\web scripts folder and refresh the web scripts. If your site name is not “demo”, you will need to edit the site reference within C:\surf-sample\setup\web scripts\products\products.get.js i.e.


var storeid = ("demo");


Deployment Setup

All content is deployed to the C:\surf-sample\sample\deploy directory. This represents a stand alone directory which is configured to deliver the Alfresco content.  This directory is separated into two sections as follows:

• Web Content – e.g. HTML renditions, JS, CSS etc – deployed to C:\surf-sample\sample\deploy\webroot\ROOT
• Surf Content – surf items such as templates, components etc – deployed to C:\surf-sample\sample\deploy\alfresco

Configure two deployment targets:

• Edit your Web Project and add two File System Receivers using the details below.

Name: Content Production
Excludes: [A-Za-z0-9:/_]*ROOT/WEB-INF/*
Target Name: content

Name: Surf Production
Source Path: /ROOT/WEB-INF/classes/alfresco
Target Name: alfresco

FSR

There is an example FSR located within C:\surf-sample\setup\FSR.  You can copy this directory to another location if required e.g. c:\FSR.  The C:\surf-sample\setup\FSR\application-context.xml file has an example configuration which will need to be edited to match your file system locations depending upon where the surf-sample app is located.  See the dir locations in bold below:


<!-- Target Configuration. Modify for your site. -->
<property name="targetData">
<map>
<entry key="alfresco">
<map>
<entry key="root"><value>C:\surf-sample\sample\deploy\alfresco</value></entry>
<entry key="user"><value>admin</value></entry>
<entry key="password"><value>admin</value></entry>
</map>
</entry>
<entry key="content">
<map>
<entry key="root"><value>C:\surf-sample\sample\deploy\webroot</value></entry>
<entry key="user"><value>admin</value></entry>
<entry key="password"><value>admin</value></entry>
</map>
</entry>
</map>
</property>

Once complete, you should be able to start the surf-sample Tomcat and give the site a test.  Create some content using the web forms and deploy it to the surf-sample app.  Start the Tomcat using C:\surf-sample\sample\bin\startup.bat and hit http://localhost/surf/page?p=index

Static Content Example

The Home Page of the site includes a static HTML file that is created using the article.xsd web form.  This creates the latestNews.html file within the repository to ROOT\content\news which is then deployed to the C:\surf-sample\sample\deploy\webroot\ROOT\content\news.  The Surf web application then includes the latestNews.html at request time.

The HTML include import is done by the Surf component, however before this will function, we need to configure Surf (using Spring) to look into the C:\surf-sample\sample\deploy directory for the static content and web scripts.  If you open C:\surf-sample\sample\shared\classes\alfresco\web-extension\custom-web-framework-application-context.xml you will see the example configuration:


<!-- Local Store Abstract  -->
<bean id="webframework.localstore" class="org.alfresco.web.scripts.LocalFileSystemStore" abstract="true" init-method="init">
<property name="root">
<value>/surf-sample/sample/deploy</value>
</property>
</bean>
<!-- Web Scripts: Local Store -->
<bean id="webframework.localstore.webscripts" parent="webframework.localstore"> <property name="path">
<value>alfresco/site-webscripts</value></property>
</bean>

Once this is configured, components can access this static content.  The component that is used on the Home Page is C:\surf-sample\sample\deploy\alfresco\site-data\components\page.main.index.xml and looks like:

<?xml version='1.0' encoding='UTF-8'?>
<component>
<scope>page</scope>
<region-id>main</region-id>
<source-id>index</source-id>
<component-type-id>/component/common/include</component-type-id>
<properties>
<container>div</container>
</properties>
<resources>
<resource id="source" type="webapp">/content/news/latestNews.html</resource>
</resources>
</component>


You can see that we are using one of the web scripts that comes bundled with Surf which is referenced by  /component/common/include.  The resource id is then passed in i.e. the html fragment.

Finally, it is also worth noting at this point that we have mapped a Tomcat alias to point to the “deploy” directory also.  This allows us to reference files such as CSS and images if required, using the “/files” alias.  Here is the server.xml extract:

<Context path="/files" docBase="${catalina.home}/deploy/webroot/ROOT" reloadable="true" crossContext="true"/>

Dynamic Content Example

The second example is the Products page which dynamically loads content from the Alfresco repository.  A list of products is dynamically generated using a web script connecting top the remote Alfresco repository.  When a link is clicked, the relevant content item is dispatched and loaded from the local file system.

The first part of this is a web script that is called to list all of the product items.  This web script is actually located on the remote Alfresco server and therefore we have to configure Surf to search this location for web scripts.

Like configuring the local file store, there is a custom Spring file located in C:\surf-sample\sample\shared\classes\alfresco\web-extension.  Open the web-framework-config-custom.xml file and if you scroll to the bottom, you will see the following extract:


<config evaluator="string-compare" condition="Remote">
<remote>
<endpoint>
<id>alfresco-system</id>
<name>Alfresco - System access</name>
<description>System account access to Alfresco</description>
<connector-id>alfresco</connector-id>
<endpoint-url>http://localhost:8080/alfresco/s</endpoint-url>
<identity>declared</identity>
<username>admin</username>
<password>admin</password>
<unsecure>true</unsecure>
</endpoint>
<!-- The default endpoint -->
<default-endpoint-id>alfresco-system</default-endpoint-id>
</remote>
</config>

This extract configures the remote Alfresco repository as an end-point.  You may also notice just above this that there is another entrance as follows:

<!-- Webapp Resource Resolver -->
<resource-resolver>
<id>webapp</id>
<name>Alfresco Web Application Resource Resolver</name>
<description>Resolves data access for web application assets</description>
<class>org.alfresco.web.framework.resource.AlfrescoWebProjectResourceResolver</class>
<alias-uri>/files</alias-uri>
<store-id>demo</store-id>
</resource-resolver>


This lets Surf bind to web application resources, like static files, in this case, the actual product XML item we wish to view.

With the end-point and resource resolver in place we can call the remote web script.  So the process is fairly straight forward – the Surf component calls the remote web script that returns a list of products via JSON.  We then need a way to load an appropriate template to display each product, and that is done by a page-association item.  This tells Surf that there is an association between the content that is being loaded and the template we would like to use to display it.  Take a look at C:\surf-sample\sample\deploy\alfresco\site-data\page-associations\products.xml:

<?xml version="1.0" encoding="UTF-8"?>
<content-association>
<source-id>{http://www.alfresco.org/model/wcmmodel/1.0}avmplaincontent</source-id>
<dest-id>products</dest-id>
<assoc-type>content-type</assoc-type>
<format-id>default</format-id>
</content-association>

You can see here that the source-id is “{http://www.alfresco.org/model/wcmmodel/1.0}avmplaincontent” and that the dest-id is “products” meaning that all content of the type avmplaincontent would be rendered via the “products” template.

Summary

Hopefully this provides a preview of how nicely WCM content will integrate with Surf powered websites, and Web Studio is also on the horizon to complete the suite.  As noted previously, this Surf configuration and setup is based on the Surf Deployment Configurations wiki article which I would highly recommend reading.  This provides a really good and detailed overview of other possible Surf configurations.

Thanks to Michael Uzquiano for all the assistance!

Setup

If you have not got the basic home page up and running from part 1, download the sample web application here and deploy to your local Tomcat (or any other web app server).  Once installed and started you should be able to hit the home page using http://localhost:8080/surf/page?p=index as long as you are using your local machine and have not renamed the web app folder.  You should then get the HTML template home page as follows:

Overview

The process of creating a new page is relatively simple.  It basically involves creating a new “page” item, and the relevant components that will make up that page as covered in part 1.  In this example I am also going to introduce a new template so that we have a different layout for our new page.  Here is an overview of the steps involved:

• Create the new FTL template file (for the different layout)
• Create the new “template instance” so that the new template can be referenced from a page component
• Create the new page component

I will then move on the introduce some simple navigation using the Page Association item.

Templates and Pages

As noted, the process for creating the new template and page is identical to that covered in part 1 and therefore I will not describe the code in detail.  If you are in any doubt, refer to Part 1 accordingly.

I have decided to introduce a new template so that we can use a different page layout from that of the home page.  I have called this template “content.ftl” as it is a generic page for displaying any type of content.

Start by preparing a basic HTML page that will be used as a generic “content” page.  If you downloaded an HTML template for part 1, perhaps a second content page was also provided.  If not, you can take a copy of the current home page template.  It does not really matter at this stage what it looks like, as long as you can see it is different from your current home page layout.  You can always come back later and make CSS and other layout changes.  If you are using the template that is included as part of the download, you can use the following example content.ftl page:

<@region id="top" scope="global" />
<body>
<div id="content">
<@region id="header" scope="global" />
<div id="left">
<ul>
<li><a href="#">Example list item</a></li>
<li><a href="#">Example list item</a></li>
<li><a href="#">Example list item</a></li>
<li><a href="#">Example list item</a></li>
</ul>
</div>
<div id="right">
<h2>Aliquam metus turpis, luctus ac, sagittis eget</h2>
<div id="line"></div>
<p>Suspendisse egestas fringilla odio. Donec lacinia tristique ante. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam </p>
</div>
<@region id="footer" scope="global" />
</div>
</body>
</html>

You will note above that I have included the different components that we have available using the <region> tag.  This just allows us to re-use the global components we require e.g. header and footers.

• Create the new content.ftl file in the /WEB-INF/classes/alfresco/templates directory.
• Copy in your source HTML for your new layout, or the above example code into the new content.ftl file.
• Add in your global components where needed e.g. headers and footers using the <region> tag.
• Create a new template instance file in /WEB-INF/classes/alfresco/site-data/template-instances named content.xml.  You can copy the current “index.xml” file and remember to amend the <template-type> to point to the new content template.
• Now create the new page.  Lets create a page called “products“.  Create the page xml item within /WEB-INF/classes/alfresco/pages named products.xml.  Remember to reference the new content template instance.

Once this is complete, you should be able to manually request the page to test it using http://localhost/surf/page?p=products. Here is my example products page using the “content.ftl” template:

You can now go ahead and componentise the new page as you wish.  Perhaps separate the main content from the left pane and create web scripts to return the HTML where required.

Is is important that the navigation pane is componentised, as this is what we will be working with.  The image below shows the navigation component:

Here are the steps involved to create the navigation component:

• Create the new component in /WEB-INF/classes/alfresco/site-data/components.  I have named my example global.nav.xml as this will be a globally scoped/used component.
• Create a new web script FTL and descriptor file within /WEB-INF/classes/alfresco/site-webscripts.  Remember to match the same URL references as defined within the component.
• Chop out the HTML for the header navigation into the web script FTL file.
• Include the component using the region tag into both the index and content template files:


<@region id="nav" scope="global" />


• Test the pages so that the new nav component is being included correctly on both the index and the products pages.

We can now go ahead and create some dynamic navigation using Page Associations.

Page Association

From the Alfresco Wiki page – The Page Association objects allows you to link two pages together. Most commonly, this link is of type child and is meant to depict a fixed structure like a navigation tree. However, other types are possible and there is no requirement to use Page Associations as a means to support only a single fixed tree.

Using associations, multiple trees are possible. The nature of the associations, when expanded beyond child, is very similar to that of classifiers, categories, or tags. In other words, Pages may be associated to other pages, but they may also be laterally associated to other elements. This allows for implementations of faceted navigation and tag clouds.

In this example, we will create a very simple navigation to link the Home page (index) to the new Products page.  To do this we will create a page association item.

• Create a new Page Association item within /WEB-INF/classes/alfresco/site-data/page-associations named index-products.xml
• Add the following code.  Note the source and destination id’s relate the pages together:

<?xml version='1.0' encoding='UTF-8'?>
<page-association>
<source-id>index</source-id>
<dest-id>products</dest-id>
<assoc-type>child</assoc-type>
<order-id>1</order-id>
</page-association>

Once the association file is in place, we now need to modify the global nav web script to process the relationships and display the menu.  You should already have in place the nav.get.desc.xml file and nav.get.html.ftl (or files of similar name and purpose) web script files which currently just return the example menu HTML code, nothing dynamic.

In order to process the menu items, we will need to include some logic making use of a JavaScript file as part of the web script.

• Create a nav.get.js (or relative name if your nav web script is named differently) file within the web scripts directory – /WEB-INF/classes/alfresco/site-webscripts.


// renderer attribute
var renderer = instance.properties["renderer"];
if(renderer == null)
{
renderer = "horizontal";
}
model.renderer = renderer;

// set up rendering attributes
model.rootpage = sitedata.getRootPage();
model.linkbuilder = context.getLinkBuilder();

This code makes use of an example basic navigation component with horizontal and vertical renderers.  This is included as part of the surf starter war.

• Edit the nav.get.html.ftl file and remove the static HTML content.  Add the following code:

<#if renderer == "horizontal">
<@horizontal page=rootpage showChildren=true/>
</#if>
<#macro horizontal page showChildren>
<ul id="menu">
<li>
<#assign href = linkbuilder.page(page.id, context.formatId)>
<#assign classId = ''>
<#if page.id == context.page.id>
<#assign classId = 'current'>
</#if>
<a href='${href}' id='${classId}'>${page.title}</a>
</li>
<#-- Children of Home Page -->
<#list sitedata.findChildPages(page.id) as parentPage>
<li>
<#assign href = linkbuilder.page(parentPage.id, context.formatId)>
<#assign classId = ''>
<#if parentPage.id == context.page.id>
<#assign classId = 'current'>
</#if>
<a href='${href}' id='${classId}'>${parentPage.title}</a>
</li>
</#list>
</ul>
</#macro>

The above code makes use of the findChildPages(sourceId) Surf API call which simply finds all child page objects for the given top level page id.  It also demonstrates usage of the linkBuilder facility which dynamically creates the URL.  You will also notice that a style is being applied if we are viewing the current page i.e. parentPage.id == context.page.

This example could easily be extended for second level navigation simply by passing in the parent item id:

<#-- Children of Home Page -->
<#list sitedata.findChildPages(page.id) as parentPage>
<#-- Sub Pages -->
<#list sitedata.findChildPages(parentPage.id) as childPage>


This is a simplified version of the navigation code used within the Green Energy site which is part of the Alfresco Surf Code Camp material.  Jeff Potts has kindly made this available for download, and I would recommend taking a look to learn more about Surf in general (including an example of second level navigation).

• Refresh the web scripts using http://localhost:8080/surf/service/

You should now have working navigation showing the Home page and the Products page:

Summary

Here we have just created a new template (so we can alter the style of the page), and created a new page using the new template.  We then created a simple page association so that the navigation item could build the links. You can probably start to see how useful Web Studio will be, allowing new pages and navigation to be created using a GUI rather than hand coding each new page.

Next I will look at using Alfresco WCM with Surf, along with some deployment options.

Download

The completed web application is available for download here – SURF Part 2 – Pages and Navigation.

See also – SURF Part 1 – Getting Started and SURF Part 3 – Alfresco WCM Content

As described by the Alfresco Wiki – Alfresco Surf is a lightweight, scriptable web framework built on top of Alfresco’s Web Script and Templating runtime.  It is packaged as a single WAR file meaning it can exist as a standalone application.  One of the nice things about the SURF framework is that you do not HAVE to use Alfresco, or any other data source to construct a web application, so for the purposes of this example, we will simply construct a basic standalone website without using Alfresco. We will take a static HTML web site template, componentise it and demonstrate loading different areas of the page using very basic Web Scripts.

09 Feb 2009 – Updated to use SURF starter WAR instead of alfwf.

Overview

SURF utilises the MVC pattern using various components and objects.  XML files are effectively bound together to allow a page to be loaded and rendered.  These include things like Pages, Templates, Components and Themes.

The array of Objects and configurations available to SURF is extensive and powerful and can be somewhat overwhelming for the purposes of just “getting started”. For this reason, I have chosen not to include the majority of these features and functions, however more advanced usage will be discussed in future articles. I would reccomend reading the Alfresco Wiki SURF Overview, as this explains the context of SURF in detail – http://wiki.alfresco.com/wiki/Surf_Platform. The SURF Platform Developers Guide also discusses in detail all of the available objects.

Take a look at the following diagram that represent a simplified path to how a page is loaded:

In simple terms, the page is specified and requested by the URL.  The page definition then looks up the Template Instance, which then calls the actual template.  This could be for example a Freemarker template file.  The template file is broken down into regions which can each call page components.

Build the SURF war file

The SURF starter WAR file can be built from source using:

ant incremental-surf-starter


This creates the starter WAR file which includes example components and configurations.  Alternatively you can download the WAR file here.  Please be aware this was built on 09 Feb and may have changed since then, so building from source is reccomended.

When the WAR file is deployed, you should be able to access the splash page on http://localhost:8080/surf/page providing that you are using your local machine (localhost) and you have not renamed the webapp folder i.e. surf.

Cache

The SURF framework includes a cache facility and at the time of writing this was enabled by default. To save application server restarts it is a good idea to disable it during the development process.

• Edit the /WEB-INF/classes/alfresco/web-framework-application-context.xml file.
• Search for the word “updateDelay” and amend the value to “0″.  There are two occurances and properties to change.


<property name="updateDelay"><value>0</value></property>


• Restart your application server for the change to take effect.

Site Configuration

• Create a new site configuration file within /WEB-INF/classes/alfresco/site-data/configurations named default.site.configuration.xml.
• Add the following code to configure the default page to be “index”:


<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<title>Sample Site Configuration</title>
<description>Sample Site Configuration</description>
<source-id>site</source-id>
<properties>
<root-page>index</root-page>
</properties>
</configuration>


Creating The Home Page

• Create a new page file within the pages dir – /WEB-INF/classes/alfresco/site-data/pages named index.xml. This will be the website home page.

/WEB-INF/classes/alfresco/site-data/pages/index.xml

<?xml version='1.0' encoding='UTF-8'?>
<page>
<title>Home</title>
<description>Site Home page</description>
<template-instance>index</template-instance>
<authentication>none</authentication>
</page>

Template-Instance

The template-instance references the appropriate renderer, and uses freemarker by default.

• Create a new template-instance within /WEB-INF/classes/alfresco/site-data/template-instances
• Call it index.xml. This must match the name used within the <template-instance> parameters within the page example above.

/WEB-INF/classes/alfresco/site-data/template-instances/index.xml

<?xml version='1.0' encoding='UTF-8'?>
<template-instance>
<template-type>index</template-type>
</template-instance>

In this example /WEB-INF/classes/alfresco/site-data/template-instances/index.xml references index.ftl within /WEB-INF/classes/alfresco/templates.

Templates

Next, we will create the corresponding template as referenced above by the in /WEB-INF/classes/alfresco/templates named “index.ftl”. This is the main page structure of our site. As mentioned previously, for the purposes of this article, we will construct a new site using an HTML site template. Choose an example HTML template for your site. There are plenty available on the web e.g. http://www.solucija.com/free-templates. Select a basic layout so that the site construction is simple.

• Open the main page of your new downloaded HTML template (typically index.html) and copy the source code of the index.html into your newly created index.ftl.
• Save the index.ftl template.

Now you should be able to test the new page by hitting your app server using the URL http://localhost:8080/surf/page?p=index. You should see your web template (probably with missing style and image data).

Now we will add in any missing page furniture files e.g. images, css, JavaScript etc so that the page will render correctly.

Copy the CSS file from the downloaded HTML template into /surf/css.

• Repeat the file copy for any other page furniture that may be part of your web template e.g. images and JavaScript files. For example, images should be copied to /surf/images and JavaScript to /surf/js etc.
• Edit your main freemarker template (/WEB-INF/classes/alfresco/templates/index.ftl) to reference these CSS/image/JS files. You can also use the Freemarker reference to URL context – ${url.context} to navigate to the correct directory, for example:


<link rel="stylesheet" type="text/css" href="${url.context}/css/style.css" media="screen" />


• Do the same for any other CSS, JS and images which are referenced within your HTML template.
• Refresh your browser and make sure that all of the referenced files are present. Remember you may have to alter the css file itself if it is referencing image files etc. You should then have a working home page.

Cache Refresh

When working with SURF editing files regularly, it may be required that the cache is cleared before your pages will render correctly. This can be done browsing to the cache invalidate page as follows:

http://localhost:8080/surf/control/cache/invalidate

Componentise The Page

A component is an instance of a component type that has been “bound” into a region or a slot. Basically the page is made up of components which can have different scopes. These can be either global, template or page depending on where you would like to use each component.

• Global – Components to be used on ALL pages e.g. a logo
• Template – components to be used on SOME pages i.e. > 1 but < all
• Page – component to be used on a single page

Global Components

Start by creating a global component such as the page header. These are sections of the page that will not change from one page to the next. On my example HTML template, the logo and general header section will not change between pages (with the exception of the top navigation which i will componentise later), so I will start with that.

• Create a new file in /WEB-INF/classes/alfresco/site-data/components named global.header.xml.

Naming Components

Naming SURF components is very important as it binds the component to a specific region of the page (i.e. where the component will be displayed), and defines the scope. The name is defined as follows scope.regionId.sourceId.xml so in the above example (global.header.xml) the component is of global scope, it is bound to a page region using header. Note there is no third parameter of the name (the sourceId binding to a specific page) in this example as this is a global scope component and therefore is used on all pages.

To provide a little further information on the Source ID, as noted above the value depends on the scope of the binding.  So for page it’s the pageId, template it’s the templateId and as noted above  global it’s always “global” so we ignore it and don’t make it part of the binding. The value is optional in the XML definitions for pages/templates/components because it can always be derived from the file name of the item – because the ID is bound in the filename.

Go ahead and create the global.header.xml as listed below:

/WEB-INF/classes/alfresco/site-data/components/global.header.xml

<?xml version='1.0' encoding='UTF-8'?>
<component>
<scope>global</scope>
<region-id>header</region-id>
<source-id>global</source-id>
<url>/header</url>
</component>

Web Scripts

One of the great things about SURF is the ability to run web scripts without requiring a connection to Alfresco. Introducing/detailing web scripts is out of scope for the purposes of this article however web scripts are discussed in detail on the Alfresco Wiki.  I would recommend a basic understanding of Web Scripts before continuing.

For the purposes of this article, we will be using very simple Web Scripts to return our HTML components i.e. the html components that will make up our page.  We actually have a couple of options here as to how the Web Scripts will work.  For example, we could componentise the HTML into different physical files stored in a specific directory, and then use a web script to actually include the required HTML fragment file.  Alternatively, we can simply store the HTML fragment within the Web Script Freemarker template file, so that this is the content that is rendered.  Either option is fine, but I will use the latter for absolute simplicity!  So for each Web Script, we will have two files – the XML descriptor file and the FTL renderer file.

You may have noticed above within the global.header.xml component definition that there is a parameter named <url>. This specifies the web script url to request. With this example, the web script to be executed is being called by /header. Lets setup the /header web script and the related Freemarker file to return the header HTML.

Web scripts within SURF are typically stored within /WEB-INF/classes/alfresco/site-webscripts.

• Create a web script descriptor file named header.get.desc.xml within /WEB-INF/classes/alfresco/site-webscripts.
• Add the following to the file:

/WEB-INF/classes/alfresco/site-webscripts/header.get.desc.xml
<webscript>
<shortname>Header</shortname>
<description>Loads global Header</description>
<url>/header</url>
</webscript>


• Save and close this file and create the accompanying Freemarker template within the same directory. Name it header.get.html.ftl.

Next we will chop out the HTML from our index.ftl that represents the region we are componentising i.e. the header HTML. Using my example, this is the header HTML that makes up outlined area in the image above.

• Edit the /WEB-INF/classes/alfresco/templates/index.ftl file and locate the HTML specific to your chosen global region e.g. header.
• Cut this code so that it is saved to the clipboard and then paste it into the newly created WEB-INF/classes/alfresco/site-webscripts/header.get.html.ftl file. My HTML looks like the following, obviously this will be different depending upon what HTML template you downloaded:

/WEB-INF/classes/alfresco/site-webscripts/header.get.html.ftl

<div id="top">
<p><a href="#">Home</a><a href="#">About</a><a href="#">Archive</a><a href="#">Sitemap</a></p>
<form id="search_engine" method="post" action="." accept-charset="UTF-8">
<p><input class="searchfield" name="search_query" type="text" id="keywords" value="Search Keywords" onfocus="document.forms['search_engine'].keywords.value='';" onblur="if (document.forms['search_engine'].keywords.value == '') document.forms['search_engine'].keywords.value='Search Keywords';" />
<input class="searchbutton" name="submit" type="submit" value="Search" /></p>
</form>
</div>
<div id="logo">
<img src="images/Alfresco-logo.jpg" width="225" height="65" alt="Alfresco Logo" />
</div>
<ul id="menu">
<li><a class="current" href="#">Home</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Products</a></li>
<li><a href="#">Clients</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">About Us</a></li>
<li><a href="#">Contact Us</a></li>
</ul>

Now we just need to reference the new component from the main index.ftl template – /WEB-INF/classes/alfresco/templates/index.ftl using the “region” tag.  This is effectively a pointer to the component.

• Edit the /WEB-INF/classes/alfresco/templates/index.ftl once again and locate the section of the page where the header HTML was previously removed.
• Insert the region tag pointing to the header component as follows:

<@region id="header" scope="global" />

• Save and close the file.

Once you have created and saved the two web script files and referenced the component from the template, we can refresh the web script environment to register the new script and test it. To refresh the web script environment access http://localhost:8080/surf/service/. You will see a button at the bottom of the page named “Refresh Web Scripts”. Select this and the new script will be registered. You can then test the Web Script by accessing it via the URL as listed within the descriptor file i.e. http://localhost:8080/surf/service/header. You should see the page header HTML:

Now when you hit the index home page once again, you should see your full page with the header global component being included – http://localhost:8080/surf/page?p=index

Page Scope Components

Once the header component is in place and running fine, we can move on to create some more components, this time using the page scope i.e. components that will change with each page. In my example, im going to build 2 for the home page named main and sidebar. I have highlighted where these components will be used within the index page:

The process is the same as we have just completed i.e.:

• Create the two component files within /WEB-INF/classes/alfresco/site-data/components
• Name them accordingly using scope.regionId.sourceId.xml
• Create two new web scripts to return the required HTML for each area of the page
• Chop the HTML out of the index.ftl page and paste into each of the corresponding web script FTL files
• Edit the index.ftl and put in the placeholders to reference the components
• Register the new web scripts
• clear the SURF cache

I will detail another example (as listed above), this time for the main content part of my page (the left hand body text).

• Create a new component within /WEB-INF/classes/alfresco/site-data/components named page.main.index.xml.
• Configure the component for page scope, mapping to a region of choice e.g. “main” and mapping the source id to the index page. Finally map the url to the web script with a suitable URL e.g. /index/main

/WEB-INF/classes/alfresco/site-data/components/page.main.index.xml

<?xml version='1.0' encoding='UTF-8'?>
<component>
<scope>page</scope>
<region-id>main</region-id>
<source-id>index</source-id>
<url>/index/main</url>
</component>

• Create the new web script within /WEB-INF/classes/alfresco/site-webscripts. First the descriptor file which I will call index.main.get.desc.xml. Make sure the url mapping matches that set in the component file above i.e. /index/main.

/WEB-INF/classes/alfresco/site-webscripts/index.main.get.desc.xml

<webscript>
<shortname>index</shortname>
<description>Returns the main page content for the index page.</description>
<url>/index/main</url>
</webscript>

• Next the Freemarker part of the web script. I will name it index.main.get.html.ftl. Chop out the HTML for the appropriate region from your index.ftl file and paste it into this file. Save again to /WEB-INF/classes/alfresco/site-webscripts.
• Edit the /WEB-INF/classes/alfresco/templates/index.ftl file again and put in the region placeholder where the component will be bound to. The id must match that set within the component definition.


<@region id="main" scope="page" />


• Register the new web script by hitting http://localhost:8080/surf/service/ and select “Refresh Web Scripts”
• Clear the SURF cache by visiting http://localhost:8080/surf/control/cache/invalidate
• Refresh your home page to see the component included – http://localhost:8080/surf/page?p=index

Summary

Once the above is completed you will have successfully setup a SURF page, created several components and bound them to the page in the appropriate areas. You will also have created some basic web scripts to return the HTML components. Go ahead and create any other required page components for your home page, and remember to use the appropriate scope e.g. global for a footer etc.

Its now probably a good time re visit the Wiki documentation on SURF as this will give you a good understanding of what other features and capabilities are available.  What we have completed here has barely scratched the surface, however should be useful for moving forward.  Next I will look at adding new pages and navigation.

Download

The finished web application is available for download here – SURF Part 1 – Getting Started.

See also – SURF Part 2 – Pages and Navigation and SURF Part 3 – Alfresco WCM Content

Download the example files here or

Web Form – blog-article.xsd

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pr="http://www.alfresco.org/alfresco/pr"
targetNamespace="http://www.alfresco.org/alfresco/pr"
elementFormDefault="qualified">

<!-- Blog Article categories -->
<xs:simpleType name="category">
<xs:restriction base="xs:normalizedString">
<xs:enumeration value="Product"/>
<xs:enumeration value="Web 2.0"/>
<xs:enumeration value="Internet"/>
<xs:enumeration value="Event"/>
<xs:enumeration value="Training"/>
</xs:restriction>
</xs:simpleType>

<!-- Blog Article fields -->
<xs:element name="blog_article">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:normalizedString"/>
<xs:element name="abstract" type="xs:normalizedString"/>
<xs:element name="body" type="xs:string" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="keywords" type="xs:normalizedString" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="category" type="pr:category" default="Internet"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

XSL Example – blog-article.xsl


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:pr="http://www.alfresco.org/alfresco/pr">

<xsl:output method="xml" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xsl:variable name="all_press_releases" select="alf:parseXMLDocuments('blog-article', '')"/>

<xsl:for-each select="$all_press_releases">
<h2><xsl:value-of select="pr:title"/></h2>
<h3><xsl:value-of select="pr:abstract"/></h3>
<p><xsl:value-of select="pr:abstract"/></p>
<br />
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Freemarker Example – blog-article.html.ftl

<#ftl ns_prefixes={"D":"http://www.alfresco.org/alfresco/pr", "pr":"http://www.alfresco.org/alfresco/pr"}>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

</head>
<body>

<#assign docs = alf.parseXMLDocuments('blog-article', '/')>
<#list docs as x>
<h2><a href="#">${x.title}</a></h2>
<h3>${x.abstract}</h3>
<p>${x.body}</p>
<br />
</#list>

</body>
</html>

Output Path Pattern

/${webapp}/partner-data/${xml['/*[name()="pe:partner_entrance"]/*[name()="pe:region"]']}/
${name}.xml

or

/${webapp}/partner-data/${xml['pe:partner_entrance']['pe:region']/${name}.xml

Sample XSD (Web Form)

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	   xmlns:pe="http://www.alfresco.org/alfresco/pe"
           targetNamespace="http://www.alfresco.org/alfresco/pe"
           elementFormDefault="qualified">

  <xs:element name="partner_entrance">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="region" type="xs:normalizedString"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Sample XML (Produced XML File)

<?xml version="1.0" encoding="UTF-8"?>
<pe:partner_entrance xmlns:alf="http://www.alfresco.org"
xmlns:chiba="http://chiba.sourceforge.net/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:pe="http://www.alfresco.org/alfresco/pe"
xmlns:xf="http://www.w3.org/2002/xforms"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<pe:region>APAC</pe:region>
</pe:partner_entrance>