When Alfresco first told me about the Surf framework and the plan to build a new then unnamed collaborative client on top of Surf I liked the sound of it. Of course anything other than JavaServer Faces sounded pretty good at the time.
But things didn’t quite turn out the way I thought they would.
See, what I thought would happen was that Alfresco would release a bunch of “mini” clients–highly-specialized apps for the task at hand. Want RM? Here’s the RM client. Doing some team stuff? Here’s Share. Basic Document Management, here’s the DM client. Web Content Management. Digital Asset Management. You get the point. With all of these sitting on top of Surf, each client app would only have the code that made it unique for that particular use case. It’s like taking one Ritz cracker (Surf) and then having a veritable smorgasbord of delicious ECM toppings to choose from.
Instead, what’s happened is that Alfresco launched their first Surf-based client, Share, for team collaboration, and then, rather than go back to the platter for another cracker, they kept piling on and piling on until that once dainty hors d’oeuvre became a towering Dagwood sandwich.
Let’s face it: Clients love the Share interface. They love it so much they want all of their content-centric apps to be based on it. If the client wants basic customizations–some form tweaks, a new dialog here, a new page there–it isn’t so bad. But the more complex the changes are, the more cruft you have to sift through and either eliminate or work around. A quick perusal through the Share code will turn up tidbits that deal with Records Management, SharePoint, and Google Docs. All of these are optional add-ons to Alfresco, but have worked their way into the Share client “just in case” someone installs that extension.
Okay, so if Share has too much to serve as an agile base in some cases, why not drop down to the underlying Surf framework? Because sometimes, Surf can be too bare bones. Recently, I did an implementation for a client that was essentially a community solution. We used two customized versions of Share: One for the “admin” interface for the community and the other for the front-facing community itself. Share worked great for the admin interface–not much tweaking was needed there at all. The dashboard, document library, wiki, discussion, and data lists functionality all made sense in the context of administering content. The front-facing community, however, was another story. We didn’t need 80% of what was in Share out-of-the-box. But we didn’t drop down to Surf because we wanted blogs, discussions, and some of the Share-tier web scripts for data lists and whatnot. We knew gathering up all of the dependencies needed to “push down” those features into Surf would be a pain. The solution turned out great, but the ratio of used to unused code is kind of scary.
Alfresco seems too far down the every-new-feature-we-come-up-with-goes-into-Share path at this point. But I wonder if the concept of a “distribution” could apply to Share. This would mean stripping down Share to some sort of bare bones minimum, just slightly bulkier than raw Surf. Then, provide AMPs or Maven builds or scripts or something that developers can use to “build up” Share with only the functionality they need.
Or maybe the solution is to make things that are optional, truly optional. It would be nice, if, through a script or this “tear down, then build up” approach, you could completely remove things like:
- Sharepoint integration
- Google Docs integration
- Records Management
- Wiki
- Blogs
- Discussion
- Links
- Anything else that’s not about the document library, data lists, categories, tags, and search.
By “completely remove” I don’t mean “hide from the user”. I mean when I recursively grep the Share web app for “Sharepoint” (for example) I get zero hits.
The goal here is to cut way down on the amount of code developers have to sift through, override, and extend when starting with Share as a base. And, once deployed, reduce the amount of code that has to be maintained and upgraded going forward.
Maybe Alfresco should take a lesson from Drupal. Some would argue that the core of Drupal is already too big, but at least the majority of extensions are in (truly) optional modules. And there are a number of Drupal distributions that take core and bundle different sets of modules for specific use cases. Django has something similar with the pinax project.
What do you think? Am I just being a picky eater? Is it realistic to think that Alfresco can whittle Share down to a more suitable base for the rest of us to build on?
I can only 100% agree!
Despite their stance that it’s modular (just because they plug beans together with Spring?), Alfresco has always been building a monolithic thing (maybe subsystems make it a bit more modular, I admit I haven’t looked at it much, as I haven’t had to really develop with any 3.x version).
It’s a product, in no way a platform.
Even embedding only the repository is hard; not to mention removing check-out/in, or versionning, or etc. even though they’re just plugged on top of the repo.
SURF is a good thing (well, it’s far too verbose, with far too many files dispatched in far too many directories), but as you say, it’s not enough.
Before they put it on a diet they need to _complete_ it. No advanced search in 3.3 was a killer on not using Share for a client.
Alfresco (generally) and Share (specifically) are at The Tipping Point. They are gaining a lot of excitement and adoption. But, the product is still too difficult to customize IMHO.
Hopefully the diet will also include getting the documentation in shape.
I agree as well. I’ve looked into Alfresco with a means to deploying a collaborative intranet with content surfacing on a corporate internet.
Share does seem to be a very large product. It is time-consuming to configure properly (i.e. exactly aligned with business requirements) and I must say that I would not be comfortable working on a solution that another developer had created which (in all hosesty, everyone) will probably not be very well documented.
The notion of different files different types of places does not sit well with me at the best of times – and wonder what version 4.x is going to look like.
I do like (love, even) the WebScript framework where I can very easily surface content from the repository but the way Share is put together worries me – not as a technical hurdle to cross, but the additional cost (development days) to customers in building solutions.
Jeff,
Great blog. I’m currently involved in a large Share customisation project for a client and the issue of the modularisation (or lack of it) in Share has certainly come up. I’m thinking particularly of things like the User Profile page this must get customised by such a high percentage of Enterprise customers I’m slightly surprised there’s not a higher degree of plug-ability available, especially as Alfresco is so great at the micro level at coding to interface and really walking-the-walk on Spring DI.
I wonder if there’s some scope for utilising Surf to implement a sort of macro-DI – perhaps a set of webscripts could somehow define the interface for, say, a blogging capability, which is connected to an implementation of a particular blogging capability, with the core Share web application handling null implementations appropriately. The same approach could be used for more non-functional or aspect-like requirements. This would, however, cost in terms of simplicity (Alfresco already has quite a lot of indirection and framework wiring) performance and wouldn’t deliver the sort of truly options plug-ins you’re talking about in your blog.
I guess one problem with the ground-up type plugin approach is the challenge of taking X functional plugins, Y aspect or NFR plugins and ensuring that each would function well with the other.
I agree that Share is way to complicated. The plan was to build a lightweight, easy to customize platform, but the result is quite the opposite.
With Javascript on Alfresco Repository, Share and the client side, HTML generated by Freemarker templates, the form service or YUI, it has become much more difficult to understand whats going on.
The missing code completion and documentation doesn’t help, either. Its try and error all the way, even so much that I miss the olden days of static Java code.
Maybe they should hire a Rails guy, since they obviously suck at frontend frameworks. Just saying…
I guess I agree with a bit of every statement above:
• Alfresco aims to be as generic as possible
• It hasn’t completed changing the interface to share and you can’t manage the product properly without it, although you can’t manage it effectivelly without it either
• New areas being addressed, such as interoperability, are critical
• Customer installation evolution is not being compromised – easy content migration to new versions, architecture design is kept clear and clean
• Product customization structure is being improved
• Documentation is improving as well
• Very easy installation and lots of features out of the box
Additionally I see a product with a strong basis on document management, making it’s way to intranets and web sites
The balance is that developpers suffer a little more, and customers pay a little more (in development hours), but in return they get a contious process with no disruption
I can tell you that I am doing projects with some of the other top 4 ECM technologies and in all respects addressed above – including for the brand’s consultants – comparing to Alfresco, it’s a nightmare; On a cost standpoint, Alfresco’s problems are not really significant
Hello Jeff,
I am sending you this comment because i didn’t find the private message section 🙂
I have done some Alfresco customization, and now i have encountered some pretty Sci-Fi Requests that i don’t know how to implement.
The requests are:
1. custom group rights: let’s say i add some new content types. i want to specify which content types are visible to each group. this way when a user from group A adds a new document he will see in the content type dropdown only the group A document types. weird.. i know
2. i wish to make customizable dropdown lists at the edit-metadata page so that the administrator can add or delete dropdown options. or read the dropdown options from a table in the database.
If you have any idea how to solve any of these problems or at least you know how to point me in a right direction please send me an e-mail.
Thank you so much,
Irina
Irina,
1. This isn’t available out-of-the-box. You’ll have to do it through a customization. Go look at the documentlibrary web scripts on the Share side and you should be able to find where that “Create Content” menu gets built. You’ll have to do some extensions of both the Share-tier web scripts and client-side Share JavaScript to make it happen.
2. This is also a customization. The approach to take is creating a Lucene-based and/or a SQL-based custom constraint. Then, in your content model, add the constraint to the property. That should automatically create the dropdown for you in both Explorer and Share. Alternatively, you could write a custom control that fetched the options from a service and the service could do the lookup. But adding the constraint to the model is the “right” way to do it. Jean Barmash wrote a blog post on dynamic data driven constraints a couple of years ago that may be helpful to you.
Good luck!
Jeff
Hello Jeff,
Thank you so much for the tips! 🙂
I started the research on the second issue because it appears to be more documented.
Have a nice week-end!
Irina