Flex and Alfresco on The Flex Show
I’m on The Flex Show this week, talking a bit about Flex/Alfresco integration. Jeff and John were great, and I think I managed to get some useful information across in spite of the fact that I was recovering from the flu when we recorded it (back in December). There are a couple of items that need improving/correcting, but listen to the show first, then come back here for the clarifications.
OK, here we go. For one thing, I have learned since doing the show that in addition to Alfresco, there are other open-source Enterprise Content Management Systems (ECM’s) out there. (When we did the show I knew about projects like Drupal and Joomla, which are great, but they are Web CMS, not enterprise systems.) In any case, Alfresco is the one embedded in LCDS, so it’s going to be the one that has the most potential to impact us as Flex developers.
Another thing I realized in listening to the recording is that I did not do a very good job of describing the Flex/Alfresco implementation that we did for the large hospitality corporation. The application is really a lot cooler than I made it sound. On the Alfresco side, the repository has models and custom content types that map to the corporation’s specific needs. On the Flex side, VOs map directly to these custom content types. The UI presents these as custom item renderers/item editors, with each renderer/editor being specific to a content type. The screens then group these custom renderers/editors based on business logic, not content type. For example, if the user does a search on “Pets”, the application will respond by displaying a list of content items that relate to pets, regardless of the content type of the individual items. It was a bit of a challenge to display renderers/editors for all of these disparate content types in a consistent and user-friendly way, but I think we succeeded.
The application also had alerts to prompt users to appropriate action. For example, many content types had specified periods of time that they were considered to be valid, after which they became “stale”. This period of time varies between content types, and can be configured in the administrative interface. On the Flex side, items that are soon to become stale are highlighted so as to draw the users’ attention to them.
But perhaps the best thing about the application is how it allows different groups of users to interact with the content as a team. For example, the groups that are responsible for entering the content are dispersed around the globe, whereas the groups responsible for reviewing and approving the content are located in the corporate offices. These reviewers/approvers do not have rights to edit the content; they merely review it, and if it needs modification, they return it to the responsible party with notes as to what needs revising. They can also assign tasks to the entities responsible for entering and updating the content.
I could go on with this, but hopefully you are getting the idea that there are a lot of things that you can do when you have an ECM on the backend and Flex on the client.





Reader Comments
Jim,
It was great to have you on; although I’m still mortified I mangled your name in the beginning. I added a link to this blog post in the show notes of the episode.
It is always tough “in the moment” to figure out how things are going to come across after the fact. I don’t think John or I have it down yet either.
Jeff,
Please don’t give the name thing another thought. I’m not being polite when I say it happens all the time - it really does, even with people who (like you) have known me for years. And thanks for the encouragement! I think you and John are doing a great job with the show.
Jim, do you have a way to make flex handle a richer set of HTTP status codes in a portable way? Without that, I’m hesitant to recommend it for REST deployments.
@Matt,
Your question merited a new post, so I wrote one: http://www.robsondesign.com/blog/index.php/2009/04/16/flex-flash-and-http-status-codes/