Am 14.09.2008 um 12:26 schrieb yuppie:
> This mail has been lying around for a while because I'm not sure it's
> the right way to start the discussion. But now I'll give it a try.
> the sprinters find some time to discuss this:
I had to leave yesterday evening... it would have been great if we'd
have been able to arrange a CMF sprint in advance even if meant just
discussing these kind of things.
> One result of the "Add forms and menus" thread was that we'd like
> get add views by portal type name. Some custom traversal should look
> and return the right view for the specified portal type.
> I'm currently trying to figure out how to implement that correctly and
> am struggling with some details:
> 1.) What should URLs look like?
> Here are same possible URLs for adding a Message to a guest book:
> 2.) Which hook should be used for custom traversal?
> a) for URLs like http://www.example.org/guestbook/+Message
> In this case we use a special prefix '+' followed by the portal type
> name. CMF containers don't implement IPublishTraverse, so we can
> register an IPublishTraverse adapter. If we don't find an add view, we
> can fall back to DefaultPublishTraverse behavior.
> Unfortunately the IPublishTraverse hook only works with one adapter.
> other packages like plone.app.imaging try to use the same hook, we
> get a problem.
> b) for URLs like http://www.example.org/guestbook/+/Message
> The '+' view already implements IPublishTraverse, so we can't change
> traversal using an adapter. The only solution I can see is to replace
> the '+' view by a customized version.
> c) for URLs like http://www.example.org/guestbook/add/Message
> If we use our own adding view, we can implement IPublishTraverse
> the view or as adapter.
I could live with either b) or c). I guess we need to weigh up the
desirability of being as close to Zope 3 style without unwanted side
effects. c) would to be the cleanest implementation. Would it be
possible to implement b) as a sort of alias for this if desired?
> 3.) For which context should we register the add views?
> The add views will depend on special portal type handling done by the
> traverser. So we register the add views for traverser?
> Or should all views have a default portal type that is used if we
> add views directly? In that case we would register the add view for
I guess the circle we're trying to square here would be what's the
best way to be able to add objects to a particular container. Our
particular experience has been to rely on the need to register views
for a particular container object but, of course, you still need type
information. As the type information (allowed content types for a
container object) is always required it probably makes sense to use
this rather than an implicit allowability through a registered view. I
think this means +1 for registering for the traverser.
> plone.dexterity uses an @@add-dexterity-content traverser, but I
> don't think product names like dexterity or cmf should be visible in
> URLs. Those are implementation details that should be transparent
> for users.
Absolutely. We've found the add forms to be extremely useful but the
dependence on knowing the name of the view is a pain even if you can
enforce a naming convention.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests