Arjé Cahn posted a short video demonstrating the Hippo CMS 7’s new content type editor. The process is all GUI driven and looks very slick. It is difficult to know whether this is as flexible as the old Hippo CMS 6 system of editing layout and xsd files but it certainly appears easier. It is also nice to see that Hippo CMS 7 maintains the ability to control the layout of the entry form. Most CMS products only let you control the widgets used, their order, and, in some cases, what tab they appear on. Hippo gives the developer control over the layout of the whole form.
Related posts:
- Bluenog subtly forks Hippo I was catching up on my blog reading and noticed...
- Hippo Launches Hippo CMS 7.0 It’s official. Version 7, a near-total rewrite of Hippo CMS,...
- One Hippo When I wrote the Hippo CMS evaluation for Open Source...
- Apache Software License, Hippo, and BlueNog When I first got interested in open source software there...
- CMS Architecture: Managing Content Type Configurations Warning: this post is highly technical. Non-programmers, please avert your...
Since you’re such a defender of Plone’s “content type definition by code” model, I didn’t think you would be so impressed with this.
Thanks for the comment Deane. You did get me thinking… If I remember correctly, the Hippo CMS 7 content type definitions are stored in the repository (rather than the file system). This can pose a problem when it comes to configuration management. I have been working on development standards (configuration management, continuous integration, automation) with a client whose CMS stores presentation templates, content type definitions, and other configuration in a JCR. Configuration management for this kind of stuff was much harder than other applications we were working on. Developers needed a mechanism to work on local (source controlled) files and push them to their development environment. Automated scripts pushed those files to various server environments. CMS that do everything in the UI and store configurations in the repository usually need some kind of import/export mechanism.
Quite right that you need some sort of import/export mechanism. And yes, we’ve got this covered in CMS7. The import has been around for some time now and has a bootstrap mechanism that you can use to get all document types, configuration and content back into a ‘virgin’ repository setup. Storing all configuration, types, etcetera in the repository has this advantage that you can “load” all state back and can actually export all configuration because it’s just data in the repository.
Until the latest development version you still had to export all pieces of configuration, content, and data types separately and remember and record where they should go. Within the latest development version there is a beta version, dubbed “project export” that lets you export everything relevant to your project in a single go. It’s
still with some limitations, but we’ll improve these things soon enough.
I think it’s never too late to see / like new products. Expecially when you’re a vendor neutral analysist.