Latest posts by MindTheGab (see all)
- Introducing the Symphony Foundation & Community Blog - August 7, 2016
- Building our Community bottom up. Thanks for a great Member Meeting! - May 28, 2016
- The Symphony Software Foundation is Growing – Join the Community! - May 16, 2016
I guess the title may sound a little odd, but actually leaving the coldest Dutch winter in ages (peaks around -20° degrees and nice snowy lanscapes especially in the Southern Holland) I was kinda hopeful that Munich could bring some joy to this Italian emigrant. But no joy for the foolish: already during landing I was announced a -12° not-so-warm welcome by the city where the Alfresco SURF Code Camp (held by Optaros) was held today.Luckily today, also thanks to the nice venue in a snowy park, but especially due to the presence of his Alfresco majesty Jeff Potts as main speaker, I could really get a feeling of what Alfresco SURF & SHARE are built upon, how they can be used and exploited to create rich user experiences based on emerging(ed) technologies like JSON, Atom and CMIS.
Exciting new perspectives in terms of architectural distribution and ease of UI development can open using SURF and the ReST approach as opposed to the old monolithic JSF Web client (now called Repository Explorer) customization.
And that was basically all what this very interesting Munich SURF Bootcamp was about.
Jeff Potts and the Optaros guys, which have supported Alfresco in the development of certain components of SHARE, organized this free one day workshop (same as in Chicago) covering both architectural and pretty technical aspects around this new way of developing frontends against an Alfresco repo with interesting walktroughs down to the code (nice idea here and fast working to deliver with pre-built VirtualBox/VMWare virtual machines).
What follows is a high level skecth of discussions and findings of the workshop while find my personal considerations at the bottom of the post (many thanks and all credits to Optaros and Jeff Potts for the pictures you find below):
- A glance on SURF architecture: An introduction was given by Jeff to make the audience familiar with Webscripts/ReST/SURF architectural concepts, baseline to understand and continue the walktroughs and the labs. As per the picture below (gratefully taken from the Bootcamp presentations), SURF finally enable a two-tiered architecture almost as natural evolution of the Webscripts micro-MVC framework already available in 2.x. Some historical notes can help those not familiar with the latest Alfresco 3.0 developments and releases, to be able to understand the trend of UI development on top of Alfresco:
- 2.9-3.0a labs : Alfresco integrates Apache Abdera and start to support the Atom and AtomPub protocol with most of the 3.0 remote services based on the Atom protocol, composing a (still growing) full ReSTful API.
- 3.0b and Enterprise: Alfresco releases the first draft implementation of the CMIS interoperability standard, on the same day the joint draft proposal is announced simultaneously by Microsoft, IBM and EMC. Obviously, lots of buzz arose around it.
- 3.x: Alfresco releases the so-called SURF platform, a completely remotable component based web framework, that, exploiting the ReST repository API, provide means for multiple remote user interfaces around Alfresco. An advanced collaboration oriented front-end based on SURF is delivered from Alfresco in its 3.x releases, under the name of SHARE.
The big difference then is, while with Alfresco 2.x you were asked to build your remoting ReST API, Alfresco 3.0 with SURF and SHARE, should give you already enough power to build a component framework based frontend without worrying of “transport” details.
On top of that, as of Alfresco 3.0 labs and as of Alfresco 3.2 enterprise, a Web Studio (integrated with WCM) is delivered to support WYSIWYG development of SURF based websites. Pretty cool indeed, more details later in the post.
- Alfresco SURF remoting APIs: But how actually Alfresco can achieve such a great level of remote capabilities? What’s the API that performs the black magic under the hood? To those questions were dedicated the second presentation and walktrough in which we learned some of the ReST and JSON remote APIs of Alfresco. And, to be honest, this is really “the topic” to master on top of Alfresco 3.0 as it seems to be so well designed that can enable very easy and modular mash-ups with existing Web 2.0 SaaS and with 3rd party systems, as it acts as the transport layer for the whole architecture.
As per the picture, in fact, Alfresco SURF bases it’s connectivity to Alfresco repository and to 3rd party XML-JSON based services on the concept of endpoint, which can be talked to in its specific dialect by the means of a connector, and authenticated against (and SURF/Alfresco users mapped to its specific users) using an authenticator.
This, simple but powerful, separation of concerns allow us to connect Alfresco SURF based applications by default already to Alfresco repository, Mediawiki and WordPress, but it’s quite simple to think about other services to be integrated (del.icio.us or Linkedin being my first two guesses) directly from your frontend.
By the way nice to know that both Alfresco Repo and SURF frontends provide proxy services in order to overcome Ajax cross domain scripting restrictions. Well thought indeed.
- Page composition and dispatching howto: The core part of the bootcamp was infact dedicated to a great insight on the complex but powerful and flexible page composition and page dispatching framework. I say complex because many concepts (so XML conf files) has to be mastered, but I say powerful and flexible because it’s well designed and its complexity should be soon made opaque but a seamless use of the 3.0 Web Studio.
Quite easy to say, any component based web framework requires these two main subsystems to be bullet proof and fast, and that’s mostly here that you get your users happy vs. bored of yet-another-complex-web-framework. Let’s then have a look at how Alfresco approached it, shall we? 🙂
As per the picture below, to compose a SURF page we need to define the following so-called model objects in the WEB-INF/classes/alfresco/site-data/* folder:
- One or more pages or page-types (class of pages) which will be matched by the dispatching framework. Basically pages define navigation of your website in a graph fashion (using page associations). The navigation component for example looks at page associations to create a breadcrumb.
- One or more template-types and associated templates. A page uses a specific template which defines (using a simple Freemarker notation) regions, which are placeholders that will be bound to the ouput of a specific component. Regions have scopes (page, template, global) which allow (will see how) to bind the same component to different pages implicitly and reduce the number of component bindings needed.
- One or more components with a specific renderer which is capable of “actually delivering some output”: examples of renderers are ftl, jsp, Java Bean and the most widely used webscript which basically defines a webscript based component.
- Zero or more webscripts to actually perform the business logic of that specific component
- Zero or more page associations (actually a page to page typed link) and content associations (tell the dispacthing framework which page is bound to be rendered when a specifically repository object is addressed, i.e. very useful for detail and landing pages)
Once defined templates and defined some pages to those, the last step is to actually bind components to regions, and in this Alfresco chose to use the typical Convention Over Configuration approach based on the file name. To be clear, you will be required to create (in the ) a bunch of XML files with the proper name following this pattern:
where scope matches the scope of the regionId defined in a template, and sourceId is the id of the specific page in case of scope=page or of a specific template in case of scope=template. This way you can start filling in your regions with actual components that are references in the XML file content. Interesting enough to know, you don’t need to restart the webapp upon changes, so it’s a good point towards fastening Alfresco customizations development.
The last thing to understand is actually how you can reference your pages from a URL. This happens by the means of the dispactching framework which can be triggered by a URL using the 3 following patterns:
- Direct: A specific Page is requested (e.g. /alfwf/page?p=home). The page is choosen if available and rendered.
- Page type: A certain page type (e.g. /alfwf/page?pt=login) is requested, than the dispacther will choose page for the specific theme. Yes, that’s it, the only use I could understand for page types is to have theme-based pages (e.g. login for extranet and intranet)
- Landing detail page: An Object from the repo is directly referenced, so the dispatcher looks at a specific content-association, which will instruct it to serve the proper page associated for that content detail.
Lots of concepts but also lots of power. The final consideration we got to during the presentation is that it’s important to understand the trade-off point in your frontend requirements to justify the usage of such a complex but flexible framework. Needless to say though that for many repetitive contexts this can result in a great reuse and easy development, especially if we keep the Web Studio striclty under radar.
- Web Studio: Jeff gave us some insights on the web studio capabilities but actually not really more than what’s out there in the Wiki, forums or that we’re able to see in Alfresco 3.0d. Still a lot to go, but the possibility of previewing a WCM SURF based website in the Studio inline editing mode, well, seems pretty much closing the circle of web development on an ECM platform, capable of hosting your components, version them, offering you sandboxing and preview features, while being completely integrated with you Enterprise content. More more to see here.
- SURF labs: after a typical Munich sausage based lunch, we digged into a some nice SURF webapp building which resulted in the Alfresco Green Energy website up and running with SURF on my laptop. Pretty cool and fast development, will post more about it.
- CMIS developments and closing discussion: After a fast CMIS playaround (actually it will be nice to use CMIS to provide cross repository browseability using the interoperable ATOM standard) in which we started to build a CMIS repo browser for SURF, the discussion became much more of a debate on common issues and a share your pain session which was also attended (via Jeff Potts’ MacOs’ Skype) by some Alfresco representatives. Typical issues which were shared, discussed in depth and in certain cases addressed to Alfresco were:
- Alfresco SURF and Repository Caching and Performance tuning
- Alfresco Software Modules / Dependencies Management ( I was really into the topic considering my struggles for Alfresco having a Maven POM file)
- What’s your opinion about SURF? Are you going to use it for Web Frontends?
- What’s your SURF alternative? (Flex and ExtJS as biggest competitors
In the end it was really an inspiring day, in which I finally could get in touch with the world of developments these Alfresco guys deliver almost on a daily basis and my conclusive opinion is that, despite of some immaturity issues and some still proof-of-concept quality level features, SURF and it’s sample SHARE are great tool that open up great opportunities on top of Alfresco, and that should be carefully evaluated as first, standard, natural option for building websites and collaboration intra/extranets on top of Alfresco.
To a later post, for understanding a bit more of SHARE/SURF can coexist with existing Enterprise portal infrastructure (e.g. Liferay) and with more standard/typical frontend application frameworks.