-----BEGIN PGP SIGNED MESSAGE-----
> 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. Maybe
> the sprinters find some time to discuss this:
> One result of the "Add forms and menus" thread was that we'd like to
> get add views by portal type name. Some custom traversal should look up
> 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. If
> 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 inside
> the view or as adapter.
> 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 access
> add views directly? In that case we would register the add view for the
> 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.
> Any feedback is welcome.
Here's my take:
o -1 to using IAdding at all. If we use a URL like
/container/+/typename, then the traverser could just use the
next name after '+' to look up the adding view directly and return
o +0 on 'container/+/typename'.
o +1 on 'container/@@add/typename'
o -1 on 'container/add/typname', or any URL token could conflict with
"real" object IDs.
o -0 on the '.html' suffic.
o +0 on 'container/+typename': I don't think this will clash with
anything in Z3: we just have to supply a traverser which does what
I outlined above for 'container/+/typename'.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests