Quick note about TAL changes on recent Plone versions

I know that using complex TAL expression on Zope Page Templates is bad and symptom of bad software architecture...
...however sometimes you have an old product that... simply works!

Only recently, with Plone 4.2, we found that something changed in ZPT language rules (don't know if this is realated to the Chameleon introduction, or Zope guys found some security issues): what is changed is how you can define TALES string expressions.

The only definition of TALES string expression I know is the one learned when I was young from the old-fashion book "Definitive Guide to Plone" (wow... we are talking of Plone 2.0!).

Roughly speaking: a string expression is something that looks like follow:
"string: statictext ${path expression} another static part"

And in the definition of path expression is possible to concatenate multiple path expressions as follow:
"context/foo/bar|context/baz"

So: in old Plone (Zope) you were able to write something like this:
"string: statictext ${context/foo/bar|context/baz} another static part"

In new Plone (Zope) versions this is not possible anymore, you'll get an explicit error (so I really think this is not a bug, but a wanted limitation):
$ must be doubled or followed by a simple path in expression

We must use only simple path expressions, no multiple set..

Fixing old code is simple: just put the path expression in a tal:define, then use the simple defined variable in string expression.

You are warned.

Plone and microdata: adding support to microdata to Plone

My last article was about adding microdata support to Plone event content type.
The article also introduced what changes needs to be done to Plone for getting microdata support (in general) and the resulting product (collective.microdata.event 0.1) applied all those changes.

However microdata inside a framework like Plone is not only something you can add, is also something you can support; so I did my best for creating a product that help people to support easily schema.org vocabulary in Plone.

Introducing collective.microdata.core

The resulting experiment is collective.microdata.core, a base package that provide a set of minimal features I already introduced with collective.microdata.event, but this time without relying on any microdata vocabulary.

The product is not for final users, but for developers and integrators. It simply give those features:

• Provide the definition for the Thing schema.org type (the most basic ones) for all Plone content types (because every content can be a "thing")
• Provide a rude adapter for obtaining a Thing definition from a content (a very little set of informations)
• Provide a catalog indexer for saving into brains the most specific microdata type
• Provide the catalog indexer implementation for Thing.

The package is very small because there isn't a lot of work to do. Unluckily the most part of the work is inside the content's view (like I said in the previous post) and this is still something not very easy to do right now.

Testing you microdata (directly in Plone)

I already wrote about how can be difficult testing microdata today with online tools and what is the JavaScript Microdata Tool. The collective.microdata.core product can adding this little JavaScript library to Plone, just for testing purpose.

This can help you "seeing" microdata inside Plone pages.

Microdata information inside folder content listing views

Having microdata in content views is great, however you must know that you can provide more that one microdata snippet inside a page. Going back to events example: you can provide a list of events, and search engines can index them all.

The optional package collective.microdata.contentlisting is doing this, but know that the task is not very easy.

Once again: we need to customize Plone views (in that case I talk about folder listings views). The product (right now) is limiting itself to customize the "standard" and "summary" views.

The problem in this task is related to the different type of information we need to put inside those views, when we met different microdata types.
Plone itself put some custom logic inside views, for displaying better information when the listed item is an Event (for displaying start and end date) or a News Item (for displaying the creator; I think this is a new feature, never saw before). This can't be a general purpose approach.

So: this experimental package simplify a lot views, delegating what to be displayed to other tiny-views that 3rd party product can provide. Obviously, default tiny-views are supported by the product so you didn't see any difference.

Once again, collective.microdata.event (new 0.2 version) is supporting this extension.

The new version of collective.microdata.event

Version 0.2 is only a refactoring: all logic has been moved to the core package, and this has been transformed to a working implementation of the other two packages.

Moving on

There's still the main issue: when provide microdata implementation we need a deep customization of content's view (if you remember my previous article: customizing with the use of old-way "main" macro). This are an issue that an add-on product can't fix without customizing the Plone main_template (and this is something I really don't like).

It's impossible to have a microdata support in Plone without putting some new features in the Plone core. Is not possible to be sure how important microdata can be in the near future, but I'm quite sure that can be really useful. I think that Plone need to directly support microdata (at least, for the content's main view).

What we can do then? What about a PLIP?