People often need to build a custom user interface on top of the Alfresco repository and I see a lot of people asking general questions about how to do it. There are lots of options to consider. Here are four options for creating a user interface on top of Alfresco, at a high level:
Option 1: Use your favorite programming language and/or framework to talk to Alfresco via REST or Web Services. PHP? Python? Java? Flex? Whatever, it’s up to you. The REST API is nice because if you can’t find a URL that does what you need it to out-of-the-box, you can always roll-your-own with the web script framework. This option offers the most flexibility and creative freedom, but of course you might end up building constructs or components that you may have gotten “for free” from a higher-level framework. Optaros‘ streamlined web client, DoCASU, built on Ext-JS, is one freely-available example of a custom UI on top of Alfresco but there are others.
Option 2: Use Alfresco’s Surf framework. Alfresco’s Surf framework is just that–it’s a framework. Don’t confuse it with Alfresco Share which is a team-centric collaboration client built on top of Surf. And, don’t assume that just because a piece of functionality is in Share it is available to you in the lower-level Surf framework. You may have to do some extra work to get some of the cool stuff in Share to work in your pure Surf app. Also realize that Surf is brand new and still maturing. You’ll be quickly disappointed if you hold it to the same standard as a more widely-used, well-established framework like Seam or Django. Surf is a good option for quick, Alfresco-centric solutions, especially if you think you might want to leverage Alfresco’s browser-based site assembly tool, Web Studio, at some point in the future. (See Do-it-yourself Alfresco Surf Code Camp).
Option 3: Customize the Alfresco “Explorer” web client. There are varying degrees to which you can customize the web client. On one end of the spectrum you’ve got Freemarker “presentation templates” followed closely by XML configuration. On the other end of the spectrum you’ve got more elaborate enhancements you can make using JavaServer Faces (JSF). Customizing the Alfresco Explorer web client should only be considered if you can keep your enhancements to an absolute minimum because:
- Alfresco is moving away from JSF in favor of Surf-based clients. The Explorer client will continue to be around, but I wouldn’t expect major efforts to be focused on that client going forward.
- JSF-based customizations of the web client can be time-consuming and potentially complex, particularly if you are new to JSF.
- For most solutions, you’ll get more customer satisfaction bang out of your coding buck by building a purpose-built, eye-catching, UI designed with your specific use cases in mind than you will by starting with the general-purpose web client and extending from there.
Option 4: Use a portal, community, or WCM platform. This includes PHP-based projects like Drupal (Drupal CMIS Screencast) or Joomla as well as Java-based projects like Liferay and JBoss Portal. This is a good option if you have requirements that match up well with the built-in (or easily added-on) capabilities of those platforms.
It’s worth talking about Java portal servers specifically. I think people are struggling a bit to find The Best Way to integrate Alfresco with a portal. Of course there probably is no single approach that will fit every situation but I think Alfresco (with help from the community) could do more to provide best practices.
Here are the options you have when integrating with a portal:
Portal Option 1: Configure Alfresco to be the replacement JSR-170 repository for the portal. This option seems like more trouble than it is worth. If all you need is what you can get out of JSR-170, you might as well use the already-integrated Jackrabbit repository that most open source portals ship with these days unless you have good reasons not to. I’m open to having my mind changed on this one, but it seems like if you want to use Alfresco and a portal, you’ve got bigger plans that are probably going to require custom portlets anyway.
Portal Option 2: Run Alfresco and the portal in the same JVM (post). This is NOT recommended if you need to scale beyond a small departmental solution and, really, I think with the de-coupling of the web script engine we should consider this one deprecated at this point.
Portal Option 3: Run the Alfresco web script engine and the portal in the same JVM. Like the previous option, this gives you the ability to write web scripts that are wrapped in a portlet but it cuts down on the size of the web app significantly and it frees up your portal to scale independently of the Alfresco repository tier. It’s a fast development cycle once you get it set up. But I haven’t seen great instructions for setting it up yet. Alfresco should document this on their wiki if they are going to support this pattern.
Portal Option 4: Write your own portlets that make services calls. This is the “cleanest” approach because it treats Alfresco like any other back-end you might want to integrate with from the portal. You write custom portlets and have them talk to Alfresco via REST or SOAP. You’ll have to decide how you want to handle authentication with Alfresco.
What about CMIS?
CMIS fits under the “Option 1: Use your favorite programming language” and “Portal Option 4: Write your own portlets” categories. You can make CMIS calls to Alfresco using both REST and SOAP from your own custom code, portlet or otherwise. The nice thing about CMIS is that you can use it to abstract the underlying repository so that (in theory) your front-end code will work with different CMIS-compliant back-ends. Just realize that CMIS isn’t a fully-ratified standard yet and although a CMIS implementation is in the Enterprise version of Alfresco, it isn’t clear to me whether or not you’d be supported if you had a problem. (The last response I saw on this specific question was a Peter Monks tweet saying, “I don’t think so”).
The CMIS standard should be approved by the end-of-the-year and if Alfresco’s past performance is an indicator of the future, they’ll be the first to market with a production-ready, fully-supported CMIS implementation based on the final spec.
Pick your poison
Those are the options as I see them. Each one has trade-offs. Some may become more or less attractive over time as languages, frameworks, and the state of the art evolve. Ultimately, you’re going to have to evaluate which one fits your situation the best. You may have a hard time making a decision, but you have to admit that having to choose from several options is a nice problem to have.
This is an interesting article. We are in the middle of a discussion on what front-end to use on our new Alfresco environment. Some of the options mentioned we have already considered, others we hadn’t.
Thanks!
Great article! I have been reading documentation and watching webinars to answer this exact question.
Jan Pfitzner pointed out that I did not mention “Customize Share” as an option. We are actually doing a significant Share customization project right now so I’ll follow up with some specific lessons-learned in a future post. For now, just realize that Share is not nearly as configurable as the Explorer client. Yes, you can add new Dashlets to the Global Dashboard or the Site Dashboard, but if you want to modify how the out-of-the-box “tools” work–to add custom metadata to the document library details, for example, or to submit your own custom workflows rather than the OOTB workflows–you may end up having to modify Share code.
The other general tip is similar to the “when to customize the web client” tip, which is: Remember that Share was built for team/project collaboration and if your solution varies significantly from that, consider dropping down to the Surf framework rather than modifying Share.
Have you ever checked Jibe ? It is similar to Docasu but I think it has much more flexibility and is more Java oriented, with the frontend in ExtJS.
http://jibeframework.org/
Daniel,
Thanks so much for pointing me to Jibe. I’ve checked out the screencasts and I have to say it looks awesome.
DoCASU is really supposed to be a streamlined web client–just the barebones functionality for people that simply need to get content into and out of the repository.
Jibe looks like a full web client replacement. I haven’t looked at your code yet, but it seems like you are trying to be a full UI framework on top of Alfresco. If it is as configurable as your wiki seems to indicate, it would be more flexible than DoCASU in that respect.
I’m looking forward to learning more.
Jeff
You are right.
Actually it is not “yet” a full replacement but we are working on rules and permissions.
I am surprised you did not checked Jibe yet, however I can confirm that it is highly configurable and extendable. The thing is that Jibe only has a webscript that acts similar to DWR, and from there it is working directly with Java and therefore the Alfresco Foundation API. I think it is a big advantage over the other Alfresco UI “frameworks”.
Would you have any question I will be glad to answer them 😉
I saw in one of the screencasts a “Task Browsing” tab. Is that for workflow task management? I would think workflow and permissions would be two critical pieces to get in. Rules to a lesser extent, but from the screencasts it looks like you’re already pretty close there.
I’m going to take a deeper look and I’ll let you know if I’ve got other questions.
Thanks again.
Jeff
There are some workflow application that we have built on top of Jibe, but at this moment we do not provide a workflow module for the “default” Alfresco workflows.
Daniel,
I poked around on your framework and it is clearly not ready for mere mortals like me. I got the base RepoModule working fine. The trouble was trying to follow your “first component” example. I left you a post in your forum with some of the problems I had.
Maybe at some point in the future I’ll get a chance to keep hacking at it, but for now I’m on to other things.
Jeff
Thanks for the high level overview. It pretty much sums up the conclusions we’ve reached after weeks of investigating.
We have a requirement for a fairly simple Intranet – allow users to manage a few documents and some of the web content on the site. Collaboration is not required just yet but there is a very good likelihood it will be required in the near future.
Share provides most of the components we require bar rules which are needed for some simple workflows. The approach we are leaning towards is using Share as the platform but providing our own customised templates and re-using as many of the OOTB webscripts we can.
Adminstration tasks can still be administered through the Explorer interface. There is no requirement for users to be empowered to the hilt. All required rules etc will be predefined. Thus it is simply a case of executing them via RESTful services.
Given that we’re fairly new to the Alfresco products, are there any obscure pit falls that need to be avoided in taking such an approach?
PS – Thanks for all your blogs, tutorials and book. The Alfresco documentation is not as complete as we’d like it so every web resource has been gold.
As usual, excelent article …
What about creating sites on Alfresco Share and develop dashlets for especific functionallity ? I think it’s a nice approach . It’s not like option 2, and you can use the Share UI.
Yes, customizing Share is an option. I consider that to be Option 2, but I agree that when you start with Share it is different than writing a Surf app from scratch because your components already have pages where they can live.
I do caution people, though, not to abuse the tool. It would be easy to take Share and make so many customizations to it you’ve taken it down a far different path than it was originally intended. What you have then is effectively your own fork of Share that may be difficult to maintain going forward.
We’ve done some significant Share customizations and there some things to watch out for. If you are going the Share route, you might want to read this summary:
https://ecmarchitect.com/archives/2009/04/22/976
I Jeff, as you teach there are many method to integrate Alfresco web client into Liferay portal framework, but in fact the most natural (Alfresco as a 168 portlet) is not usable at all!!
I’m using Liferay Portal 5.1.2 and Alfresco ECM 3.2r2 deployed as portlets, using Tomcat 5.5.26.
Tomcat, Liferay and Alfresco starts up ok, no errors. 6 Alfresco portlets are deployed onto liferay (registered successfully).
But there is a big problem: You can’t add/upload content in Alfresco’s folders.
You can add the Alfresco client portlet to a portal page, but when you try to ‘add a content’ – you get the error:
([org.alfresco.web.ui.common.Utils] A system error happened during the operation: null
java.lang.NullPointerException
at org.alfresco.repo.content.filestore.FileContentReader.(FileContentReader.java:123))
This is a problem since a long time, also using previous Alfresco version.
Please, could you help on this?
Thank you in advance!
Ivano
Ivano,
I haven’t looked at that particular style of integration in a long time. Honestly, I would avoid it if possible. Running Alfresco and Liferay in the same JVM is not the best idea. Alfresco’s direction with portal integration is to use Spring Web Scripts from within a portlet to make remote calls to the Alfresco repository.
You might have better luck in the forums.
Jeff
Dude, I think this guy ripped off your article: http://www.optaros.com/blogs/alfresco-user-interface-what-are-my-options
You are quite right. Except I worked for Optaros at the time I wrote the post, so technically I guess it wasn’t ripped off but borrowed. While I worked there it was common for me to write something on this blog and then re-post it on the Optaros blog. What’s weird is since I did work for Optaros at the time, we would have put my name on it. I’m not sure why Marc’s name is on it. I hope that person asking questions isn’t hoping for an answer. Marc’s a Marketing guy who doesn’t even work for Optaros any more!
Sorry for the confusion it may have caused.
Jeff
No worries man! I just want to make sure credit is given where credit is due.
Either way, I’m intrigued as to your opinion on the topics of customizing Alfresco interfaces. We have a client that wants a knowledge management solution as well as a CMS. Alfresco solutions seems like a perfect fit. However, being an agency the interface that Alfresco gives you OOTB needs some work. I’m curious as to your opinion on using the Javascript API: http://wiki.alfresco.com/wiki/3.4_JavaScript_API and then building an AJAX type interface that simply makes calls into Alfresco via such methods. I also saw your post here: https://ecmarchitect.com/archives/2010/09/07/1212 which frankly deterred me some more 🙂 Any thoughts?
Tyrus,
I’m realizing I never answered your follow-up question about using the JavaScript API on top of Alfresco. The Alfresco Share interface uses the approach you’ve outlined. It takes YUI and wraps it with its own set of client-side JavaScript objects (documented here for Community 4.0b). Those client-side objects are talking to the repository tier via web scripts. The web script controllers are written in server-side JavaScript (mostly, some are Java) and those use the JavaScript API you’ve referenced.
Share wasn’t built on YUI alone. It also needed a framework for doing page layout and for making remote calls back to the repo tier. For that, Share relies on Spring Surf which also happens to use web scripts. But instead of returning data from the repo tier, they return markup on the presentation tier.
So, if your use case is very close to Alfresco Share’s, you could start with Alfresco Share and have your AJAX-y interface ready to customize. If it isn’t close to your use case or requires too much customization to get the UI close to what you need, start with a custom app using the framework of your choice and hit the repo tier using web scripts. You might try to use the out-of-the-box repo tier web scripts as much as possible to try to reduce your coding and maintenance burden. You can always knock out custom repo-tier web scripts when the out-of-the-box web scripts don’t meet your needs.
Jeff
Hi Jeff.
I am new to alfresco share.I am currently using alfresco community Edition 4.0d.
I am learn lot of things from your tutorials.
I want to search the user by their job title and location what should i do for that?
Rutaveej,
Take a look at this YouTube vid: http://www.youtube.com/watch?v=23iayijlB0A&feature=share&list=PLOEM5PcngNJXCP2MDOSdGFJXkBnxwH6-3
It shows how to update your profile and how to do searches for people based on their profile metadata.
Jeff
Hi Jeff,
I found this article interesting, however things have changed and personally i’d like to see an updated version of this article on the options we have right now? Particularly with ADF.