[Zope-CMF] [dev] add view traversal

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> Hi!
> 
> 
> 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"[1] 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:
> 
> http://www.example.org/guestbook/+Message
> http://www.example.org/guestbook/@@+Message
> http://www.example.org/guestbook/addMessage.html
> 
> http://www.example.org/guestbook/+/Message
> http://www.example.org/guestbook/@@+/Message
> http://www.example.org/guestbook/+/addMessage.html
> 
> http://www.example.org/guestbook/+cmf/Message
> http://www.example.org/guestbook/@@+cmf/Message
> http://www.example.org/guestbook/+cmf/addMessage.html
> 
> http://www.example.org/guestbook/add/Message
> http://www.example.org/guestbook/@@add/Message
> http://www.example.org/guestbook/add/addMessage.html
> 
> 
> 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[2] 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 
> container.
> 
> 
> 
> plone.dexterity[3] 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
   it.

 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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
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

iD8DBQFIzQiQ+gerLs4ltQ4RAo4WAKCcVH2ceg4yvs8FmAwWbCsrhBHTmwCgi7eO
fGNT58nb9hZNn4RPJjiEPMQ=
=rZJY
-----END PGP SIGNATURE-----