Month: December 2008

Alfresco Developer Guide readers react positively

Thanks so much to everyone who has commented on the blog, sent an email, mentioned the book in a blog post, or written a review on my book, Alfresco Developer Guide. I’m glad you’re finding it helpful. Keep that feedback coming. While I’m thinking about it, here are some links related to the book you might find helpful:

  • A free chapter can be downloaded from the Alfresco Content Community. You’ll need an Alfresco Content Community login (it’s free).
  • One of my Optaros colleagues, Olivier Pépin, and I, originally wrote a chapter on Optaros’ open source alternative web client, DoCASU, but we had to make it a download for space reasons. You can download the “bonus chapter” from Optaros (email address required).
  • Appendix C talks about installing Alfresco, AMPs, import/export, and Surf. This was originally intended to be included in the book as well, but it’s been provided as a download instead.

Alfresco 3.0 Surf Code Camp Boston Wrapped Up

We hosted a good crowd of folks at Optaros headquarters in Boston today for our second Code Camp around Alfresco 3.0 Surf. Alfresco’s own Dr. Yong Qu was on hand to provide an early gift to campers–a live demo of Alfresco’s browser-based site designer tool, Web Studio. It looked like it was coming along nicely. The new tool is in Labs head but I haven’t had a chance to take a look so it was great that Yong was able to show us how it worked.

Yong showed a quick demo in which he stepped through a site creation wizard. Behind the scenes, Web Studio was creating a new web project in the Alfresco WCM store and configuring a user sandbox. Once the site was created, Yong put the site in edit mode. It makes more sense when you see it but what happens is a tray opens up that contains various lists of templates, components, and assets that can be dragged-and-dropped onto regions on the site’s pages. Once put in place, the component can be configured. Again, behind the scenes, Web Studio is creating the Surf model objects in the Alfresco WCM store (Code Campers become painfully aware of the variety and number of model objects required to build a Surf site because they do it by hand all day in the labs).

It’ll be a while (multiple months?) before Web Studio makes it into Enterprise. Until then, try it out. And while you’re in there, look at the library of components. Alfresco is hoping you will be inspired to create and submit additional components that can be similarly shared with the community.

The next Optaros-led Alfresco 3.0 Surf Code Camp will be in Munich on January 13th. I’ll be there as well as some of my other Optaros teammates, Alfresco will be there, and we’re hoping you will be there too. Read more details on the Munich event and sign up here.

Catching up on XForms, XRX, XProc, and Orbeon

I recently spent a little time looking at open source components we could assemble to provide a basic web form authoring solution embedded within one of our SaaS offerings. Rather than full-blown Web Content Management, all that the solution really called for was the ability for non-technical users to enter data in a form and to upload binary objects which may be related in some way to that form data. There could be several forms with some chunks of forms being reused, and at some point, it might be nice for non-technical people to create their own forms.

For the forms piece I immediately thought of XForms because (1) I knew we wanted the data stored as XML and (2) I like the MVC pattern that XForms follows.

It had been a while since I played with XForms directly. Alfresco’s web forms engine is currently based on the Chiba implementation of XForms, but you don’t normally get exposed to the XForms details. There are a few things going on in the world of XForms that caught my attention:

XProc. XProc is a W3C specification for an XML Pipeline Language. If you’ve ever worked with Apache Cocoon you’ll get this concept immediately as Cocoon was an early implementor of the XML pipeline approach. Think of raw XML going in a pipeline on one end, having it processed with one or more steps as it goes through the pipeline, and then possibly new XML emerging from the other end. Those processing steps can be thought of as modules that can be reused and recombined in different ways to build new pipelines.

One of our past clients was doing something similar to this with their own home grown solution. They were taking XML data feeds from sporting events, and then performing various operations on that XML before it was eventually posted on the web site in the form of scoreboards and stats pages. They called the process definition a “workflow” and it was described in XML. XProc would be ideal for something like that.

XRX. XRX stands for XForms/REST/XQuery. It is not a standard–it’s an approach for building web applications. It means using XForms on the front-end to present and capture data, REST between the front-end and the back-end, and XQuery to retrieve and transform XML from the back-end. This approach allows you to build a web application without any object-relational mapping. The data you are dealing with is always XML so there is no translation necessary.

eXist. eXist is an open source, native XML database. If you’re dealing exclusively in XML, why go to the trouble of translating your XML into rows and columns (and then back in to XML when it is retrieved)? Native XML databases do a better job of storing XML with no translation required while preserving your ability to efficiently do things like XQuery and XPath statements across the entire scope of your dataset. I had previously played with Apache Xindice but Xindice doesn’t support XQuery which is a major focus for eXist (plus, things seem a little quiet over at the Xindice project).

Orbeon Forms is a server-side XForms implementation. If you’re looking for an open source forms solution, you need to take a look. Orbeon is XForms, XProc, and eXist, all rolled into a single offering. You can merge the Orbeon WAR file with your web app’s WAR or you can deploy Orbeon in its own web app and simply tell it to handle all of the XForms tasks. Orbeon also has a graphical forms builder but I didn’t get a chance to play with that.

Thinking I might want to use Apache Sling/Jackrabbit as my repository, I decided to see how easy it would be to persist the XForms data into Jackrabbit instead of eXist, as Orbeon’s tutorial does by default. As I suspected, it turned out to be a 2 minute task. Because Sling provides a REST API into Jackrabbit, and because XForms can persist data via REST natively, it was simply a matter of changing the post URL from the eXist REST URL to the Sling REST URL and it was a done deal. Deciding whether or not Jackrabbit (instead of or in combination with eXist) is the right way to go is a decision for another day.

I’ll provide an update at some point down the road after we’ve done some implementation work on this embedded forms stuff and we’ll see how it actually held up.

I’m Sorry I’ve Neglected You, Server-side JavaScript Debugger

What can I say, Server-side JavaScript Debugger? You’ve been there all along, willing to help if only you were asked, and I was too set in my ways to pay you any attention. I don’t know, maybe it was all of those Java-backed web scripts that I was hooked on. But when I needed you, I just updated log4j.properties and you came through, no questions asked:

log4j.logger.org.alfresco.repo.web.scripts.AlfrescoRhinoScriptDebugger=on

Some will say that your Swing UI is a little hard on the eyes. Ignore them. Let them print logger.log messages all day while you and I step back and forth through code with reckless abandon!