Tag: Alfresco Developer Guide

Happy 5th Birthday, Alfresco Developer Guide!

Birthday Cake by Will ClaytonIt is hard to believe that the Alfresco Developer Guide was published five years ago this month (really, the tail end of October). My goal at the time was to help flatten the learning curve around the Alfresco platform and encourage people still using legacy ECM systems to make the leap. Based on the number of people who come up to me at meetups, conferences, and other events to tell me how much the book helped their projects, their teams, and even their careers, I’d say that goal was met and that makes me very happy.

The product and the company have definitely evolved a lot since 2008. The chapter on WCM is no longer relevant. The section on Single Sign-On is out-of-date. The book was written before Alfresco Share existed. And, at the time, jBPM was the only workflow engine in the product and Solr was not yet on the scene, nor was mobile. Both JCR and the native Web Services APIs have given way to CMIS as the preferred API. And Maven and AMPs are the recommended way to manage dependencies, run builds, and package extensions.

But the fundamentals of content modeling haven’t changed. Rules, actions, and behaviors are still great ways to automate content processing. Web Scripts are vital to any developer’s understanding of Alfresco, including those doing Share customizations. And, though the preferred workflow engine is Activiti rather than jBPM, the basics of how to design and deploy content-centric business processes in Alfresco haven’t changed that much.

So where do we go from here? The book was originally based on a set of tutorials I published here on ecmarchitect. Last year I created second editions of many of the tutorials to catch them up with major advancements in the platform. For example, the custom content types tutorial now includes Share configuration and CMIS. The custom actions tutorial now includes how to write Share UI actions. And the workflow tutorial now assumes Activiti and Alfresco Share rather than jBPM and Alfresco Explorer.

The source code that accompanied the book lives in Google Code, but I recently moved the source code that accompanies the tutorials to GitHub. I’m busy refactoring the tutorial source code to use Maven and AMPs. I’ve also started moving the actual tutorial text to markdown and am checking it in to GitHub so that the community can help me revise it and keep it up-to-date.

I learned a lot writing that first book. One of the lessons is to always work with co-authors. That made a big difference on CMIS and Apache Chemistry in Action. I hope that book helps as many people as the Alfresco Developer Guide did and I look forward to reflecting back on how CMIS has changed on that book’s fifth birthday in 2018.

Any interest in a pre-3.4 five star ratings widget for Alfresco Share?

One of the examples I put in the Alfresco Developer Guide is a five star ratings widget. The example company in the book, SomeCo, uses it to let their web site users rate whitepapers published on the site. Metaversant recently took that code and implemented it in a production web site, and that client gave us permission to take the code (which wasn’t really changed that much from the book anyway) and release it as open source.

But in Alfresco 3.4 Community and Enterprise, Alfresco has implemented partial ratings functionality. Right now, it consists of the back-end, repository tier services and it is darn close to what’s in the book.

With the back end in place, I expect Alfresco to release ratings functionality in the Share front-end in an upcoming release. So, I’m somewhat reluctant to package up my ratings stuff and release it as it is partially obsolete in 3.4 anyway. On the other hand, it would give those of you on releases earlier than 3.4 a functional ratings widget, and, with some adjustments, I could make the front-end work with Alfresco’s rating service in 3.4, which would mean functional ratings in Share for those of you that have already upgraded.

If the code was ready to go, I’d just package it up and if only one person used it, great. But, the client we did the widget for was using a heavily customized version of Share–we didn’t integrate the widget into the out-of-the-box document library or document details page. That’s the last bit of work that needs to be done. Even if there is no interest, I might do it anyway just to have as an example. But, I’d be even more motivated if there were folks out there who would use it in their production implementations.

So what do you say? Any interest? Take the survey below and let me know.

Create your free online surveys with SurveyMonkey, the world’s leading questionnaire tool.

Alfresco Developer Guide source updated, uploaded to Google Code

Back in July of 2009, I did a reorg of the source code that accompanies the Alfresco Developer Guide. Shortly after that I validated against 3.2 Enterprise, but I didn’t keep up with the Alfresco releases after that. I’m happy to say that I’ve caught up. And, to make it easier for you to get to the source code, I’ve checked it all in to a Google Code project.

So, if you’re reading the book and you’re finding a couple of problems with the source code on Alfresco versions after 3.2 Enterprise, go get a version that matches up with the chapter you are on and the release of Alfresco you are running, and see if it fixes the problem.

I’ve now validated that the code works with the following versions:

  • Alfresco 2.2.4 Enterprise
  • Alfresco 3d Labs
  • Alfresco 3.0.1 Enterprise
  • Alfresco 3.1.1 Enterprise
  • Alfresco 3.2 Community
  • Alfresco 3.2 Enterprise
  • Alfresco 3.3 Community
  • Alfresco 3.3 Enterprise
  • Alfresco 3.4c Community
  • Alfresco 3.4 Enterprise

Packt Author of the Year Award

I mentioned it on Twitter yesterday but I definitely wanted to spend more than 140 characters saying thanks. If you missed the tweet, what I’m talking about is that Packt announced that I won the Author of the Year Award for the Alfresco Developer Guide.

Earlier this year they had a nomination process which resulted in readers choosing me as a finalist. Getting that far was really cool and I definitely want to say thanks to the readers of the book and the blog for making that happen.

The next step was a round of judging. This took a while and I can’t imagine the process whereby you get a panel of judges, with different backgrounds and full-time jobs (I assume) to look at six technical books that cover a wide range of topics (Alfresco, Drupal, Ext JS, JavaScript, and SOA) and subsequently make sense of the feedback. Definitely a big thanks to Packt and the panel of judges who worked hard to make this happen.

The book was certainly a team effort. I had a great team of technical reviewers, and they were instrumental. I think it’s also important to recognize my firm, Optaros, because the project couldn’t have happened without their support and encouragement. The entire Alfresco team also got behind it in one way or another and that was important to the success as well.

Alright, enough said. I’ll quit before I start working my way down the family tree. Maybe Twitter’s length restriction really is the best thing for an acceptance speech. Thanks, again, to everyone involved!

Alfresco Developer Guide source reorg and 3.2 Community update

[UPDATE: Added a link to the source code that works with 3.2 Enterprise]

I originally wrote the Alfresco Developer Guide source code for Alfresco 2.2 Enterprise and Alfresco 3 Labs. The code was pretty much the same regardless of which one you were running. For things that did happen to be different, I handled those with separate projects: one for community-specific stuff and one for enterprise-specific stuff. This was pretty much limited to minor web script differences for the “client extensions” projects and LDAP configuration differences for the “server extension” project.

With the release of 3.2 Community, I realized:

  • The number of different flavors of Alfresco any given reader might be running are going up, not down. Who knows when 2.2 Enterprise will be sunset.
  • It is no longer as easy as “Enterprise” versus “Labs/Community” because multiple releases of the same flavor are prevalent (2.2E, 3.0E, and 3.1E, for example).
  • Tagging my code in Subversion by Chapter alone is no longer enough–I need to tag by Chapter and by Alfresco version.
  • Sending the publisher the code one chapter at-a-time and expecting them to manage updates and deciding how to organize all of the chapter code was a bad idea.

So, I’ve done some work to make this better (reorg the projects, restructure the download files). I’ve also tested the example code from each chapter against the latest service packs for all releases since 2.2 Enterprise. That includes making some small updates to get the examples running on 3.2 Community.

You can now download either all of the source for every version I tested against, or, download the source that works for a specific version. It may take the official download site at Packt a while to get the new files, so here are links to download them from my site:

Alfresco Developer Guide example source code for…

  • Alfresco 2.2 Enterprise (~5.3 MB, Download)
  • Alfresco 3.0 Labs (~5.6 MB, Download)
  • Alfresco 3.0 Enterprise (~5.7 MB, Download)
  • Alfresco 3.1 Enterprise (~5.6 MB, Download)
  • Alfresco 3.2 Community (~5.7 MB, Download)
  • Alfresco 3.2 Enterprise (~5.9 MB, Download)
  • All of the above, combined (~28.1 MB, Download)

Hopefully this makes it easier for you to grab only what you need and makes it clear that each Eclipse project contains only what’s needed to work with that version of Alfresco. Deployment is easier too. Most of the time, it’s just the “someco-client-extensions” project that you deploy.

Now that I’ve got everything structured like I want it, as new versions of Alfresco are released, it should be much easier to keep up.

Keeping your Alfresco web scripts DRY

One of my teammates thoroughly drenched our under-the-desk development server with a giant cup of coffee once. Somehow, disaster was avoided, although the client’s carpet had a nice coffee-stain outline of the server’s footprint long after the app rolled out which afforded the rest of us endless opportunities to mercilessly haze the clumsy coder.

Keeping your Alfresco web scripts DRY is actually not about making your developers use spill-proof travel mugs, or better yet, virtual machines. DRY is a coding philosophy or principle that stands for Don’t Repeat Yourself. There are all kinds of resources available that go into more detail, and the principle is more broad than simply avoiding duplicate code, but that’s what I want to focus on here.

There are three techniques you should be using to avoid repeating yourself when writing web scripts: web script configuration, JavaScript libraries accessed via import, and FreeMarker macros accessed via import.

Web Script Configuration

Added in 3.0, a web script configuration file is an XML file that contains arbitrary settings for your web script. It’s accessible from both your controller and your view. Building on the hello world web script from the Alfresco Developer Guide, you could add a configuration script named “helloworld.get.config.xml” that contained:


<properties>
<title>Hello World</title>
</properties>

You could then access the “title” element from a JavaScript controller using the built-in E4X library:

var s = new XML(config.script);
logger.log(s.title);

And, you could also grab the title from the FreeMarker view:

<title>${config.script["properties"]["title"]}</title>

The web script configuration lets you separate your configuration from your controller logic. And because you can get to it from both the controller and the view, you don’t have to stick configuration info into your model.

This example showed a script-specific configuration, but global configuration is also possible. See the Alfresco Wiki Page on Web Scripts for more details.

JavaScript Import

If your web script controllers are written in JavaScript, at some point you will find yourself writing JavaScript functions that you’d like to share across multiple web scripts. A common example is logic that builds a query string, executes the query, and returns the results. You don’t want to repeat the code that does that across multiple controllers. That’s what the import statement is for.

The syntax is easy:

<import resource="classpath:alfresco/extension/scripts/status.js">

This needs to be the first line of your JavaScript controller file. This example shows a JavaScript library being imported from the classpath, but you can also import from the repository by name or by node reference. See the Alfresco JavaScript API Wiki Page for more details.

FreeMarker Import

Of the three this is the one I see ignored most often. Let’s take the Optaros-developed microblogging component for Share. Its basic data entity is called a “Status” object. So web scripts on the repository tier return JSON that might have a single Status object or a list of Status objects. That’s two different web scripts and two different views, but the difference between a list of objects and a single object is really just the list-related wrapper–in both cases, the individual Status object JSON is identical. I’ve seen people simply copy-and-paste the FreeMarker from the single-object template to the list template and then just wrap that with the list markup. That’s bad. If you ever change how a Status object is structured, you’ve got to change it in (at least) two places. (Or it’ll be someone that comes after you that has to do it which makes it even worse. If you aren’t following the analogy, your redundant code is the coffee stain).

Instead of duplicating the logic, use a FreeMarker import and define a macro that formats the object. Then you can call the macro any time you need your object formatted. Here’s how it works for Status.

A FreeMarker file called “status.lib.ftl” contains the macros that format Status objects. It lives with the rest of the web script files and looks like this:


<#assign datetimeformat="EEE, dd MMM yyyy HH:mm:ss zzz">
<#--
Renders a status node as a JSON object
-->
<#macro statusJSON status>
<#escape x as jsonUtils.encodeJSONString(x)>
{
"siteId" : "${status.properties["optStatus:siteId"]!''}",
"user" : "${status.properties["optStatus:user"]!''}",
"message" : "${status.properties["optStatus:message"]!''}",
"prefix" : "${status.properties["optStatus:prefix"]!''}",
"mood" : "${status.properties["optStatus:mood"]!''}",
"complete" : ${(status.properties["optStatus:complete"]!'false')?string},
"created" : "${status.properties["cm:created"]?string(datetimeformat)}",
"modified" : "${status.properties["cm:modified"]?string(datetimeformat)}"
}
</#escape>
</#macro>
<#--
Renders a status node as HTML
-->
<#macro statusHTML status>
SiteID: ${status.properties["optStatus:siteId"]!''}<br />
User: ${status.properties["optStatus:user"]!''}<br />
Message: ${status.properties["optStatus:message"]!''}<br />
Prefix: ${status.properties["optStatus:prefix"]!''}<br />
Mood: ${status.properties["optStatus:mood"]!''}<br />
Complete: ${(status.properties["optStatus:complete"]!'false')?string}<br />
Created: ${status.properties["cm:created"]?string(datetimeformat)}<br />
Modified: ${status.properties["cm:modified"]?string(datetimeformat)}<br />
</#macro>

There’s one macro for JSON and another for HTML. It still bothers me that the same basic structure is repeated, but at least they are both in the same file and it feels better knowing that this is the one and only place where the data structure for a Status object is defined.

The FreeMarker that returns Status objects as JSON resides in status.get.json.ftl and looks like this:

<#import "status.lib.ftl" as statusLib/>
{
"items" : [
<#list results as result>
<@statusLib.statusJSON status=result />
<#if result_has_next>,</#if>
</#list>
]
}

You can see the import statement followed by the JSON that sets up the list, and then the call to the FreeMarker macro to format each Status object in the list.

When someone posts a new Status, the new Status object is returned. Rather than repeat the JSON structure for a Status object, the status.post.json.ftl view simply calls the same macro that got called from the GET:

<#import "status.lib.ftl" as statusLib/>
{
"status" : <@statusLib.statusJSON status=result />
}

Now if the data structure for a Status object ever needs to change, it only has to be changed in one place.

Don’t Repeat Yourself

Take a look at your web scripts. Eliminate your duplicate code. And keep a lid on your mocha frappuccino.

Save 15% on Alfresco Developer Guide

Forgive this temporary transgression into a blatant sales pitch, but I’m trying to save you some money. Packt Publishing is offering ECM Architect readers 15% off my book, the Alfresco Developer Guide. To take advantage of the discount:

  1. Visit the Alfresco Developer Guide Book Page
  2. Click the “ADD TO CART” button to add the book to your shopping cart
  3. Enter AlfrescoDG-3117 in the “Promotional Code” field and click the “Update Button”. The discounted price should now be reflected in your order.

After your book arrives, if you read it and decide it was the best Packt book published in 2008, you should take a minute to vote for the Alfresco Developer Guide in Packt’s Author of the Year awards. Voting ends May 25.