In zc.buildout we have the parts. Those are put together using the 'parts =' parameter in buildouts main section.

At some point you may got the feeling this defines the parts order of execution. But this is most time wrong. It just defines which parts to take into account. The order given there is only important if there don't occur any reordering later.

This means order is valid for:

[buildout]
parts = part1 part2

[part1]
recipe = somerecipe

[part2]
recipe = somerecipe

But dependencies can overrule the given order, like:

[buildout]
parts = part1 part2

[part1]
recipe = somerecipe1
someparameter = ${part2:otherparameter}

[part2]
recipe = somerecipe2
otherparameter = foo

part2 got executed first, then part1.

Now its not necessary to references part2 anymore in parts, the following is exact the same as above example:

[buildout]
parts = part1

[part1]
recipe = somerecipe
someparameter = ${part2:otherparameter}

[part2]
recipe = somerecipe
otherparameter = foo

With this knowledge we can simplify our recent Plone 3.2 buildouts, well even if this is not a major advantage, its just removes redundant information. But lets demonstrate:

[buildout]
parts = instance    
extends = http://dist.plone.org/release/3.2rc1/versions.cfg
versions = versions    
newest = false    
find-links =
    http://dist.plone.org
    http://download.zope.org/ppix/
    http://download.zope.org/distribution/
    http://effbot.org/downloads

[zope2]
recipe = plone.recipe.zope2install
url = http://www.zope.org/Products/Zope/2.10.7/Zope-2.10.7-final.tgz    
fake-zope-eggs = true
additional-fake-eggs =
    ZConfig
    pytz

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
http-address = 8080
zope2-location = ${zope2:location}
eggs = Plone

At the moment it is common to declare eggs always in the buildout section (same for zcml). I switched to declare them always in the instance section. If I have more than one instance I reference the eggs, zcml and products section of the first instance in the following. Major reason is to have better control over the order in which eggs are built/fetched. I hit a problem while trying to use celementree. The provided binary egg does not work correctly (no idea why). Fortunately we can do custom builds and it just works to do:

[celementtree]
recipe = zc.recipe.egg:custom
egg = celementtree

If all eggs, specifically the add-on which depends on celementree, is declared in the buildouts eggs section it is fetched first, buildout fails. 

Declaring all eggs in the instances eggs section, except the special one helps:

[buildout]
parts = instance
# ... missing lines see above
eggs =
    ${celementtree:egg}

[celementtree]
recipe = zc.recipe.egg:custom
egg = celementtree

# ... missing lines see above

[instance]
# ... missing lines see above
eggs = 
    ${buildout:eggs}
    Plone
    my.addon.dependend_on_celementree

Now buildout first resolves dependencies of the main [buildout] section and first [celementree] is built. Next [instance] ist hit, but it depends on [zope], so first zope is built, then [instance] and at the moment it builds it resolves the eggs with it dependencies, celementree is already there so it does not need to fetch it again.

I hope this make things a bit more clear.

Some weeks ago we began to work on a new Archetypes extension, called archetypes.fieldtraverser. It should be now ready for a broader audience to use and test.

Plone in concert, 1997. Credits: Alan Farmer, Bearos Records

Our archetypes.fieldtraverser allows you to access field contents via an URL, like so:

PATH-TO-YOUR-ARCHETYPES-OBJECT/++atfield++FIELDNAME

You can also address a specific storage flavour of your field with:

PATH-TO-YOUR-ARCHETYPES-OBJECT/++atfield++FIELDNAME-STORAGENAME

So, if you have an archetypes newsitem object called "news-of-the-world" which has an image-field with the name "image" and an automatically resized image stored in storage name "thumb", you can access it like so:

news-of-the-world/++atfield++image-thumb

This notation is very useful if you want to access fields which use the AnnotationStorage mechanism. Object-annotated fields are not accessible as attributes on objects (obj.fieldname in python) nor via obj/fieldname (TALES) notation. You have to access them via the Schema in Zope-Views with obj.Schema()['FIELDNAME'].get(obj). This restricted python code is not possible to use in PageTemplates. Although with recent ATContentTypes the conventional notation is still possible because ATContentTypes hacks __bobo_traverse__.
With archetypes.fieldtraverser you have the possibility to access fields in Page Templates in an easy way.
archetypes.fieldtraverser also works with archetypes.schemaextender extended schemas and is in production use at http://trolltech.com/

Storing images or other binary data as annotation on objects has the advantage of a more lightweight object access. Normally, if you access an object which contains binary data, a certain amount of binary data is loaded regardless if you use it or not. Not so if you use AnnotationStorage for this binary data.

Since Plone3, ATContentTypes images, files and texts use AnnotationStorage per default. Also, recent ArchGenXML versions use AnnotationStorage for images and files.

Also, it can be very handy to access raw content via an URL request.

Funny that after releasing archetypes.fieldtraverser we have found that the current Archetypes trunk has a similar solution (Archetypes.traverser.ImageTraverser). At the same time similar work was done on two different places on earth. But our solution is more flexible because you can access any field via the archetypes.fieldtraverser ++atfield++FIELDNAME notation and specific storage flavours too.

Sadly, patching Archetypes is not so easy. archetypes.fieldtraverser has to be loaded BEFORE any Archetypes based content types are initialized - more concrete: before any archetypes schemas are built. Traditional products are loaded before any zcml referenced eggs are loaded. So we have to tweak Archetypes content types which are products afterwards (see patch.py). This is the case with ATContentTypes, even as eggified version in Plone3.2. In Plone3.2 ATContentTypes has the namespace Products.ATContentTypes. The directory where the python eggs reside is in the Python path and Zope recognises ATContentTypes as normal product, because it lives in an Products.* namespace.

This problem would be gone if archetypes.fieldtraverser finds it way into Archetypes itself, replacing the current image-traverser solution which is less flexible. We'll prepare a PLIP for this.

Let us know if you find any bugs or if you have any ideas how to improve archetypes.fieldtraverser. Or help us with development. Mail to: dev [at] bluedynamics.com

PYPI: http://pypi.python.org/pypi/archetypes.fieldtraverser
SVN: http://svn.plone.org/svn/archetypes/archetypes.fieldtraverser/trunk/

This week BlueDynamics Alliance participates at the Bolzano sprint in South Tyrol/ Italy. Here a short wrap-up.

Our major topic is to push Devilstick, the new style model-driven framework for Zope and Plone. Paula - zope 3 PAU-extensions and its PAS bridges - is also topic and related in some parts.

Robert and Hannes started with pair-programming on the model-agent package. The model-agent is the generic reader, writer and validator of cornerstone.model. 

Peter and I discussed the userinterface: how might a generic form look like? Peter started a mock-up to collect ideas. It bases on the current UI of Plone but needs extensions to provide a good experience.

Florian fixed some issues with Paula authentication. He currently uses Paula for an real-world project. His next task is to connect it to a WSDL providing service. Here the plan is to write an transaction-manager for zopes persistent API and use it. Devilsticks storage will work as well this way.

I myself did some coordination-work and started now with implementation of the DAO-API. It was specified at the Blackforest sprint and for those interested.

Also socializing happens :-) After a day of sprint we ended up at Hopfen & Co.  and later in an Irish Pub. 

The official press release for the world plone day in Innsbruck at pressetext austria (german): http://www.pressetext.at/pte.mc?pte=081110022.

Plone Code Swarm

Plone Code Swarm from Chris Calloway on Vimeo.

Noch spannender ist der Plone Collective Code Swarm. 

Wahnsinn, welche Aktivitäten der Community hier abgebildet werden!

zworkb, yenzenz bzw jensens, rnix und hpeteragitator von BlueDynamics sind als Entwickler der Plone Community dabei.

Die beiden Plone Code Swarm wurden mit  code.google.com/p/codeswarm/ vom svn.plone.org/svn/ am 23. und am 26. Oktober 2008 erstellt.