Ten things to love (or hate) about Bricolage. Part II.

Cross-posted from the New Internationalist Tech blog.

Okay, here we go — because you’ve all been so anxious for it — the second part of the infamous "Ten things to love (or hate) about Bricolage."

In this week’s post I’ll focus on the things that, as a Bricolage implementer (which I’ll refer to here as a "developer," not to be confused with a Bricolage hacker), you might love (or hate) about Bricolage, the open-source enterprise-class content management system (CMS) that is used at New Internationalist.

• Love: The integrated development environment. Bricolage is the only Web publishing tool that I’ve worked with that ships with a multi-user "integrated development environment." When working on template assets in Bricolage (akin to "theme" or "skin" assets in other content-management systems), each developer has their own workspace and, more importantly, development sandbox. Check out a template and it’s locked from editing by others — cool. Even cooler? Edit that template, preview a content asset, and see the template changes reflected (while others previewing the asset still see the last "deployed" version of the template). This makes day-to-day site tweaks a breeze, and doesn’t require a separate development server or, often problematic, "syncing."
  
  Hate: The integrated development environment. This one feature of Bricolage is so exceptionally useful, that I wish the concept was present in every other content-management system. Movable Type, Open Melody, and so on — take notice.

• Love: Virtual FTP interface. As if the integrated development environment for templates wasn’t enough, Bricolage goes on to offer "virtual FTP" access to those templates. That’s right: just fire up your FTP client and you’re interacting with that template IDE as if it were files in a filesystem. Only, when you make an edit to a template, the template is instantly moved into your workspace and sandbox. Save that edit and you can preview the content asset with the template changes. Best part yet: add a .deploy to the end of the template file name and the template is instantly deployed for use by live content assets on the site. Genius.
  
  Hate: Virtual FTP interface. The only gripe I have here is that this feature isn’t implemented for all of Bricolage’s assets. As someone who’s inclined toward development tools over Web-based user interfaces, I’d love to be able to edit content and media assets via the virtual FTP interface also.

• Love: Elements & sub-elements. The core of Bricolage’s ewwy-chewy-goodness as a publishing platform for large organizations is its flexible approach to describing assets and creating interfaces that enable humans to create those (potentially complex) assets. Unlike the common "Title," "Teaser," "Text," approach provided by most content-management systems, Bricolage enables endless possibilities for entering well-structured data. This flexibility is something that other CMSs are only starting to incorporate, e.g., Content Construction Kit in Drupal, Archetypes in Plone (which, incidentally, was inspired by Bricolage’s approach to forms and views).
  
  Hate: Elements & sub-elements. Historically, the step-by-step process of adding groups of elements (called sub-elements) was, frankly, a pain-in-the-ass. Now, thanks to some recent, AJAX-powered, UI improvements, this has become more palatable. However, the lack of sub-element "sets" for common input element groupings — e.g., street address, contact information, and so on — and the lack of field-validation or input-masking options still leaves room for improvement.

• Love: Powerful, well-documented, API. As if the above wasn’t enough to make a developer smile, Bricolage just doesn’t let up. Its thorough and comparatively well-documented API is (most days) a pleasure to work with. And, like all good Perl software, the documentation comes with the application. No Web access, no problem.
  
  Hate: Lousy API browser. Mediocre documentation. The one downside is — probably because I’m so used to software that doesn’t come with the documentation — that my first instinct is to visit the API browser online. To date, that’s been a mediocre experience due to some less-than-perfect browser support in the output of Pod::Site. Good news is that David has been busy improving Pod::Site and the API browser (sneak peak here). Other gripe: though the developer documentation is fairly good, the general documentation — for administrators, for content editors, and so on — is somewhat lacking. (Actually, the in-application "help" is pretty good, but needs to be ported to a Web-friendly format.)

• Love: SOAP interface. Last but not least is the uber-powerful SOAP interface. Bricolage’s SOAP interface provides a standardized way to access most assets programmatically. Content and media assets, element types, templates, and managing workflow, can all be accessed and managed via SOAP. This comes in pretty handy when importing content from legacy systems, automating parts of the publishing process, and syncing data between Bricolage instances (should you want to).
  
  Hate: SOAP interface. Well, what can I say, it’s SOAP. It’s huge, verbose, slow, and — at times — very annoying. But, until there’s an XML-RPC interface or similar, it gets the job done.

That’s it for today’s developer-centric look at things to love (or hate) about Bricolage. Hope you enjoyed. (And, as mentioned previously, these gripes are mostly a big, fat, "note to self.")

Got a beef or big-up for Bricolage? The comments are open. (And maybe, just maybe, I might have another five things to love (or hate) in store for you.)

Cross-posted from the New Internationalist Tech blog.