mj at zopatista
Mar 12, 2007, 1:32 AM
Post #1 of 2
(473 views)
Permalink
|
Hi all,
This weekend I had fun with creating views for catalog results. In
order to do this, I had to:
- Create an ICatalogResult interface and use a five:implements
directive to configure ZCatalog.CatalogBrains.AbstractCatalogBrain as
implementing it.
- Set Five.traversable.Traversable as a mixin brain for catalog
results (Catalog.useBrains).
With these changes, I could a) define views for catalog result
objects, and b) traverse over them in a template to obtain the view.
I'd like to add this to Zope trunk, with Traversable a base class for
AbstractCatalogBrain and a implements(ICatalogResult) on that same
class. The obvious advantage of the latter is that one doesn't need to
use Catalog.useBrains any more to add functionality to result objects
(just use adapters). The first change is a necessity if you want to be
able to look up views on results through traversal (in a template for
example).
I'd like to have some feedback on this idea before I do this however,
just to make sure that using Traversable here is a good idea or not.
For the curious, my usecase involved creating workflow menus (a lá
Plone) for a page showing up to 100s of content objects, all AJAX
driven. This enables you to quickly workflow several related objects
without waking up all the content objects just to see their available
workflow transitions. The workflow actions menu is a view defined for
both content objects and catalog results, with the view also
supporting invoking the transition. There are different view classes
for content objects and catalog results, but the template for the view
is the same for both cases.
The catalog result view looks up transitions by hacking up action
information objects, and the only limitation is that transition guards
can not use permission or roles guards (no meaningful context to look
up on) and guard expressions need to be written taking into account
that the context is either a real content object or a catalog result.
These limitations were not a problem for the workflows involved.
--
Martijn Pieters
|
