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.

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.

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.

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!

Jean Barmash has started giving the Alfresco SDK distribution some attention. If you’ve worked with it lately you know it is a worthwhile cause. He’s looking for help so if you have feedback on ways to make the SDK a bit easier to work with or if you’ve got samples you think ought to be included, read his post and then join the discussion.

I don’t normally cover release announcements unless they are significant. Today Alfresco announced the release of 2.2 SP2. This one is noteworthy because it includes “key enhancements” to Alfresco WCM. Alfresco is encouraging WCM users to stay on the 2.2 code line rather than upgrade to 3.0 because these enhancements are not yet merged into 3.0. Alfresco says they will be part of the 3.1 release which will likely be some time in February.People running on the DM side of the house can upgrade to whichever release makes sense. Obviously, Alfresco hopes that is 3.0. Many clients deploy solutions that span both DM and WCM. My hunch is that waiting for 3.1 will make the most sense in those cases. 

It pains me to say it, but I’ve left Ubuntu as my primary OS and switched to Mac. I used Ubuntu as my primary operating system on my Dell laptop for over two years. I loved it. I felt very productive in the OS, especially relative to Windows. Many people have commented on how excited I must be (”Dude, you’re getting a Mac!”) but for me it kind of feels like it did when we moved out of the house our kids were born in–I know we moved for the right reasons, but the old place was special to me.

 

So why the switch? With Ubuntu there were a few annoyances. The major ones included:

 

  • Palm Treo synchronization. Worked in Gutsy once then started working fine after upgrading to Hardy Heron so this one wasn’t ultimately a factor.
  • OpenOffice.org incompatibilities with Microsoft Office. At Optaros we’ve tuned most of our standard documents to work with both. Just to make sure I always sent a PDF version of documents and presentations along with the original.
  • Broken wireless with the upgrade to Hardy Heron. Worked great in Gutsy. Completely broke in Hardy. The problem is a bug in Network Manager related to the Intel wireless device in Dell laptops. I learned to live without wireless.
  • Unreliable display detection. This is correctable with edits to xorg.conf, but when my machine couldn’t detect the projector settings, it was usually 10 minutes before a pitch which is a bad time to be fooling with that file.
  • Inability to host a Webex. I worked around this one by dual booting, running a virtual machine image, or using an alternate machine. Co-workers running Gentoo don’t seem to have a problem with Webex so I’m not sure what was going on here.
  • Gnome instability. Every once-in-a-while, I’d hear my hard drive start swapping and then–boom–all of the “file menu” frames around all of my active windows, and all of my Java processes would simply go away. There was no way to recover without restarting X (ctrl+alt+backspace). Gnome is probably not an accurate description of where the problem was here.

Could I have fixed these issues? Given enough time, probably. But I’d rather spend my time elsewhere rather than fooling around with stuff that ought to “just work”.

 

I realized that what made my development so productive on Ubuntu was:

 

  • Being able to install software quickly and easily through apt-get
  • Working with the same command-line tools I enjoy working with on Linux and Unix servers
  • Building and running open source technology on its “target” platform
  • Having complete control over what is installed and running at any given time
  • Enjoying increased stability and performance (gnome issue aside) compared to Windows
  • Never having to worry about procuring a license
  • Finding helpful community and online resources for self-support

Ultimately it was my former colleague and friend, Tom Pierce, a fellow Linux lover and Mac user, who convinced me that with a Mac I could keep the productivity of Linux while gaining the benefit of a consumer-oriented machine–Mac users don’t have to settle for broken wireless or worry that an archaic projector will derail a client presentation. (To be fair, neither do Linux users with the time and inclination to work through the issues).

 

So I bit the bullet and switched. At least on my primary work machine. My wife and kids still run Ubuntu on their desktop, my son runs Debian on his laptop, and our DVR is a Windows Media Center PC that talks to an XBox 360. (My home IT environment is now every bit as heterogeneous as Optaros’). Tom says my MacBook Pro is essentially a gateway drug and that my house will be all-Apple in no time. I hope he’s wrong. I don’t want to be a fan boy. Variety is the spice of life. My Treo is looking a little long in the tooth, though. I’ll bet an iPhone would be a nice complement to this machine…

 

We’ve just announced a new Code Camp date and city. We’ll be doing a Code Camp on Alfresco Surf in Boston on December 16th (Code Camp Details). Our New York City event filled quickly so if you want to attend you should sign up now. Hope to see you there.

BTW, the Code Camp in Munich looks like it will be some time during the week of January 12th. Obviously it will be posted here, at Optaros.com, and at Alfresco.com when it finalizes.

What a great group of campers we had today at the Alfresco 3.0 Surf Camp in New York City. We were all quite impressed with how much the attendees were able to get accomplished.

It’s clear that experience with web scripts sets one up for success with Surf. Surf is a two-tier framework. The repository tier is exposed to the presentation or Surf tier through web scripts running on the repository. So, obviously experience writing repository tier web scripts is directly applicable. On the presentation tier, it is still MVC and web scripts, but Surf adds page definition and templating constructs. The biggest challenge for people already familiar with web scripts, then, is to learn the presentation tier lingo and to sort out the numerous XML files, what they do, where they go, etc.

The best way to learn Surf seems to be to start with a simple Share dashlet then work up to building a complete web site. The dashlet gives you a chance to practice with the Surf JavaScript API and to make remote calls to the Alfresco repository (or other HTTP end points). Once you get the hang of that, try to build a simple one page web site that maybe queries some data from the repository and formats the results. Then, broaden from there.

Anyway, thanks to everyone that attended or helped put this together.

I suppose it is inevitable that an author opens his book for the first time and immediately sees a problem. An obvious typo perhaps. Or maybe a sentence or topic that could have been made more clear. For me it was a little more jarring. Picture this scene: Wife and kids gathered around a box. Everybody doing a fake drumroll. Box opens, book opens, and…hey, wait a second. Where the hell is the acknowledgements page? You know, the one that thanks my wife and kids for putting up with me. Nowhere, that’s where! Maybe in some unorthodox location? Flip to the back. Nope. Nada.

So, if you own a copy of the book and it is missing the acknowledgements, consider it a collector’s item. Hopefully, Packt will fix this problem before too many more get shipped. To the reader it isn’t an issue, but to me it is a big deal because it is important to express my appreciation to the large group of folks that made this project come together. It certainly wasn’t a solo effort. So, until this gets fixed, here is the elusive acknowledgements section.

Acknowledgements

This book would not have been possible without Optaros. What an awesome place to work and what a stellar team to work with. Thanks to Bob Gett, Mavis Chin, and Marc Osofsky for providing an incredible level of senior leadership support. Dave Gynn, John Eckman, and Seth Gottlieb (we miss you, Seth!) also provided early inspiration and counsel. Noreen Vincent helped with marketing and promo. Optaros colleagues from around the world rolled up their sleeves and dug in with code and technical editing: Olivier Pépin, Brian Doyal, Xavier Naud, Jens Scheutter, Alan Fehr, and Michael Ruflin all gave incredible amounts of thorough and thoughtful feedback. The book is significantly better than it would have been because of your involvement.

Alfresco has been tremendously supportive of and excited about this project. Thanks to John Powell, John Newton, Matt Asay, Dr. Ian Howells, Paul Holmes-Higgin, Luis Sala, Phil Robinson, Michael Uzquiano, and Nancy Garrity for providing information and support and for building such a cool platform. Alfresco team members also pitched in with technical reviews: David Caruana, James Urquhart, Jean Barmash, and Peter Monks spent time reading chapters and providing feedback when they probably should have been cranking out 3.0 code.

David Barnes at Packt Publishing deserves thanks for suggesting the project and getting it on track. Rajashree Hamine and Nikhil Bangera have done a great job holding me to task and handling everything on the Packt side.

My ecmarchitect.com readers deserve a big thanks. Your helpful feedback and encouragement motivated me to keep posting. I look forward to continuing the conversation.

Finally, to Christy, Justin, and Caroline: Thank you for putting up with the late nights and lost weekends, providing so much encouragement, and being so understanding.