Thoughts on Content Management and Open Source.

Tuesday, October 25, 2005

Goldegg

Cignex recently announced a new project called Goldegg to help bring Plone to a new level. The project involves over 26 developers from about 17 companies and will be working on all layers of the Plone stack (Plone, Content Management Framework - CMF, and Zope).

This is great news. Plone is already a very solid CMS for building a wide range of we applications from collaborative workspace to e-Commerce site. However, Plone has been struggling with how to will deal with changes in the underlying Zope application server which, with version 3, folds parts of CMF into the core product and makes several other fundamental architectural changes.

The answer, for now, is The Five Project which is a Zope 2 product that allows for the integration of Zope 3 technologies into Zope 2. However, this is a short term solution that will allow Plone developers to gradually incorporate Zope 3's new features. In September, there was a sprint in Vienna, Austria to make CMF use Zope3. Another sprint this week in Fredericksburg, VA will work developing a CMF 2.0 Alpha version. The final sprint will take place November 7-11 will refine how Plone adds Products (modules) on top of the core.

This is also significant because the new project Alfresco is going strong and already offers a compelling feature set on Java technologies which is more familiar than Python for many enterprises. Plone, with its long history and vast install base still has the advantage, but it is good that the community is being proactive about pushing the project forward in such a comprehensive way.

Since Cignex's Munwar Shariff sits on the board of the Plone Foundation, I assume that Goldegg is fully coordinated with the overall Plone project. The next release of Plone (2.2 code named "Ms. Bumblebee") is due out November 11. It will have some of the Plone view components that came out of the Goldegg work..

Labels:

Monday, October 24, 2005

JCR: More than just Java

If you have been intrigued by the The JCR but feel left out because you are not a Java shop, you might be interested to know that other technologies are getting in the game as well. Henri Bergius, of the Midgard CMS has started working on making Midgard accessible to a JCR via JNI (the Java Native Interface which allows you to execute native, non-java, code from a Java application). There has also been talk about a PHP-170 project to implement a JSR 170 compliant repository in PHP although no code has been submitted.

More recently, Stefane Fermigier has written about an attempt to hook Zope into a JCR by using JPype, a Java-Python bridge. In this blog entry, Stefane makes a good case that the structure of the JCR is very similar to the ZODB because both are node based rather than relational (as in a relational database). Having JCR storage option this would address a common issue with Zope which is that the ZODB is closed and difficult to manage in extreme conditions. My current client has a ZODB which is over 45 GB (That is just text. Images are stored outside.) and is growing at a rate of 2 GB per month (packed). We are working on a prototype to store content in a relational database to get around that limitation. In the elevator, I ran into a former co-worker who works for another company upstairs and they are doing the exact same thing. The ZODB is enticingly easy to build applications on and, in most cases, more than sufficient. However, in extreme cases, alternatives, especially standards compliant ones, are nice to have.

Labels:

Monday, October 03, 2005

Bricolage for Print

There was a recent thread on the Bricolage mailing list about using Bricolage to support print as well as web publishing. Given Bricolage's history and focus on publishing magazines and other periodicals, I am not surprised that there were some good anwers. One of the respondents recommended creating presentation templates that write to an XML format that can be imported into Adobe InDesign CS. In InDesign, you can create style sheets where you map incoming XML tags to InDesign layouts. If you don't have Adobe InDesign, another option is to use Apache XML:FOP (pronounced Pho as in the Vietnamese food or Faux as in fake) which stands for Formatting Objects Processor. XML FOP is a very cool technology which takes an XML format and can output to different print formats with an emphasis on PDF.

By using this technique, you can get excellent re-use between your print and web content and you will also be able to leverage Bricolage's powerful workflow functionality.

Labels: