Archetypes-based content-types are traditionally tied to the ZODB as backend storage. It has always been hard making the content available through a RDBMS - the only solution for a long time has been SQLStorage. However the implementation and the behavior was more than flaky. Lately projects like collective.tin (Laurence Rowe) and Contentmirroring by Kapil appeared on the scene. The major reasons for using a RDBMS backend are scalablity and efficiency: with a standard Plone/CMF installation you can create between 4-8 objects per second. Tests with a RDBMS backend have shown that creating the same objects within a database like Postgres is slightly faster: up to 350(!) objects per second.
As a sunday-afternoon exercise I created a prototype of a new RDBMS-storage for Archetypes on top of SQLAlchemy - the preliminary name is RDBMSStorage. The database model uses table inheritance for storing the common metadata within a dublincore table. Content-type specific fields are stored in dedicated tables like document. SQLAlchemy allows us to map the Archetypes field types nicely to SQL datatypes. The code right now is only of prototype quality and for experiementing however the first results look promising.
Some stupid Archetypes behavior observed during the implementation:
- Archetypes creates six new object instances when creating a new document through the portal factory
- The get() method for fields like title, description or text are called up to eight times when viewing a document. That's pretty dumb and might lead to performance issues unless we use some smart caching.
Our SmartPrintNG solution for Plone is now available since about 18 months and it introduced support for generating first-class office documents (PDF, RTF, OOXML, ODT) from Plone content. There are no other comparable solutions available in the Zope world when you compare them based on functionality and quality.
Good things are often not good enough!
It is time to step forward bringing SmartPrintNG into the web-to-print world.
SmartPrintNG is dead - long live SmartPrintNG
Over the last months the complete SmartPrintNG code base has been rewritten from scratch based on a complete new architecture where the Plone integration will only be a small layer on top of the zopyx.smartprintng.core and zopyx.convert2 modules. Based on the new architecture we can integrate web-to-print functionality into almost any Python- and Zope-based application. The new flexiblilty can now be used to generate complex and layout-oriented PDF for e.g. business cards, flyers, books etc. A custom web-2-print solution does not depend on any specific data source - it can be a CMS like Plone or a database - the only requirement is that the data must be accessible through Python.
Some key features of SmartPrintNG web-2-print solutions:
- generates PDF, RTF, ODT, OOXML, WML
- separation of content, templates and styles
- easy installation
- can be installed either locally or on a central server
- client-server architecture
- support for counters (e.g. for page counters).
- supports most common paper formats (A4-A0, Legal, Letter)
- language-specific hyphenation support
- multi-column support
- user-configurable margins
- highly-extensible and configurable
- cheaper than comparable commercial solutions
What's coming up?
- The SmartPrintNG server - the central web-2-print working horse - available as product or hosted service.
All SmartPrintNG related core packages will remain free and will be maintained in the well-known repositories on svn.zope.org and svn.plone.org. Further support, customizations, hosted services etc. will be available on a paid basis.
For further questions and assistance, contact us.
The 9th Zope conference organized by the Deutschsprachige Zope User Group is over.
Time to try out Typo 3 in order to figure out how the Plone competitor(s) actually work. It's good to know the "enemy" in order to fight it properly.
It's Sunday afternoon...time for some fun: let's try out Typo3. Step one: Installation. For MacOSX you can download a pre-packaged 166MB archive from here. The installer just works fine and after some minutes a web-browser starts up with the installer UI. After clicking through the ten-step installation process I got the admin login...not bad so far. Step two: after login into the Typo 3 backend you will see a clean tree on the left with various options in one place (compared to various actions scattered around the Plone UI (which makes more sense to me)). With Typo 3 backend I tried to perform a simple task like adding a simple page. The main tree shows me three options: Page, View, List. Click on each options opens a secondary tree with obviously represents a default tree structure...hmmm...what's the difference between the three? no idea :-) Some how I got into the edit more for a page. Typo 3 seems to support out-of-the-box a page composition model (similar to CMFContentPanels or Collage). A standard page can be composed of different blocks and each block has its own configuration UI (comparable to the BernArticle implementation but implemented in a somewhat nicer way). Enough for today....some observation:
- the UI is pretty complicated and not directly intuitive
- the UI is overloaded with icons and little text
- the usability is not straight forward
- the Typo 3 backend feels a bit sluggish and slow (similar to old Plone 2.X versions) - Plone's inline editing mode is much faster to use
- the default page composition options are definitely stronger than what we have in Plone out-of-the-box (which raises the discussion if the editor needs a idiot-proof UI or requires a UI like in Typo 3 with many options).
That's it for now.
During the Blackforest Sprint a new package z3c.pypimirror has been created under the lead of Daniel Kraft. The major goal was to build up a distributed mirroring infrastructure. Why? PyPI is still a single point-of-failure and because there are a bunch of cases where you need an in-house mirror.
After easy_install-ing z3c.pypimrror you can use the pypimirror script for downlading all packages from PyPI (and as an option all external packages (experimental)). This requires roughly 4 GB of diskspace. After mirroring PyPI you can run a buildout against your local PyPI mirror. Right now I have full copy of PyPI available under http://pypi.zopyx.com. By default zc.buildout asks PyPI always when looking up a package. You can avoid that by the following configuration in your buildout.cfg:
find-links = http://pypi.zopyx.com
allow-hosts = *.zopyx.com
This configuration tells zc.buildout to also look for packages on my local server and to restrict any lookup to the hosts defined within the allow-hosts section - this works like a charm.
The local PyPI mirror also works nicely with easy_install:
easy_install -i pypi.zopyx.com <your package>
The Blackforest Sprint is coming to an end after three days of intensive working.
Some of the results in short:
- a new package z3c.pypimirror has been created in order to prepare a more reliable and fault-tolerant PyPI mirroring infrastructure for the future
- Jim Fulton, Christian Theune, Dieter Maurer and Laurence Rowe were working on ZODB issues. The foundation for several ZODB improvements like a more pluggable ZODB architecture have been laid. Other improvements like a better control over the ZODB cache sizes will likely pop up in next major ZODB release.
- Major progres has been achieved in the eggification of Zope 2.12 (Hanno Schlichting, Florian Schulze, Godefroid Chapelle)
- Andi Zeidler and Simon Pamiés were working on a Grok application where you can point to a existing Zope instance. It will fulltext-index all your ZCML files and provide a UI for searching through your ZCML configuration.
- The Devilstick team made significant progres on the project (sorry, but I don't know about the details :-))
Click here for some sprint impressions.
Starting today, SmartPrintNG V 1.2.0 and higher is available under the LGPL 3 license. There is no longer a difference between commercial and non-commercial usage. This means that SmartPrintNG is now free for commercial usage under the terms of the LGPL.
Are you dealing with lots of SVN externals? Are you impatient and don't want to wait for minutes until Subversion updates all your svn:externals one after the other?
You might look at zopyx.parallel_svn_externals_updater performing update operations on svn:externals in parallel (e.g. updates all svn:externals of a Zope 2.11 checkout in 10-15 seconds).