Category: Alfresco

Alfresco open source content management

Alfresco dynamic list constraints example

Jean Barmash has published an example showing how to do dynamic list constraints for Alfresco properties. His example accepts a Lucene query to populate the list but it can easily be extended to query anything you want.UPDATE (12/1/2009):The link to Jean’s example in my original post wasn’t a permalink. I’ve corrected that. To clarify:

  • Jean’s post on dynamically updating dependent dropdowns is here.
  • His original post on data-driven dropdowns is here.

Obviously, these two techniques can be combined.

Progress on the Alfresco book

Several readers have asked how the book I’m writing on Alfresco development is coming along. First of all, thanks for asking. It has been quite a project. The first draft of the entire book is now complete. What’s happening now is that a group of technical reviewers from Alfresco, Optaros, and Packt, the book’s publisher, are going through the chapters and providing comments. So far, I’ve been able to turn those around quickly but I anticipate an increasing volume of feedback as we move into the later, more technical, chapters.

I’m pretty excited about how it is coming together. If you like the tone and scope of the Alfresco Developer Series of tutorials you’re going to like the book. The book is full of hands-on examples so it should be really good for people that are new to the Alfresco platform.

It would be great if we could publish by the time the North American Community Conference happens in Washington D.C. on October 9th, but to be honest, I’m not exactly sure what the schedule looks like from here on out. I’ll give another update as we get closer to publication.

Open Source CMS Alfresco Releases 3.0 Preview

Alfresco has just announced the availability of the Alfresco Labs 3.0 Preview. If you’ve been regularly updating from HEAD there may not be a whole lot of stuff that’s new to you but if you haven’t, it might be a good time to see what the team in Maidenhead has been up to.

The first thing you’ll notice is that Alfresco has changed the name of their freely-available Community edition to “Labs”. Alfresco has always insisted that this edition is a developer build that really isn’t suitable for production use. The name change is an attempt to further drive that point home.

Surf’s Up

Alfresco Surf is essentially Alfresco’s name for the web script framework plus some pre-built components with a framework for defining and assembling pages. The web script framework (and therefore, Surf-based sites) can now be run separately from the Alfresco repository process. This has actually been possible since 2.9 Community but now Alfresco is starting to do something with it (See “Share the Love”). In fact, some of my Optaros teammates have been working hard for Alfresco (as a client) to develop some of the content-centric components that are part of Surf and one of the new clients, Share. So Surf is essentially a web application development framework built on REST, JavaScript, FreeMarker, and YUI that you could use to build your own web apps without ever touching an Alfresco repository if you really wanted to. Assuming you do want to pull content from the repository, Surf let’s you make remote calls from within Web Script controllers back to the Alfresco repository, or via AJAX using YUI components from the browser.

Share the Love

Alfresco is using Surf to build its new web client offerings. One such offering is called Share. If you’ve been following Alfresco’s progress you’ll probably recognize it by its code name, Slingshot. Share is a collaborative workspace that allows you to spawn “sites” that include things like a Document Library, Blog, Discussion Forum, Wiki, Team Calendar, and Activity Feeds. Activity Feeds are sort of like a Facebook News Feed, but instead of tracking who poked whom you are being alerted when someone updates a document, makes a new blog post, etc.. The Share client will be the core for Alfresco’s frontal assault on Microsoft Sharepoint.

Speaking of, Share implements the SharePoint protocol. What does that really mean? It means that if one of the things you liked about Microsoft SharePoint was how you could work with a SharePoint Shared Workspace from within Microsoft Office applications, you no longer have to settle for an all-Microsoft stack on the back-end. You can use an Alfresco server instead. That means your users can have the functionality they like when collaborating on Office apps, while the IT department gets to keep their options open from operating system to database to application server and doesn’t have to worry about scalability concerns inherent in SharePoint. Unlike prior Alfresco add-ons for Microsoft Office integration, this approach requires no additional installations on the client because Office already has the hooks for talking to SharePoint, and Alfresco Share implements the SharePoint protocol.

Jon Newton, Alfresco CTO, said in his blog post on the release, that we should expect another Labs update in September with an Enterprise release to follow some time in October.

Sneak peek: Optaros Ext-JS Web Client for Alfresco

As I mentioned in my “Assembling 2.0 Solutions with Alfresco” talk, Optaros has written a streamlined web client for Alfresco based entirely on REST (web scripts) and Ext JS. We’re calling it DoCASU, which stands for Document Access for Casual Users, and we’re making it freely-available as an open source project.

We haven’t made the official announcement of its availability yet, but so many people have asked me about it after seeing the presentation, I thought I’d spill the beans, at least for faithful ecmarchitect.com readers.

Read more about the project and download the AMP from code.optaros.com. If you see things that need fixing, create a bug report or fix it yourself and contribute it back. Have fun!

Slinging some ideas around RESTful content

Via Seth Gottlieb news that Apache Sling has been officially released. Sling is interesting–I’ve played with it only a bit. You can read more about it on Seth’s post but essentially it is a REST API that sits on top of Apache Jackrabbit. Jackrabbit is the reference implementation of the JCR spec.

I’m not crazy about the JCR API because it is Java-only (yes, I know there are bridges out there). Plus, it doesn’t seem to be rich enough for many types of implementations. For example, Alfresco is a JCR-compliant (Level One) repository, but you don’t see too many people doing JCR-only interactions with Alfresco.

What is interesting to me, though, is the idea that you can abstract repositories at a higher level: the REST API. If we’re all going to talk to our repositories via REST, why not do it in a standard way?

Alfresco introduced a REST framework in 2.1 called “web scripts” (learn more). But Alfresco does not yet have a full-blown “REST API”. Yes, there are a few out-of-the-box REST calls but for the most part, when you interact with Alfresco via REST you are going to roll your own API. On Optaros projects, this has not yet been a huge burden. Quite the opposite, in fact–we’ve been able to develop everything from web script-backed JSR-168 portlets to a streamlined version of the Alfresco web client (soon to be released as an open source project), all on web scripts.

As part of 3.0, Alfresco anticipates rolling out additional out-of-the-box URLs to more fully establish the REST API. The new 3.0 web clients are based almost entirely on REST so they might as well build a REST API that we can all use.

When I look at Apache Sling, I’m thinking, why don’t we agree on a standard REST API for working with content repositories. Then, we could write a front-end once and theoretically use it with multiple back-end repositories. If someone then wants to use a JCR-compliant repository behind the scenes, then that’s cool, but it isn’t a requirement.

Obviously, there is a granularity challenge here. If the API is too granular the front-end ends up making too many calls. If you are aggregating multiple calls from within an intermediate application and then returning the result to the front-end (rather than making a bunch of AJAX calls initiated from the browser client), that’s not as much of an issue. If the API is too coarse, it is too hard to reuse across many different types of front-end applications.

Still, if we agree that REST is the preferred interaction model in the “content as a service” world, at least for the moment, and further, that front-end developers tend to want to have the option of using non-Java technologies for the presentation layer, a standard REST API for interacting with content repositories makes sense, whether that’s Sling, whatever Alfresco comes up with, or the best of both.

Maybe the Atom Publishing Protocol is close to what I’m thinking here. Maybe Alfresco thinks so too. I noticed the Abdera JAR was added to the Alfresco Community dependencies fairly recently. Abdera is an Apache incubator project for working with Atom.

We actually have an engagement with Alfresco right now to develop some of the new 3.0 web client modules. When I get some time I’ll explore this idea a little further by checking in on the 3.0 web client team, looking at Abdera, and doing a deeper dive on sling.

Toughest ECM Job: VP of HR at Vignette?

Quick, name an Alfresco SE who did not come from Vignette. Okay, you can shout out any name you want–I don’t really know the answer. But it does seem like every week I’m meeting an Alfresco new-hire that just turned in his Vignette badge. Most companies have an “attrition” number they keep an eye on. Vignette must have a “left to go to Alfresco” metric that keeps those guys up at night.

Of course the market is relatively small and incestuous and everybody’s gotta have a former employer, but I know when someone leaves you always want to know where they are going and if it turns out to be a competitor, it puts a pit in your stomach.

I guess as the legacy commercial ECM vendors get taken down by Alfresco and, more generally, the open source movement, this kind of thing is going to happen and it will get even worse. It’s kind of like watching Animal Planet. You see the tiger stalking the gazelle, you know what’s coming and you know it is the “circle of life” and all of that, but when the claws inevitably sink into those fleshy hindquarters, you still have to feel something for the gazelle, even if only for a moment. At least until you realize that’s what the gazelle gets for not embracing open source.

Of course hiring a bunch of folks from the same company doesn’t always work out for the best. People tend to be loyal and they move in packs (don’t worry, no one’s getting eaten in this metaphor). For example, someone recently connected the dots for me with regard to the Alfresco WCM engineer departures. It turns out Kevin Cochrane, Britt Park, and Jon Cox all came over from Interwoven so the timing of their departures is not coincidental at all.

Thanks for attending the Open Source ECM event

I want to thank everyone for attending the Open Source ECM event in Dallas this morning. In case you missed it, the slides I presented on “Assembling Enterprise 2.0 Solutions with Alfresco” are available on share.acrobat.com (which is powered by Alfresco, BTW) here.

The deck covers a bit about the general components of Enterprise 2.0 solutions and how a repository like Alfresco can be central to that architecture because it is so open. I then give a brief intro to web scripts (recycled from the talk I gave at the user conference in San Jose earlier this year) and walk through Endeca and a few other client examples.

I’ve also got some Alfresco-Ringside thoughts in there that include screenshots on the Alfresco-Facebook demo app running on Ringside and a list of potential features that might be interesting to implement with an Alfresco-Ringside combination.

Finally, I’ve got some never-before seen screenshots of the yet-to-be-announced Optaros-built streamlined Alfresco web client which we will release as an open source project under the GPLv3 soon.

Kevin Cochrane leaving Alfresco

In his blog, John Newton announced yesterday that Kevin Cochrane is leaving Alfresco. This was a bit of a shocker. If you’ve ever been to any sort of community event sponsored by Alfresco, chances are you’ve heard Kevin speak. In fact, if you’ve been involved at all in strategic discussions with Alfresco about product direction, you can attest to the passion an enthusiasm Kevin exudes when discussing Alfresco. Excitement alone would make him just a Marketing guy (no offense, my Marketing friends!), but Kevin added to that a sharp sense of direction for where Alfresco was headed and what users were looking for. That combination is what made him a good product manager, not just for Alfresco WCM, but really the entire platform. As John mentions, the product really wouldn’t be where it is today without Kevin’s drive.

It always seemed odd to me that Kevin, with his strong Interwoven background, was driving both the WCM and DM side of the platform. It seemed like a lot of scope to bite off, particularly with the potentially diverse set of use cases each provides. I guess The Two Johns agreed–they’ve decided to backfill Kevin with two resources: Mike Farman for ECM and Michael “Uzi” Uzquiano for WCM. Uzi earned recognition of late with the creation of the “next generation” web site framework which ultimately was adopted into 3.0 and incorporated into the plans for the new 3.0 web client, so he’s got the technical chops.

It’ll be interesting to see what happens next. Kevin’s is the latest departure from the Alfresco WCM ranks. A month or so ago two senior WCM engineers, Jon Cox and Britt Park, left. There seemed to be a bit more proactive damage control being done when Jon and Britt left, but I’m not going to read anything into that.

Alfresco has a lot of momentum right now with key clients going live on both the DM and WCM side of the house, impressive subscription revenue growth, and a good team to fill the void left by Kevin and Co. Provided the 3.0 release doesn’t slip too terribly far behind, I don’t think these departures are going to derail them.

Fixed the Alfresco-Ringside File Upload Problem

I’ve been playing with Ringside‘s Social Application Server. In my initial post on the subject I mentioned I was having trouble with the file upload. I got that put to bed this evening. As it turns out, Facebook inserts some hidden fields into form tags (see doc) such as the Facebook user, API key, session key, and app ID. Ringside doesn’t insert those fields.

Why does this matter? When you post a multipart form (i.e., a file upload) in a Facebook app, you don’t post to the canvas URL, you post to the application directly, which in this case is an Alfresco web script. All other posts go through the canvas URL and by the time they arrive at the web script, the request has the parameters it needs to make Alfresco’s Facebook web script runtime happy. In Ringside, the file upload post lacks that context because the hidden fields are missing. Alfresco needs those hidden fields–without them, the script has no idea which Facebook app is posting the data.

The fix was easy enough. I just inserted the hidden fields into the form via the Freemarker template (adddocdialog.post.fbml.ftl). The “facebook” root object knows the user, API, and app ID because the form gets displayed as the result of a canvas post.

Here are the hidden fields I added to form in the Freemarker template:

<input type="hidden" name="fb_sig_user" value="${facebook.user}" /><input type="hidden" name="fb_sig_session_key" value="${facebook.sessionKey}" /><input type="hidden" name="fb_sig_api_key" value="${facebook.apiKey}" />

The only other change I made was to comment out the postUserAction call in adddoc.post.js. I’m not sure that’s supported yet in Ringside. If it is, there’s some other problem causing it to choke.

So, other than the user action post, the Alfresco Document Library Facebook app is fully-functional in Ringside.

The next step is deeper integration into the web client. I know Alfresco is moving toward more social networking features in the 3.x release, but integrating with Ringside via web scripts might be a way to get there faster with more functionality.