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.
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.
Bryan Spaulding, Media Practice Lead at Optaros, and I have been thinking about lightweight digital asset management and Alfresco. Alfresco can manage any kind of asset, including rich media. It has some built-in functionality for doing image transformations and you can easily integrate with open source solutions like ffmpeg to work with video. But many of our clients need something more, especially when it comes to video.
That’s where Kaltura comes in. Kaltura is a fully hosted video solution that provides full analytics, flexible and customizable players and playlists, and robust back-end CDN and hosting services. You can also download the open source Kaltura Community Edition and run it yourself if you want.
There are a variety of ways Alfresco and Kaltura could work together. We decided to start with a basic integration focused on the Alfresco DM repository. The idea is to use that as a foundation, expanding in the future based on community and client feedback to include deeper functionality for the DM repository or broader integration with other Alfresco products like Alfresco Share and Alfresco WCM.
In this short screencast, I demo the basic CRUD functions the integration provides. You will probably want to hit the “full screen” icon on the Kaltura player to see the detail.
The integration is available as open source. You can download the integration from Kaltura’s community site and use it on your projects, or better yet, expand on it and contribute back the code. The readme that is included with the source includes installation and configuration instructions.
As I point out in the screencast, there’s not much to the integration from a technical standpoint. Open Atrium is Drupal and the CMIS module already has a CMIS repository browser. So, all we had to do was expose the module as a “feature”, which is something Open Atrium uses to bundle modules together that create a given chunk of functionality.
Readers familiar with Alfresco Share will instantly recognize the Open Atrium concepts. Instead of “sites” Atrium uses “groups”. Instead of “pages” or “tools”, Atrium uses “features”. The overall purpose, self-provisioned team-based collaboration, is the same and many of the tools/features are the same (blog, calendar, member directory). I’m not advocating using one over the other–as usual, what works best for you depends on a lot of factors. I just thought Atrium provided a nice way to show yet another example of Drupal and Alfresco together (post).
How comprehensive? This edition offers 239 new pages (including the index) over the original. That’s a lot of net new content. The first seven chapters are roughly the same as the first edition, covering fundamentals, installation, security, basic library services, rules, and the content model. The Collaboration and Syndication coverage has morphed into a chapter on Share & SharePoint which is very timely as there is a lot of activity around that area of the product right now.
The organization of the book feels improved over the first edition. It now follows a very logical progression through the entire platform. There are still places where the information feels superfluous (the discussion of ActiveDirectory versus Novell eDirectory, for example) or aimed at a different audience (Chapter 9’s coverage of integration with other systems) but overall I think Shariff and his team have done a great job of covering an expansive platform and its many use cases.
If you are evaluating Alfresco, just getting started with the platform, or you are looking for the missing manual for end-users and power users, you should take a look.
Disclosure: Packt provided me a copy of this book free of charge. Also, Munwar and his team of authors work for Cignex, a services firm that, from time-to-time, competes for business against my company, Optaros.
Peter Monks (Alfresco), Russ Danner (Rivet Logic), and I have been working on compiling course content for the “Alfresco Best Practices” Masters Class that will be given at the Alfresco Community Meet-Ups around the world this Fall. I’m a bit worried, though. If you’ll forgive the somewhat graphic mixed metaphor, the three of us have done this huge brain dump and now we’re stirring it together in the hopes that we can firehose the audience and have some of it stick. There’s just a lot of stuff to cover in very little time. (I’m sure between now and then we’ll get it to be less of a hose down. And, whatever we don’t get to in the session will be made available online for your reference).
Our plan for the talk is to cover the material in the same conceptual order that your implementation will go through. We’ll start by understanding the most common business use cases for Alfresco. Then we’ll talk about the pieces of Alfresco that you have to work with, and sort of line those up against the common use cases. From there, we’ll dive in to best practices for each of the pieces, roughly in order that you’d touch them (start with content modeling, move to writing code, then deployment, then keeping everything running). We’re going to share best practices on extensions, UI customizations, WCM, Surf, backup/restore procedures, and on and on.
Hopefully, regardless of where you are in your implementation, you’ll be able to come away with at least a handful of tips, tricks, or things to avoid that will make your project more successful.
Russ will deliver the material in Washington, D.C. and I’m taking Atlanta and L.A. I’ll also be in D.C. to steal ideas from Russ’ delivery that I can pass off as my own. Toni de la Fuente will be giving the talk in Madrid (and translating the deck into Spanish). I’m not sure who’s delivering the material at the other European events.
In any case, I’m looking forward to it. If you’ll be attending any of the North American meet-ups, be sure to say hi.
I know I’m way behind on this. I’m kind of surprised at how little attention it has received. Maybe I need to refresh my portal-based news feeds. In any case, earlier this Summer, JBoss and eXo announced they would be combining the JBoss Portlet Container with eXo Portal to create a new project called GateIn. Other than the similarity between the concepts “portal” and “gate” I’m not sure what they are going for with the name, but don’t let that throw you off. To get an idea of what it’s about, check out the demo.
Most of our clients looking for open source Java portals have been interested in either JBoss Portal or Liferay. In choosing between the two, one consideration was that, historically, JBoss Portal has been less about out-of-the-box portlets and flashy UI and more about providing a presentation framework. Clients developing solutions that were really 100% custom apps with a portal-like interface leaned toward JBoss Portal (especially if they were already a JBoss shop). Clients looking for more of an “instant community” with ease-of-use on the configuration side and a large number of out-of-the-box portlets leaned more toward Liferay. GateIn appears to be a big step forward for JBoss Portal in terms of the user experience for portal administration and makes JBoss Portal about more than just a framework for presentation services.
Beyond requiring a great user experience for both end users (site consumers) and portal administrators (content managers), portals must also have a fast and intuitive development model. I think this is especially true lately as lighter-weight presentation frameworks have become more popular. As the difference in capabilities between portal and non-portal presentation frameworks becomes less and less, portals can’t afford to offer a soul-sucking development experience.
I haven’t spent any time customizing GateIn so I can’t comment on the developer experience. What I do know is that when you move from developing code using lightweight frameworks like Drupal or Django to Java portal servers like Liferay, you feel the increased complexity immediately. Anti-Java-ites will say that a lot of the complexity in the development experience is there because it’s Java and it will always be that way. I don’t think that’s true–look at frameworks like Grails and Wicket.
The point is, for GateIn to be a serious challenger to Liferay, they’ll need to provide not only the eye candy on the front-end, but also a developer experience that approaches the productivity level we can get with non-portal frameworks. If they can do that, they have a chance against Liferay. Of course even if they manage to do that, they are still up against the “Do we really need a portal server to do this?” undercurrent that threatens both projects. But that’s another blog post.