Alfresco 3.2 Share: Pimp The Document-Library for Custom Document Types

What we´ve seen from my last post about the tales through the features of the newest Alfresco Version was just the first trick. The second trick belongs to the documentLibrary of share: How can we pimp the document-library for our custom Document-Types? Well, if we want to provide additional menu-items - to obtain just a document-list that belongs to one document-type, we have to configure and extend alfresco in both directions:

Alfresco Explorer
Alfresco Share

The left displayed image gives you a first imagination we want to implement the next steps.

When calls arriving Alfresco with the aim to retrieve a bunch of documents they will be processed by a WebScript that is mapping some JavaClasses in its JavaScript-Code. These classes are responsible to retrieve the results on using Alfresco-Service-API. Following example shows up an appropriated example how you can call these “backin-classes”. For instance, the object search isnt defined in any javascript-line but via Spring.

if (args["id"] != null) {
  var id = args["id"]; 
  object = search.findNode(id);
  if (object != null && args["shortQNames"] != null && args["shortQNames"] == "true") {
    model.put = object.toJSON(true);
  }

  model.put = object.toJSON(true);

}

Within the configuration-file script-services-context.xml we can find the definition of all scriptObjects that can be used via scripting. But thats not the matter i want to discuess here - i digress regarding the main-thematic here…

If the left site, of the documentlibrary is being in construction, a call is set via proxy-connector of share towards Alfresco-Explorer. So here comes the way: the doclist.get.js will be executed where the passed arguments of the call are processed in such a way, that a lucene-query is being constructed.

filterParams = getFilterParams(filter, parsedArgs, favourites)

The method getFilterParams is defined in the same directory in the file filters.lib.js. In that file theres a switch-construct defined which checks the passed filterId (i will introduce this filterId later) to made-up the query: so here you can add you´re case-block:

      case "butchersBay":

         var filterQuery = "+PATH:\"" + parsedArgs.rootNode.qnamePath + "//*\"";

         filterParams.query = filterQuery + ' AND +TYPE:"{http://www.dmc.de/ns/dmc/1.0}butchersBay"' ;

         break;

Right here, we have defined a case-block which is executed if a filterId is passed with the name “butchersBay” - our custom model. It doesnt matter whether its a realy existing content model but its a common approach. Very well, what brings out the query we´ve just defined? All items with type of “butchersBay” gettin returned from a specificaly path (e.g. /app:company_home/st:Sites/cm:MySite/cm:documentLibrary) - nothing else.

Now after we´ve done the first step, we have to change some things within Alfresco Share. Within the file filter.get.config.xml you define the filterId that we have already added to the alfresco-part of our current tale: the “butchersBay”-filterid:

<filter id="butchersBay" label="link.butchersBay" />

Now we´ve defined the filter which will be recognized by share on restart or on using the “Refresh WebScript”-Functionality. Now its time to add the language-part of that filter so we get displayed a human-readable text in the left pane of the documentlibrary. Therefore we open the file filter.get.properties and add the label link.butchersBay with an appropriated text. Very well done!

We´re ready for Takeoff. Test it guy!

August 4, 2009 | Filed Under Alfresco