What it is
Spring Surf is probably best known for its use within Alfresco Share. Surf provides a skeleton around Spring Webscripts which are effectively bundles of convention driven MVC functionality made to work within Alfresco. Surf is largely notable for its very verbose XML based view definitions where the various components are customizable in multiple locations. Additionally Surf creates a rich model which represents the assorted objects which play a role in the View and can be used while rendering for some view specific logic.
My Hopes
I adopted Spring Surf for a project because we use Alfresco and I was looking for a replacement solution that would keep stakeholders from desiring that some stale legacy code was carried forward. The verbosity of Surf seemed to promise higher levels of flexibility, and combined with Alfresco that could allow for a greater amount of runtime control and publishing of a wide range of View updates through Alfresco Web forms. The splitting off of Surf into a Spring project was promising as it indicated that Alfresco was interested in creating a richer ecosystem of libraries that were less coupled to their architecture.
DevCon
I recently went to Alfresco DevCon 2012 primarily to get a feel for the future direction of the project so that any of my work would not diverge too strongly (particularly since most documentation is still focused on version 3 while 4 appeared to be a major shift). Alfresco is understandably focused on enhancing its role as an ECM which co-exists with other solutions and in particular becoming the cloud compatible ECM. Solutions which are not directly concerned with document management are increasingly being handled outside of Alfresco using CMIS and entirely different technologies (like Drupal).
My Realities(not necessarily anyone else's)
The biggest single hurdle in working with Surf was the lack of documentation. Although it had been split off, the Spring pages were seemingly given no attention and there was effectively no information about using the framework in non-Alfresco contexts. After DevCon it became painfully clear that this is due to Surf not being useful outside of Alfresco, particularly Alfresco Share.
Being focused on being an ECM Alfresco is in the role of allowing their solutions to be able to be worked with, but it is not their role to develop external solutions. The splitting of Share into a more distinct client application was necessary to become more Cloud-y. I can only suppose that shifting Webscripts and Surf to the Spring umbrella was done in the hopes that they would gain traction outside of Alfresco (which they haven't). Alfresco provides a powerful platform for the repository and for the Share client, but on the client side the result is that you must be on top of the platform to reap the benefits. The idea of further modularization into a library or loosely coupled framework is not on their horizon.
Surf is too cumbersome to compete with other similar solutions. There is virtually no tooling to help with the creation of Surf files. The one possible exception is the now seemingly abandoned Spring Roo plugin, which from my eyes is on the wrong end of the development tools: a possible benefit of having the view defined using Surf's approach would be to transfer greater power to a non-engineer (non Roo user).
The imagined flexibility didn't pan out as the model of the View is created entirely at start-up. This makes sense and there are ways to work around it, but ultimately it does not provide any out of the box flexibility beyond any other view composition approaches.
Webscripts still have promise (and are used effectively in another department at my office), but unless they are communicating with Alfresco they could also be replaced by a far simpler and lighter solution.
Ultimately Spring Surf only makes sense as Alfresco Surf and used in Alfresco Share. The entire structure makes perfect sense when viewed through the lens of a larger platform which allows for a consistent programming model when dealing with repository nodes and a View which represents the interface to that repository. Outside of that context, however, the complexity it introduces provides no benefit over slight modifications of far, far simpler alternatives.
If you are building a solution that should sensibly be tied to the Alfresco platform, then using Surf to customize Share and optionally working with an Alfresco partner makes a lot of sense. If you're looking for a more general purpose solution and may have even thought something like Spring == a solution that can help for a variety of problems: keep looking.
Being focused on being an ECM Alfresco is in the role of allowing their solutions to be able to be worked with, but it is not their role to develop external solutions. The splitting of Share into a more distinct client application was necessary to become more Cloud-y. I can only suppose that shifting Webscripts and Surf to the Spring umbrella was done in the hopes that they would gain traction outside of Alfresco (which they haven't). Alfresco provides a powerful platform for the repository and for the Share client, but on the client side the result is that you must be on top of the platform to reap the benefits. The idea of further modularization into a library or loosely coupled framework is not on their horizon.
Surf is too cumbersome to compete with other similar solutions. There is virtually no tooling to help with the creation of Surf files. The one possible exception is the now seemingly abandoned Spring Roo plugin, which from my eyes is on the wrong end of the development tools: a possible benefit of having the view defined using Surf's approach would be to transfer greater power to a non-engineer (non Roo user).
The imagined flexibility didn't pan out as the model of the View is created entirely at start-up. This makes sense and there are ways to work around it, but ultimately it does not provide any out of the box flexibility beyond any other view composition approaches.
Webscripts still have promise (and are used effectively in another department at my office), but unless they are communicating with Alfresco they could also be replaced by a far simpler and lighter solution.
Ultimately Spring Surf only makes sense as Alfresco Surf and used in Alfresco Share. The entire structure makes perfect sense when viewed through the lens of a larger platform which allows for a consistent programming model when dealing with repository nodes and a View which represents the interface to that repository. Outside of that context, however, the complexity it introduces provides no benefit over slight modifications of far, far simpler alternatives.
If you are building a solution that should sensibly be tied to the Alfresco platform, then using Surf to customize Share and optionally working with an Alfresco partner makes a lot of sense. If you're looking for a more general purpose solution and may have even thought something like Spring == a solution that can help for a variety of problems: keep looking.
No comments :
Post a Comment