Aikau 1.0.85 – Data Lists

I was asked after I published my last blog post (on the progress being made with the FormsRuntimeService in Aikau) whether or not the example Data Lists page I showed would be available in the next release of Alfresco Share. At the time of writing it is not planned on the road map, however that does not stop you from making use of it.

The Aikau JAR contains a number of lib files that can be imported into WebScripts to quickly build standard pages. This previous blog post describes how to provide the Aikau version of the Document Library as a site page.

The steps outlined in that post can be loosely followed, but the main difference will be in the JavaScript controller for the WebScript, which should look like this:

<import resource="classpath:/alfresco/site-webscripts/org/alfresco/share/imports/share-header.lib.js">
<import resource="classpath:/alfresco/site-webscripts/org/alfresco/share/imports/share-footer.lib.js">
<import resource="classpath:alfresco/site-webscripts/org/alfresco/aikau/{aikauVersion}/libs/pages/datalists.lib.js">

var siteId = ( != null) ? : "";

var headerServices = getHeaderServices();
var headerWidgets = getHeaderModel(getPageTitle());

var dataListServices = getDataListServices();
var dataListWidgets = getDataListWidgets({
   siteId: siteId
var services = headerServices.concat(dataListServices);


model.jsonModel = getFooterModel(services, headerWidgets);
model.jsonModel.groupMemberships =["alfUserGroups"];

However, for convenience I’ve added a sample extension to a GitHub repository so that you can just download and try it out. Simply download the JAR file and place it into the share/WEB-INF/lib file and restart Share and you’ll be able to add this page to existing sites.

It is important to understand that at the time of writing this page is unsupported by Alfresco and is provided purely for educational purposes. The FormsRuntimeService and DataListService are both still under development and are not ready for production use. Having said that, it would be exceptionally valuable to get feedback and bugs reported so that we can continue to improve these until they are ready for production use.

This video shows the page in action…




Aikau 1.0.84 – Forms Runtime Service with Tasks Page

In my last post I described some work I’d done to provide a service within Aikau to support the XML based forms runtime in Share. In this post I attached a video demonstrating a page where the service could be tested by requesting a form from Share and seeing it mapped into a Aikau widgets.

Whilst fine in principal it doesn’t actually provide much “real-world” use. Therefore I wanted to plug the service into a page to test it out in a more user focused way. The lack of support for the forms runtime has (up until now) been a barrier for converting more of Share to be implemented with Aikau.

I’ve started to explore how easy it is to recreate existing Share pages using Aikau and an obvious candidate for testing out the FormsRuntimeService was the “My Tasks” page. I’ve attached a video showing this page in action to demonstrate how we can start to leverage this new service and port more of Share to Aikau.

The service is still a work in progress and (at the time of writing) is not yet ready for production use. I’ll keep posting updates as it improves – but as this isn’t my primary work activity at the moment, the development rate may not be rapid. However, any feedback you have on this effort would be gratefully received – even if it’s just to say that it’s something that you’d be interested in using when it’s ready!

Update 5th Sept 2016 :

I’ve created another example, this time using Data Lists:

Alfresco SDK 3 beta 1 available

We are pleased to announce the first beta of Alfresco SDK 3.0!

This release has been in the works for a long time, and addresses a lot of the issues and limitations we currently experience with the latest SDK releases.

By releasing this first beta we wish to get feedback on the overall structure, setup, compatibility and hot reloading.
Please raise issues on Github or reach out to us directly.

We welcome all feedback.

What’s new

  • JAR first approach, standardised JAR project structure
  • All runner logic is centralized in the Alfresco Maven Plugin (no runner projects)
  • Flexible configuration: Enable Repository? Enable Share? Enable Solr? Enable H2? Enable Tomcat? All configurable via the plugin
  • No forced parent pom
  • Low impact on your project
  • AMP as an optional assembly
  • Install 3rd party addons (and control the order they are applied)
  • All-in-one, Repository and Share archetypes
  • Hot reloading via JRebel
  • Support for all releases from 5.0 to 5.2.a – across community and enterprise
  • Support for 4.2 (currently Share module requires you to add two dependencies by hand)
  • Standalone Repository archetype supports Solr4

What’s yet to come

How to get it

Martin Bergljung has written up an in-depth user guide that will walk you through all the jucy details, you can find it here.

If you just want to get it up and running here and now, here’s the steps you need:

EDIT: We have just released SDK 3.0.0-beta-3 to address this issue. The instructions below have been changed to reflect beta-3.

The Alfresco SDK 3.0.0-beta-3 has been released to Maven Central’s staging area. You need to add this as a repository to your ~/.m2/settings.xml:


Once you’ve added it, you can now create a new project based on the new archetypes using this command:

mvn archetype:generate -DarchetypeCatalog=

Select the archetype you want, enter the properties and execute (for Linux/Mac) or run.bat (for Windows).

Thoughts, comments or other feedback? Let us know on Github, comments below, email, IRC etc.

Aikau 1.0.76 – Form Runtime Support

One of the comments I had on my last blog post point out that one of the main problems with using Aikau is that it doesn’t support the XML-based Forms Runtime that Share uses to render forms using the old YUI2 controls.

I decided to take a look into this issue and see what could be done about it. The major issue with the existing implementation is that it the REST APIs return HTML fragments containing references to the YUI2 controls – it’s just not possible to extract the pure data from the API as it is not.

Fortunately one of the many great things about the WebScripts implementation is their ability to be extended and have multiple output formats defined for them. This meant that I was able to extend the FormUIGet Java controller for the WebScript to generate a pure JSON output for the forms data and then define a new WebScript descriptor to access that data.

Because the Forms Runtime only applies to Share and not to to standalone clients, it was necessary to package the Java class and Spring bean configuration into a separate JAR file. This means that to leverage this new capability of Aikau you now need to include an additional dependency in your AMP files (or simply download the JAR from our Maven repository and copy it into the “share/WEB-INF/lib” folder as I do in my demo video).

Now that we can access the forms runtime data we need to be able to convert the form definition into an Aikau forms model. This is capability is provided by the “alfresco/services/FormsRuntimeService” module. At the moment this module is not fully complete – but I wanted to get something working out to the Community as soon as possible in order to get feedback and hopefully some collaborative development.

At the moment only a couple of YUI2 controls are mapped to Aikau controls, but both edit and view modes are supported and the ability to configure in custom mappings is something that will be added in later. Constraints are also only partially handled, but the remaining constraints will be added soon.

The main objective for this first release was to get something out to the Community that demonstrated the end-to-end capability. A test page has been bundled with the Aikau that you can try out. Everything has been done to support multiple versions of both the Aikau and Forms-Runtime-Support JARs.

Take a look at the demo video and let me know what you think… please feel free to add comments to the JIRA epic or raise issues on GitHub to discuss where to take this next.

EDIT: Update for 1.0.77

We’ve made some more improvements that are shown here:


Improving Aikau Education


In my last blog post I talked about the perspective I’d gained by working in another team at Alfresco that has been using Aikau. For the last 18 months the Aikau team has been so head down in development trying to provide features and fixes for internal teams, customers and the community that we’ve not had much opportunity to focus on reviewing and improving the educational material that is available for Aikau.

Interestingly with the advent of the new Angular based UI framework and the conclusion of a number of major Alfresco projects that use Aikau the heat is now off us and I’ve had some time to start looking at what resources are available and how we can improve the situation.

At this point I think it’s important to state that as far as I’m aware Aikau development is going to continue and that if you want to develop a user interface for Alfresco – particularly if you want to customize or add new pages to Share – then Aikau is still the recommended framework.

Alfresco is still actively using Aikau (most notably for Records Management in Share) which is hugely important for its business. The use of Aikau is never going to be the headline feature in an Alfresco release, but it’s usually there in the background getting the job done.

Eating Our Own Dog Food

I decided to have a go at reproducing some existing YUI2 based features of Share using Aikau to try and showcase how rapid development can be – but more importantly to try to understand where the gaps might be in available education.

I’ve started with the “People” page and you can watch me creating this page from scratch in a brand new client in the video below. It’s a bit rough around the edges, for which I make no apologies – but hopefully it will be informative.


Feedback Wanted !

The full disclosure is that the first time I went through the process I found that some of the JSDoc could be better, we could provide some additional widgets and that the UserService needed updating – and I took care of these issues before recording the demo.

However, I would urge that anyone attempting to do any development that has similar problems to report them as a GitHub issue so that they can be addressed.

I’d also love your feedback on whether or not this medium is effective or not, whether I should record more demos and what they should be focused on. I’ve already got an idea for a follow up in developing some custom widgets to go on the page – but it might be better to work through an entirely different use case – Data Lists perhaps?

I’d also welcome any suggestions on other approaches we could take to help people get up to speed with Alfresco development using Aikau.

Accessing the Code

I’ve created a GitHub repository containing the application that I built in the video. I’ve tagged the commit with the code (and will continue to tag each commit if I do more examples) so that it’s easy to try out the code and experiment with it yourself.

Announcing Alfresco NG2 Components

By bringing together content & process, Alfresco is a unique platform for building solutions and business applications.

As a platform company, it is critical for us to ensure that our developer ecosystem is successful and our community, customers, and partners can deliver applications on top of Alfresco as quickly as possible.

Earlier this year, we embarked on a customer, partner, and community consultation exercise and analysing market data and industry trends. We got a lot of feedback from customers, partners and community that they are focusing more and more on Angular. John Newton wrote a nice blog post in May about our direction to move towards Angular and focus on Experience Design.

To support our strategy Alfresco invested in a new development organisation dedicated to frameworks, tools, and APIs to help reduce the time to develop and deliver applications across both ECM (Alfresco One) and BPM (Activiti). The organisation is headed by John Sotiropoulos our VP of Developer Products who works closely with me to deliver our strategy .

Our Application Development Framework is our overall offering that helps our developer ecosystem build applications on top of Alfresco and Activiti and provide a rapid, consistent, and unified developer experience. We have articulated our strategy in a set of slides, but like any vision it will evolve.

We also want to break the habit of doing development “in the dark” and be open and transparent about the process, revitalising our community. This is why we’re making the source of our work so far available – and we want your feedback!

Today we are announcing a brand new Javascript API, a set of NG2 components and a couple of Yeoman generators to help bootstrap your Angular2 project and components.

Alfresco Javascript API
One thing we keep hearing over and over again is that developers spend a significant portion of time doing boilerplate code. Bootstrapping a project from scratch takes time. Dealing with APIs, authentication and the lower levels are key. To help ease all of this we’ve developed a new API that wraps around our new v1 REST APIs.

The Javascript API is not tied into any specific framework. This means you can use this in all javascript based applications, whether it is a node.js backend application or a plain vanilla javascript page.

The goal with the Alfresco Javascript API is simple – we want to provide a great developer experience for developers consuming our APIs.

Be sure to check it out –

Alfresco NG2 Components
Building on top of the Alfresco Javascript API we have built a core set of components that are easy to use, configure and extend to fit your needs.

Initially we have focused on a set of high level components:

  • ng2-alfresco-core – Core services and utilities to help power components
  • ng2-alfresco-datatable – A simple file list
  • ng2-alfresco-documentlist – An advanced list of documents
  • ng2-alfresco-login – A login component
  • ng2-alfresco-search – A basic search component
  • ng2-alfresco-upload – Advanced upload capabilities that integrates with lists
  • ng2-alfresco-viewer – A PDF.js based viewer to preview content

Once you start using these components you will notice that they are all styled with our new design guidelines based on Google Material Design.

Be sure to check it out –

Alfresco NG2 App Generator
To help you get started as quickly as possible we have created a Yeoman generator to scaffold and generate your project. The generator will ask you a set of questions, but also offer to include and wire in the components listed above.

Be sure to check it out –

Get started today!
We have a bunch of good material to help you get up and running. This page gives you a brief dive on how the components and the javascript api ties together.

The biggest requirement to get up and running is the 201606 Community Edition since we rely exclusively on the new v1 REST APIs. On top of this you need to have CORS enabled.

Since the NG2 components are purely client side components you need to have the Alfresco Platform allow requests from other domains, otherwise your browser will not allow the javascript api to make XHR requests.

First you need to download 201606 Community Edition, then download the “enablecors” module here. Put the JAR file in $ALF_HOME/modules/platform. The module contains a web fragment that configures CORS for the repository. You can find more detailed information here.

While you’re at it, why not include the REST API Explorer? Grab the war file here and put it in $ALF_HOME/tomcat/webapps.

Start up Alfresco and leave it running.

Next up is making sure you have Node.js installed. You will need to have a minimum version of 5 – we recommend you use the latest.

Once Node.js is installed you need to install the Yeoman generator:
npm install -g yo
npm install -g generator-ng2-alfresco-app

Run the generator, followed by “npm start” and you’re good to go!

Components documentation
Now that you have everything up and running, it’s time to have a look the component catalog and figure out how to configure and extend the components. Go to to browse the components and view the documentation. We make a point of having both sample code and documentation as part of the definition of done. This way we ensure we have up to date documentation for our developers from day one.

We want your feedback
We recognise this is early days for our new “Application Development Framework”, but we want to have an open and transparent development process. We are continuing to develop more components and improve on the existing ones, but we would love to hear your thoughts and ideas. We will also welcome any pull requests with new features, bug fixes, enhancements to documentation, samples or anything else you would like to contribute.

If you want to contribute we are all set up on Github, please make sure to read the code contribution acceptance criteria, our Code Style, Commit format and Definition of Done.

Next steps
We are planning a Tech Talk Live next week, Wednesday 6th of July where we will present and demo what we have and we have a series of blog posts planned on how to use the individual components. Stay tuned!

Writing for Alfresco

A year ago we published a survey, asking you if Alfresco products use User Interface (UI) terms and language that makes sense.

We had a great response from 200 Alfresco users, developers through to end users, and since then we’ve been busy putting the feedback you gave us to good use.

Survey Results
We’ll have a look at what we’ve been up to in a minute, but first (as promised previously) we’ll show you some of the survey results. We found that the feedback to the following statements was particularly useful in validating our thoughts behind conducting the survey in the first place.



It was clear from these results that we could make improvements to give real benefit to the day-to-day experience of Alfresco users.

When we looked at the detailed responses, many of you felt that the language and tone we used was perfectly ok. But there were plenty of useful comments, both general and specific, on what could be improved.
And one thing came up again and again; that the language in Alfresco products is

“too technical!”

This is something we were already aware of, and if you check this previous post then you’ll see that we’d been addressing it in recent new features and products. So it was great to see that we’ve been heading in the right direction.

What we did after the survey
Once we’d sifted through and evaluated the feedback, we chunked it into a backlog of areas to fix. There are a lot of words in Alfresco – the Alfresco platform and Alfresco Share alone contain well over 40,000 individual words, and that’s before we get on to Activiti, Records Management, Alfresco Mobile, etc.

Using the survey feedback we identified the key places where we could make improvements, and we now have a playbook in place to make these fixes.

Of course, at the same time as we were doing this our engineers continued to be busy developing new products and features, all the time adding new terminology.

Writing for Alfresco
As we built on how we wanted Alfresco terminology to be, we decided to set up some guidelines to ensure that we could develop consistency across the product range. We used a number of tools to decide what the Alfresco “voice” should be, including the survey results, a ton of analysis of other research data, user testing, and of course, looking at other products.

As we looked at the tone and voice guidelines for a well-known email app, Thomas De Meo, our VP of Product Management suggested that the app was “the kind of guy you want to hang out with”. That struck a chord and so we thought, well what do we want Alfresco to be? The answer was “the kind of person you want to work with”.

We built on that and have now published a set of guidelines – “Alfresco Voice – writing for the user interface”. This covers all aspects of product language including what tone to use and what words to avoid, how to write for a global audience, keeping it simple, and how to make that error message useful instead of an overly-technical nightmare.

The style and tone in this guide is how future Alfresco products and features will sound. And we’re gradually working through the existing terminology to bring it in line.

User Assistance and Experience Design representatives now work with the Alfresco Engineering agile teams to design the terminology in parallel with feature development. This means that the words you read in our products have been carefully designed and considered to compliment the UI and user level, and to make Alfresco products simple to use.

We hope that you’ll notice the difference, and see how we’ve taken all your feedback on board. And if you’re an Alfresco developer, then go ahead and use the guidelines for your own add-ons or customizations –

writing for alfresco

Developing With Aikau – Another Perspective

I’ve recently been moved out of the Aikau team in order to provide some assistance to a feature team that are using Aikau. This change in role has given me a very useful insight into the problems that developers have when using Aikau. When working on Aikau I only ever get to see a fragment of the overall implementation – I get very little context so I never know if the overall implementation is being done in a sensible way.

It’s important to remember that we never think of Aikau as being “done”. Our widgets are always open to further iteration to either add more capabilities, refactor them for better performance, improve the design and fix any bugs. We also don’t consider them to be an exhaustive set by any means – we know that more widgets will be needed.

What we don’t know is what bugs exist, what features could be added and what widgets are missing. We rely on our feature teams, customers, partners and community to tell us what is required.

When I started working on the feature I was given in the new team I almost immediately identified one bug and 3 features (1,2,3) that were required. This wasn’t a brand new requirement for my new feature team but these requirements hadn’t been identified.

Trying to act like a good community citizen I raised these as issues on JIRA and then being a model community citizen I created pull requests to fix the problem and add the features following the well defined acceptance criteria.

Of course it’s much easier to do this when you have an awareness of what is available and how things are meant to work in a framework when you have been involved in the development of that framework. Having said that I really want to encourage you to just ask the question and start the dialog with us.

It should hopefully be clear from the closed issues that we’re more than happy to answer questions when they’re asked.

The flip side of the coin is to not start a dialog but to simply complain about something without trying to dig into the details like with this blog post published last week. Whilst I understand that something might not be immediately obvious when trying to use Aikau (we’re well aware that documentation could be improved, we just haven’t been allocated the resources to do enough about it) we will try and help you if we can – even if that help is simply explaining why something is the way it is.

We aren’t promising to implement all your feature requests (far from it in fact!) but we are committed to genuine bugs in our coding (meaning a defect in the intended behaviour of an individual widget or service).

We’re starting to see increased Community interaction – more issues raised, more traffic, more GitHub stars. What we’d really like to see is more pull requests – and if something is blocking you from making a pull request then we’d like to know what that impediment is so that we can remove it.

This is going to be especially important during my reassignment as it means that we might not be able to implement community requested features as we have in the past – but we will endeavour to try to stay on top of the bugs that you raise.

Thanks again for your ongoing support !

Separating Platform and Share in Alfresco 5.1

The content of this post is mostly based on the talk I gave at the amazing BeeCon 2016 conference, in Brussels.

Alfresco One 5.1, released in March 2016, introduced a separation in the packaging between Alfresco One Platform and Alfresco One Share. I want to explain a bit behind the motivations for this; how we did it and what’s in it for you.

Why separate?

The main reason was to have different release lifecycles between Platform and Share. That means we can now, for instance, release versions of Share more often, without having to retest the whole Platform (which is very costly with all the databases, application servers, etc.)

The releases are also smaller and more incremental. We hope it makes it easier to upgrade the Platform while keeping a heavily modified Share: this seems to be a common use case!

From a more “Alfresco Engineering” point-of-view, there are more reasons to split: the combined codebase was huge, and we couldn’t really assign it to a single team. Now, we have reorganised our teams, and we have proper Platform and Share teams, each taking responsibility for their own codebase. Ownership is simpler, the issue backlog is smaller, and we are overall more agile.

Where to cut?

We needed to decide where to draw the line between Platform and Share code.

An initial idea was to create one codebase for each artifact (jar or war): alfresco-core.jar, alfresco-data-model.jar, etc. But that would have been a bit too many to handle.

The most obvious was to simply cut between the two war files: alfresco.war and share.war. However, that meant that we couldn’t update the Share APIs (webscripts, etc.) when we update Share, since they are actually delivered in alfresco.war.

We got inspiration from this blog post from Netflix. The idea is explained in this picture, which I have shamelessly reused here:


Netflix has to support a lot of very different devices: browsers, Wii, XBox, iPhones, …
To add some flexibility to their server-side code, they created this notion of Client Adapter Code. It is delivered at the same time as the client, but actually sits on the server-side, allowing each client to evolve and manage their own API within their own lifecycle. This is exactly what we needed!

The Share codebase therefore produces a Platform-side component, called Share Services, which is packaged as an AMP. It contains the /slingshot webscripts, the sample site bootstrap, and the datalist and wiki services. The alfresco-share-services.amp is applied to alfresco.war: its source is in Share, but it runs in the Platform.


Separating common pieces

Some components are used by both Platform and Share. We needed to separate each of them into their own codebase too, otherwise we couldn’t release Share without releasing Platform. So we extracted these components, and now they have their own lifecycle:

All these are kept in the same Subversion server. This is much more convenient when we need to merge fixes from old branches to and from 5.1. We may move these to Git in the future.

Of course, we also had to cut a few cyclic dependencies, but it wasn’t too bad…

What do we package?

Community Edition

We had discussions on whether we should provide Platform and Share packages for the Community Edition. We decided not to, because Community is typically used on single node installations. Also, it’s quite often an entry point for people researching Alfresco, so we wanted to keep things simple there. (I had people complaining about this at BeeCon, but I’m still looking for a valid use case…)

Since it will contain components with different versions, we had to find a different versioning convention. We settled on a version based on the year and month: 201605. We also add a -GA (General Availability) or -EA (Early Access) suffix, to make clear the level of testing it had. For instance, the latest version of Community is called 201605-GA, and it contains:

  • Alfresco Platform 5.1.g (a security issue fix from 5.1.f)
  • Alfresco Share 5.1.f
  • GoogleDocs integration 3.0.3
  • Alfresco Office Services 1.1

Share separation does benefit Community Edition though, because we can ship more often, and include only what has changed, as with 201605-GA

Enterprise Edition

For clusters and complex setups, as supported by Alfresco One, it is useful to install Platform and Share separately, so we have provided separate installers for each of them. The Share one installs a separate Tomcat instance and just deploys share.war in it. It also copies the Share Services AMP into the installation folder, but you will need to apply it yourself to the Platform installation it connects to – see the documentation.

We thought a “full” installer, with both Platform and Share, was still needed. It is convenient for people who want to try Alfresco without knowing much about its architecture, or simply for standalone instances. The version of this all-in-one installer for Alfresco One still reflects the version number of the Platform, i.e. 5.1. We are waiting to see what people think of the Community Edition naming before we change the naming for Alfresco One.

In summary, here are the different packages we offer for the Enterprise Edition:


What next?

We didn’t go as far as we had planned. For 5.1.x, the source codebases are separated, but we are still going to release Platform and Share at the same time, with the same version number. We lacked time to test each component individually. Previously, Alfresco could be tested as a whole and it was fine. For instance, JLan was mostly tested by integration tests in the Platform. Now, we need to make sure JLan works on its own, before we release it, because we may have to release it just for a Share version, without running the Platform tests against it.

We also didn’t think we could ensure that Platform 5.1.X would work with Share 5.1.Y – once again due to the lack of tests and of clear public APIs between the components. (Although this improved in 5.1 – see the BCK project for instance, or the documentation on extension points.)

In the near future, we are planning to separate more components from the Platform. The most likely candidates are currently:

  • Search, as part of the upgrade to Solr 6
  • More of Share: there are parts of the Platform that we think should belong to Share, such as calendars, blogs, … And we still want to release it separately in the future!
  • Enterprise extensions, to upgrade from a Community Edition

I’m not making promises of course, but this is on the roadmap, so it looks good!

Adding the Aikau Document Library as a Site Page in Share


In previous blog posts I’ve shown examples of how the Aikau version of the Document Library can be used both within Share and in standalone clients. In this blog post I thought it might be useful to provide a more in-depth guide on how to add the Aikau Document Library as a site page in Share, as well as to provide a general status update on progress.


It’s important to understand that the Aikau team is a “Component Team” and not a “Feature Team”. This means that we provide the components (in this case Aikau widgets and services) for other teams to deliver features or products.

At the time of writing there is no feature team driving the replacement of the old YUI2 Document Library with the Aikau version – nor indeed has there ever been. Aikau has always predominantly been about re-use and the Document Library has progressed because other features have required Document Library related widgets.

There are two epics in JIRA that list the current tasks required to achieve feature parity with the YUI2 Document Library: one for general features and one for action support. Reviewing these epics should give an overview of what work remains.

In general the Document Library is quite functional and should be more than adequate for covering a large number of use cases. The following steps and code is available within the following GitHub repository and all of the files described before are linked to the specific files in that repository.

Create the Aikau Document Library Page

The first step is to create the WebScripts for the new page. Create the WebScript descriptor file…


  <shortname>Document Library Example </shortname>
  <description>This provides an example of building the standard Document Library using the doclib.lib.js library file.</description>

Now let’s create the template…



The properties file is slightly more involved…


This file just contains an instruction to import two other properties files:

  • org/alfresco/share/imports/share-header.lib
  • org/alfresco/aikau/{aikauVersion}/libs/doclib/doclib.lib

This process is described in more detail in this previous blog post.

The last WebScript file required is the JavaScript controller… this is where most of the code goes:


The first thing is to import the required controller files…

<import resource="classpath:/alfresco/site-webscripts/org/alfresco/share/imports/share-header.lib.js">
<import resource="classpath:/alfresco/site-webscripts/org/alfresco/share/imports/share-footer.lib.js">
<import resource="classpath:alfresco/site-webscripts/org/alfresco/aikau/{aikauVersion}/libs/doclib/doclib.lib.js">

Now you need to import the services and widgets that the header uses…

var services = getHeaderServices();
var widgets = getHeaderModel(msg.get("aikau.doclib.title"));

The header services need to be combined with the services required by the Document Library. These can be retrieved by calling getDocumentLibraryServices.

services = services.concat(getDocumentLibraryServices());

Now use the getDocLib function to create the model for the Document Library. The main data to provide is the site id which is available from a template argument and the name of the folder in which the Document Library files can be found within the site folder (typically “documentLibrary”).

var docLib = getDocLib({
  containerId: "documentLibrary"

This model needs to be added to the header model….


Finally we need to call getFooterModel passing in the header and Document Library services and widgets. This is required because the footer model wraps everything else on the page.

model.jsonModel = getFooterModel(services, widgets);

Make the Document Library a Site Page

In this previous post I describe the process for adding Aikau pages in general – so please refer to that for a slightly more in-depth description of the process.

Create a new Surf Page definition that will provide the title and description of the page as shown when customizing sites.


<?xml version='1.0' encoding='UTF-8'?>
  <title>Aikau Document Library</title>
  <description>The Aikau Document Library</description>

Now create an extension module to ensure that the site page is an option when customizing sites.


      <id>Aikau Document Library Site Page</id>
      <evaluator type="default.extensibility.evaluator"/>
        <config evaluator="string-compare" condition="SitePages" replace="false">
            <page id="AikauDocLib">dp/ws/DocLib</page>

Now you need to pull these files together into a single JAR and copy them to the “share/WEB-INF/lib” folder.


Restart Share and go to any site and customize it – you should see the “Aikau Document Library” in the list of available pages:


Drag it into the “Current Site Pages” list and click “OK”


Now you should have a new link for the “Aikau Document Library” (if you have a lot of site pages, try looking under the “More” drop-down menu!). Click on the link and you’ll be taken to your the Aikau Document Library:


What Are The Benefits and Limitations?

One of the main reasons for creating an Aikau version of the Document Library was to make customization much simpler. Through the use of the Aikau model it is significantly easier to make fine-grained changes to the Document Library. Some things you could do for example would be:

  • Add custom views
  • Edit existing views (add or remove the metadata that is displayed)
  • Filter the displayed actions or add entirely new actions
  • Render only specific sections of the Document Library (the tree, breadcrumb trail or list for example)
  • Edit the menu options that are displayed

The Aikau version also has a few features that are not included with the original Document Library:

  • Drag-and-drop upload new version
  • Inline document preview
  • Inline commenting
  • Inline content creation

As of Aikau 1.0.68 the Document Library uses a new non-modal upload file design. See screenshot below:


The main limitation is that there is not yet support for all the actions that you would find in the existing Document Library (you can review the missing actions in the previously linked epic).

The other potential limitation is the lack of integration with the forms runtime. This means that when editing properties for custom types the XML forms configuration will not be represented.

Despite these issues the Aikau Document Library should still be useful for many use cases – especially where serious customization of the existing Document Library is required.