Having released v0.2 of the Node Browser Component for Share this week and having put a bit of work into refactoring the underlying code, it seemed like a good time to write a quick guide to creating Administration Console Components for Share.
Like dashlets, Admin Console components are easily defined using a single web script, along with some supporting resources, and are therefore are automatically picked up by the framework once added to Share, with no additional configuration needed.
Alfresco’s Engineering team have added a number of new console components to the upcoming Swift release, and in addition to the Node Browser Share Extras provides two other additional components that you can add to your existing 3.3 or 3.4 installations.

• Complenting the Node Browser, Florian Maul’s JavaScript Console allows custom JavaScript code to be executed against the repository to display information or make changes. Loading and saving of scripts to and from the Data Dictionary is supported, as well as syntax highlighting and custom space contexts.
• Secondly the Create Bulk Users component allows administrators to create multiple users in the repository, based on CSV/TSV or JSON data, and is capable of auto-generating usernames and passwords, sending email notifications and logging of all user created.

Each of the three add-on pages has information on checking out a copy of the source code, which you can use as a basis for creating your own components. You should also grab a copy of the Sample Project bundle, which can be used as a template for your projects.
But before you dive into the code, it’s useful to have an understanding of the different parts that make up a component. So let’s step through each of them in turn, using the Create Bulk Users component as an example.
1. Web-tier web script
Technically, this is the only required part of the component. The component is bound into the application via this web script, which must be declared as a member of the admin-console family within its .desc.xml file. It should also define a single, unique URL, have a unique path and provide a HTML template to render the component’s UI.
The following XML is from the descriptor file (create-users.get.desc.xml) for the Create Bulk Users component, which should illustrate this.

<webscript>
   <shortname>Admin Console Create Users</shortname>
   <description>Administration Console - Create Users Console</description>
   <url>/extras/components/console/create-users</url>
   <family>admin-console</family>
</webscript>

Although it’s obviously possible to provide a JavaScript controller for the web script, it’s normally not necessary if you’re using a client-side module to encapsulate your business logic, as we’ll explore in the next section.
A HTML template (create-users.get.html.ftl in this example) is responsible for laying out out the basic skeleton mark-up of the component, including instantiation of any client-side modules being used.
Although technically optional you will normally also need a corresponding .head.ftl template (create-users.get.head.ftl in this example) to include your own basic, custom CSS file as well as any client-side JavaScript files the component requires.
You can see these templates and all other files that make up this web script in the Create Bulk Users source code under config/alfresco/site-webscripts.
2. Client-side component
It’s recommended that you use a client-side component for all but the most basic console components, since it will allow you to handle interactions with the user using standard script-based controls and widgets, and in a manner consistent with other admin console components.
Like dashlets that utilise client-side code, your client-side component will normally be defined in a dedicated .js file, which should be part of the static files (in addition to your CSS) supplied with your component.
The component should be defined using the standard Share pattern

1. Components are JavaScript classes, defined within a specific namespace, which can be instantiated in page components when needed
2. Components declare a constructor, then extend a base class using YAHOO.extend() and add their own class methods
3. Component definitions are contained within a function closure

But whereas dashlet classes would typically extend Alfresco.component.Base, admin console components extend Alfresco.ConsoleTool, which adds some additional fields and methods to support multiple panels and the YUI History Manager.
The component constructor is also slightly more complex than for a dashlet component, since to support the panel approach it is necessary to define within the constructor at least one inner panel class, plus an instantiation of each class.
Panels provide different views of a console component, and whereas simple components such as the Create Bulk Users Console have only one panel, it allows more complex components such as the Node Browser to define more than one (in this case one for the search panel and another for the node view panel).
Like the main component, the pattern used to define the panel class is the constuctor + YUI.extend() method, with panels extending the base class Alfresco.ConsolePanelHandler.
Although this might seem complex, once understood, it provides a consistent pattern which can be applied again and again to define as many admin console components as you need.
So wrapping all of this up, the general pattern for admin console client-side components is something like the following, as illustrated for the Create Bulk Users component.

// Ensure Extras namespace exists
if (typeof Extras == "undefined" || !Extras)
{
   var Extras = {};
}
(function() // Function closure
{
   ...
   Extras.ConsoleCreateUsers = function(htmlId) // Component constructor
   {
      ...
      FormPanelHandler = function FormPanelHandler_constructor() // Form panel constructor
      {
         FormPanelHandler.superclass.constructor.call(this, "form");
      };
      YAHOO.extend(FormPanelHandler, Alfresco.ConsolePanelHandler, // Extend Alfresco.ConsolePanelHandler
      {
         onLoad: function onLoad() // Fired on initial panel load
         {
            ...
         }
         ...
      });
      new FormPanelHandler(); // Instantiate panel instance
      return this;
   };
   ...
   YAHOO.extend(Extras.ConsoleCreateUsers, Alfresco.ConsoleTool,
   {
      options: // Console component configurable options
      {
         ...
      },
      onReady: function ConsoleCreateUsers_onReady() // Fired when component ready
      {
         ...
      },
      ...
   });
})(); // End function closure

Much of the code is stripped out here to convey the overall structure. In reality you would have other statements mixed in with the functions above, and all public classes, constructors and methods should be documented with appropriate JSDoc.
To explorer this some more, it’s recommended that you take a look at the client-side JavaScript files inside the JavaScript Console and Create Bulk User Console add-ons. You will find these files in the checked-out source code under the directory source/web.
3. Web-tier Spring configuration and message bundle
Most of the strings that appear in the admin console component UI should be externalised in your web script .properties file, and will be accessible from the Freemarker template of the web script via the root-scoped msg() function.
However, the name of your component also appears in the component list on the left hand side of the Admin Console, and since the page component responsible for rendering this does not have access the messages defined in your web script, it is necessary to provide a globally-scoped message bundle to provide some text for a label and a description of our component.
You can define your message bundle in any valid .properties file, but for the sake of convention I normally give mine a unique name and place them in the package alfresco/messages in my configuration. This is the file used for the Create Bulk Users component, which you can find in the source code under config/alfresco/messages/create-bulk-users.properties.

tool.create-users.label=Create Bulk Users
tool.create-users.description=Create repository users from CSV or JSON data

The message names should comply with this standard structure, with the part between the periods (.) being the same as the name of the console component’s web script, minus the method part. Since the name of the web script was create-users.get, the message names required are tool.create-users.label are and tool.create-users.description.
Lastly, a small piece of Spring configuration is needed to bind the message bundle into the application. This file must have a unique name with the suffix -context.xml, and be placed within the package org/springframework/extensions/surf. See the file config/org/springframework/extensions/create-bulk-users-context.xml in the Create Bulk Users source code for an example.
4. Repository components
Lastly, it’s likely that your admin console component will require some custom repository logic to perform your administration tasks. Normally this would take the form of one or more repository-tier web scripts, but other components such as a custom data model could also be required.
Fortunately the source directory structure used by the Sample Project in Share Extras (and by the three admin console add-ons) allows these to be placed in the same project, and you will find the repository web script create-users.post used by the Create Bulk Users component in the source code under config/alfresco/templates/webscripts.
Summary
You should now have an idea of the basic parts involved in an admin console components such as the three examples provided by Share Extras, and how they interact with each other.
You can study these examples to help you gain further understanding of how each of the four parts are implemented in practice, by checking out the source code for them. The JavaScript Console and Create Bulk Users examples are the simplest, so start there and look at the Node Browser if you need a multi-panel example.
The Sample Project provides a good skeleton project for you to define your own add-ons. Although the example code provided in it implements a web script, you can easily delete these and add your own files to define an admin console component, based on one of the three examples.
As well as giving you a basic directory structure, the project also gives you an Ant build script that you can use to build, test and distribute your add-on.
If you have any feedback, please leave a comment below.

Note: This post discusses how document previews may be customized in Alfresco Share 3.x. In version 4.0 onwards, an improved method is available, based on a plugin framework. See my presentation Customizing Web Previews at Alfresco’s DevCon 2012 event for more details.
I was asked by a partner today how one would go about enhancing the document details page in Share to better support previewing of specific file types.
Share’s built-in Flash previewer provides great browser-based previews across a whole range of different document types, from PowerPoint files to PDFs. But often you may only be dealing with a couple of different content types, and you may need a wider set of features in your viewer, specific to those content types.
Or, you may want to add support for an additional content type, not supported by the built-in web previewer.
Either way, it is not difficult to add support for other types of previewers. These could be based on Flash widgets, similar to the web previewer, or other technologies such as Java applets or ActiveX controls. Increasingly the HTML5 support in modern browsers, coupled with modern processors, can perform a lot of heavy lifting that previously required a plug-in.
A good example is provided by Share Extras, in the form of the Media Previews add-on. This uses a third-party Flash component to preview video and audio content in the browser, wrapped by a client-side JS module, but the basic approach is the same regardless of the technology you’re choosing. Basically, if you can embed a previewer or player on a website, you can integrate it into Share.

The first step is to read the documentation for the previewer you’re using. Work out which files are required to make it work and how they are referenced in the HTML mark-up on the page.
The files may consist of static resources such as Flash files, JavaScript scripts, CSS files and even compiled code packages (for Java/ActiveX). Sometimes they may be hosted on third-party servers, but normally you will need to bundle them yourself.
Assuming the latter case, you should add them into a new directory inside the Share webapp, and ideally in a collection of sub-directories within that. For example, the Media Previews files are placed in the directory /extras/components/preview, mirroring the structure used by Share’s web preview, but in a separate subdirectory reserved for Share Extras add-ons.
The next step is to modify the web script that hooks in the web previewer. You can find the files for this web-preview.get web script in the following directory in the Share webapp
WEB-INF/classes/alfresco/site-webscripts/org/alfresco/components/preview
Take a look in web-preview.get.html.ftl. You should see that it inserts the standard web previewer using a JavaScript module, instantiated inside a <script> element.
Now look inside the customised web-preview.get.html.ftl in the Media Previews source code. You will see that it uses a Freemarker <#if> directive to choose between the standard previewer and the custom ones, based on the content item’s MIME type.
Although the two custom previewers used here also use client-side code to instantiate themselves on the page, you could equally just use an <object> tag to reference the Flash .swf files directly. The benefit of wrapping the previewer with JavaScript code is that it allows you to apply more complex logic, such as detecting if the user has the correct version of Flash installed, or hooking the previewer into page events to update the preview when a new version of the content is uploaded.
Once you’re happy with the mark-up you want to add into the Freemarker file to insert your custom previewer, you can insert this into the file. But rather than overwriting the original, you should use Spring Surf’s override mechanism to separate your custom code from the original version.
To override the HTML template, take a copy of the web-preview.get.html.ftl and place it into the following directory, after first creating any missing directories.
<TOMCAT>/shared/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/preview
When you reference your static files that you added into the webapp earlier, you should use URLs such as ${url.context}/mydir/path/to/asset.swf, or in 3.4 ${url.context}/res/mydir/path/to/asset.swf. The url.context variable will automatically resolve to Share’s webapp context path, i.e. share by default, and mydir/path/to should be the directory structure you created in the webapp.
To reference the item’s content by URL, you can use an expression such as ${url.context}/proxy/alfresco/api/node/${node.nodeRef?replace("://", "/")}/content in your Freemarker markup. To reference the content of a named thumbnail, add /thumbnails/imgpreview to the end of the URL, where imgpreview is the name of the thumbnail.
If your previewer does use some JavaScript code or custom CSS styles from additional files which you’ve bundled, you will need to reference these files in web-preview.get.html.ftl. See the customised web-preview.get.html.ftl in Share Extras for an example, and note the override mechanism is exactly the same as for the .html.ftl template. You are recommended to use the <@script> and <@style> macros provided by component.head.inc, but note that with <@script> you will need to bundle a compressed version of your JavaScript file(s) with the -min.js suffix.
When you’ve finished making changes in your override files you can put these into effect by refreshing Share’s list of web scripts or by restarting your Tomcat server.
Once you’re happy with your customisation, you’ll want to create a dedicated project structure to manage your source files. So Share Extras also provide a sample project, complete with directory structure and an Ant build script that can be used to package up your add-on in JAR format.

I reorganised the front page of Share Extras the other week to organise the growing list of add-ons by type, which should hopefully make it easier to find specific extensions.
Today I added a new type on the front page, Pages, in order to categorise the latest add on – Content Expiration.

The new add-on is interesting for a couple of reasons. Firstly it contains a number of different types of extensions, which (like all the other add-ons on the site) are all bundled in a single JAR file.

• A custom model that defines a new Validity aspect
• A repository web script to return a list of all ‘expired’ content items
• A custom dashlet to allow a user to quickly see his or her expired items
• A full page definition to display a more detailed report for a user (or for all users)

It’s also interesting because the add-on started out as a single basic web script, which together with the custom model, we put together for the first version of the Alfresco Partner Site. If you take a look at the repository web script still has a HTML template attached to it, which provided the original user interface.
The basic steps we went through to adapt it for the Share UI could equally be applied to any basic repository web script. I wanted to share our approach as not only can it be used to bring your legacy web scripts up-to-date, but it’s also a perfect way of prototyping your extensions. First start off with a basic repository script, then build up a richer web-tier layer on top.

1. Define your basic repository script, by defining a JavaScript controller and a HTML template to present the data
2. Once you’re happy with your data, add a JSON template to the script to provide a machine-readable representation
3. Now define a basic Share dashlet, pulling in data from the repository script as JSON
4. If you’re tight on space in the dashlet, you can always link to the HTML version of the repository web script for the full report
5. Finally add a full-page version of your dashlet as a custom user or site page, and provide a link to this from the dashlet

I’ll follow up with a more detailed walk-through of this process, but in the meantime I’m interested to know if you have used a similar methodology in your own projects.
You can download version 0.1 of the Content Expiration add-on from the Downloads page.

I was really pleased by the feedback I got when I first talked about Share Extras at Alfresco’s Sales Kick-off in Orlando earlier this year, when I showed a few of the initial add-ons.
Since then, the list has grown significantly, but I was especially pleased when Peter joined the project and contributed his Google Site News Dashlet and CKEditor Form Control add-ons for Share. For me it marked the point where the project became more than the list of ideas that had been in my head.
Now as of last week two contributors have become four, with the addition of two great add-ons from Florian Maul and Romain Guinot. I’m really excited about these both.
Florian’s JavaScript Console add-on is an essential tool for developers building extensions for Alfresco, and complements my port of Dave Caruana’s original Node Browser. Like the Execute Script action, it also provides a useful tool for administrators who want to run one-off scripts against the Alfresco repository.

Romain’s Sample Audit Dashlet shows how different types of Audit information can be displayed in Share. This is a great addition since it shows how auditing can be used outside of the DOD Records Management module, to track specific events within the repository. Even custom audit applications are supported.

Not only do these new add-ons take the total number to almost 25, they also extend the number of languages supported in Share Extras, by providing examples in French and German, in addition to the English and Swedish examples added by myself and Peter.
Lastly, I’ve made a few significant improvements to the Site Poll Dashlet last week, which I couldn’t have done without the help of several others. So thanks to Toni de la Fuente for helping me to debug and fix a couple of previously unreproducible (at least for me) issues with the repository web scripts, to Jeff Potts for his suggestion to update the site activity feed when someone votes, and to Ed Mannion for reporting an obvious issue with using Date.now() on non-Mozilla browsers.
If you want to help contribute to Share Extras, you can do so in several ways. Of course new add-ons are always welcome but ideas, bug reports/fixes and translations are equally valid ways of helping out. More information is available on the Contribution Process page.