Hi Tres,
Putting the policy in the typeinfo objects seems like a much saner place
to keep this stuff than embedding it in a component registry.
+1, at least if we're talking about persistent configuration (which I
guess we are).
Do you have a preference for what shape this should take?
- A simple property 'addview' that gives a view name?
- A simple property 'addview' that gives a view name in a TALES
expression?
- Something using FTI actions?
- Something else?
Also, why not try to use the Zope 3 menu concept? There's even a special
"add menu" directive.
The Z3 menu stuff seems to me bound up with the needs of the
never-gonna-use-it Z3MI: it is overcomplicated for little purpose, and
puts too much policy into "emergent" behavior (ordering of component
lookups, for instance).
Plone uses it to make the "content menu" (the green bar in the
"editable" border) somewhat pluggable and customiseable-by-context. In
hindsight, we could probably just as easily have invented our own
interfaces and used that instead of the ones in zope.app.publisher,
though I don't think they've done too much harm either.
The ordering thing is irritating though.
For add menus, however, there *may* be a purpose to using it since Zope
3 has a specific ZCML directive to declare your "add action". At least
we should consider it.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
