Tag: Alfresco Share

Custom Data Lists in Alfresco Share Community 3.3

One of the new features of Alfresco 3.3 Community is Data Lists. The ability to create an arbitrary list within a team collaboration site is a feature so loved by SharePoint users, it is often cited as one of the things holding back a migration to Alfresco. I agree that it’s a useful feature and I’m glad to see it making its way into Alfresco Share. Let’s take a look at the new feature, then we’ll lift up the hood to see how it works so you can implement your own custom data lists.

Quick Review of Data Lists in Alfresco Share

First, take a look at this screencast. It shows the new Data List feature in action as well as the high-level steps needed to create your own custom Data Lists.

As you can see, Data Lists let you keep track of team information that lends itself to being managed by classic web form interactions and displayed in sortable columns. You can probably think of a lot of examples of things your team needs to track that don’t make sense in a blog or a document library or maybe need a little more structure than the wiki. The screencast showed To Do’s and Issues but it could really be anything.

In the Community 3.3 releases, Alfresco Share includes To Do Lists. It sounds like more Data List examples are coming in the 3.3g release. But if you want to add your own custom data list type, it’s really easy, especially if you’re familiar with Alfresco content models (tutorial). However, right now, this still requires XML editing. SharePoint allows lists to be defined on-the-fly, so while Alfresco’s roadmap does have this as something to address in the future, right now this is still a gap between the two products.

If you are interested in just the end-user functionality of Data Lists in Alfresco Share, this is where you should bail. If you want details on what’s going on behind the scenes, keep reading…

How Data Lists are Implemented

Data Lists are persisted as nodes in the repository. One node represents the list itself–it contains child nodes for each item in the list. The data values for each list item are stored as metadata on the node–sometimes we call these “content-less objects” because there is no file content associated with them. The nodes live in the DM repository just like data from the other tools in your Share site.

If you want to see this for yourself, go into the Explorer Client. In the Sites folder, there is a folder for Share site and within that, a folder for each site tool. Data List nodes reside in the one called dataLists. In the back of your mind you should be thinking that this means items in a Data List can trigger rules and be routed through workflows just like any other node. In fact, any API call that can work with a node can work with an entry in a Data List, including CMIS. (Shameless plug: “Heck, you could even create Data Lists with Python using cmislib!”)

You know from working with data models that each Alfresco data model has an XML file that describes it. If you go look at the out-of-the-box model directory you’ll see a new content model XML file called datalistModel.xml. If you take a look at that file, you’ll see that the node that represents the container of list items is an instance of dl:dataList which inherits from cm:folder.

The nodes that represent each item on the data list are instances of specific data list types. So, for example, the out-of-the-box To Do List has items that are of type dl:todoList. In my Issues example, Issue items are instances of scidl:issuesList. All data list item types must inherit from dl:dataListItem. For one thing, that’s how the Share user interface knows what to offer as an available data list type.

The form that’s displayed when you create and edit new Data List items is configured through the Alfresco Form Service. In my example I didn’t do anything fancy with the form, but you’ve got the full power of the new Alfresco Form Service behind you so you’re not limited to simply listing one field after another.

So, creating your own custom Data List types involves two steps:

  1. Define and deploy a custom content model for your new Data List type, making sure it inherits from dl:dataListItem.
  2. Configure the Alfresco Form Service in the Alfresco Share application to display the metadata from the custom Data List in the create and edit forms as well as in the browse grid.

In my example, I used an AMP to deploy the content model to the repository tier (my Alfresco WAR) and a JAR to deploy the form service configuration to the presentation tier (the Share WAR).

If you want to try this example in your own environment, you can download the Eclipse project here. It includes an Ant build file, the content model, and the form configuration. Note that I deployed the Forms Development Kit to both the Alfresco and Share WARs prior to deploying my Data List form configuration. The example assumes you’ve done the same. If you don’t want to fool with the FDK, that’s cool, it’s not required for data lists. You may want to look at the Forms Development Guide for tips.

Alfresco Share microblogging component released as open source

Back in February (I know, it’s been simmering on the back burner for too long), I did a couple of screencasts on Optaros Labs showing a demo of Alfresco Share (part 1, part 2). In part 2 of that screencast I showed two custom components: Status and Bookmark. Alfresco made Bookmark obsolete by releasing their own shared bookmarks module for Share, and that’s a Good Thing. I kind of expected them to release a microblog component as well, but they haven’t yet. Well, I finally got around to making ours available, so until a similar feature makes it into the product, feel free to use it in your own projects.

The component is simple: A “My Current Activity” dashlet lets you and your team give a quick blurb about what you’re working on. Another dashlet aggregates all of the status entries from your teammates. A global dashlet aggregates the entries from all Share sites. All status changes automatically show up in Alfresco’s Activity Feed as well.

My Current Activity Dashlet
My Current Activity Dashlet

Unlike Twitter, the status component lets you mark an entry as “done”. When you do that, your current status gets reset and the old entry moves to the archive. So it’s a little more task-oriented than more general purpose, free-form microblogging tools.

Deployment is pretty easy. An AMP gets deployed to your Alfresco WAR, and a ZIP gets unzipped into your Alfresco Share web application. That’s it. No configuration necessary. All of the data lives in the same structure as the other tools in your Share site.

I’ve put the code out on Google Code under a BSD license. There’s a pre-built AMP and a ZIP for download or you can checkout and build from source. There’s one Eclipse project for the repository tier and one for the Surf tier. I’ve tested this on Alfresco 3.2 Community. I’ll test it out on the Enterprise releases when I get a chance. There were some changes in the Activity Feed that I had to deal with and I’m not sure how far back those go so I may have to have version-specific releases.

Have a look and give me your feedback. If you want to dig in and make enhancements, bring ’em on.

Customizing Alfresco Share: Five things to watch out for

Alfresco Share is a team-centric collaboration tool. It’s really cool and our clients have been reacting very positively to it. When customers see the AJAXalicious UI, a common reaction is to want to take the next 5 projects on their list and “do them on Share”.

In cases where the functional requirements closely resemble team collaboration, that can be a great choice. In others, it’s an abuse of the tool. Just like a lot of things in software and life, just because you can doesn’t mean you should. (Remind me to tell you the story about building a tennis court reservation system in Lotus Notes some time).

Anyway, let’s assume you’ve got a set of requirements that reasonably resembles team-based collaboration, but some of Share’s tools (wiki, blog, document library, calendar, and recently, bookmarks) don’t work exactly the way you need them to. I’m not talking about adding new, self-contained custom components. This is specifically about customizing the out-of-the-box Share components. With that in mind, here are five areas where even simple Share customization efforts could take longer than you might think.

Custom Metadata

In its current incarnation, if you have custom metadata you want to display when looking at document detail, that’s code you have to write. Alfresco’s Mike Hatfield said, via Twitter, that the 3.2 Forms Service will make this better, so that’s good. If your Share sites contain simple documents that use only out-of-the-box metadata, this won’t be an issue for you.

Custom Workflows

Currently, in Share, there are a couple of places where the jBPM workflow engine is used. First, when you invite someone to a site, that kicks off a workflow. Second, you can “assign” an advanced workflow to a document in the document library.

The first issue is that the workflow submission dialog includes only the two out-of-the-box, document-centric workflows, “Ad hoc” and “Review and Approve”. It won’t show any custom workflows you’ve deployed. The workflow modal is not inspecting the workflow UI configuration like the web client does, so even if you got your workflows to show up in that list, the form wouldn’t have the custom workflow metadata you need to launch your custom workflow properly.

When you log in to Share, you’ll see a “My Tasks” dashlet. This gives you hope that maybe that dashlet could manage tasks for any workflow. Unfortunately, it only works with the “invite user” workflow and the two document-centric, OOTB workflows.

Long story short, Share isn’t set up to work with custom workflows out-of-the-box. If you’ve got custom workflows that need to work in the Share context, you’ll need to write your own dialogs for launching the workflow and your own component for managing workflow tasks.

YUI Bubbling Events

Share makes heavy use of YUI Bubbling Events. This results in a great end-user experience–the Share components communicate with each other and refresh themselves via AJAX without page refreshes. But it does mean there’s a bit of a learning curve when following the same pattern to implement your customizations if your team has never worked with the bubbling library before. It can get kind of thick in places.

Incidentally, all of the YUI stuff is part of Share, not Surf, which is the framework used to build Share. If you’re building your own Surf app you’ll need to grab the YUI libraries (or any other libraries you want to use) yourself. It’s the same for the Flash pieces (multi-document upload, document preview). It keeps Surf light, but if you want to incorporate that kind of functionality into your Surf app, some assembly will be required.

Code Sprawl

In Share, every module has as least one JavaScript file. For example, the Document Library has six different JavaScript files weighing in at about 136KB. Sometimes what should be a simple change (adding a button, creating a new modal) requires changes to every one of those files. This combined with grokking the bubbling events translates into potentially lengthy development cycles for stuff that you wish would be quick.

Theming

The main CSS file for Share is in the themes directory. But changing that will only affect the global dashboard header and the site dashboard header. If you want to change the theme for everything in Share, including individual tools, you have to change each tool’s CSS file. Those CSS files live in the “modules” directory. It would be nice if it were easier to implement site-wide or global themes.

Adding your own Components/Tools

The impact of these issues are lessened somewhat if you are adding your own components or tools instead of customizing what’s already there. It’s easy to write your own dashlets that show up on the global dashboard or the site dashboard. And with a little work, you can write dashlets that talk to each other using YUI Bubbling Events, just like the OOTB dashlets. The area for improvement is in skinning, configuring, and extending the out-of-the-box tools.

Share Your Thoughts on Share

There’s no doubt that Share is a cool application for team-based collaboration. I didn’t expect it to be configurable to the Nth degree right away, and we may be pushing the limits of its intended use. I’m curious to hear from others who have been tweaking the app: Have you worked through these issues? Are there other examples of specific extension points Alfresco could address to make your lives easier?