[Zope-CMF] [dev] add view traversal

[Martin Aspeli]

Jens Vagelpohl wrote:

>> 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.
> 
> This looks like a good solution. I believe Zope 3 uses the same or a  
> similar style.

I don't think we can do this. The + view implements IAdding which has 
special semantics. Existing types are likely to rely on + being an 
IAdding view.

Zope 3 does use IAdding for zope.app.form/zope.formlib based add views; 
With z3c.form, IAdding support is optional, but the preference is to 
just use views like @@add-foo.html (note: I hate the .html convention; 
it is superfluous and looks weird, IMHO).

I think it's better to use a different name. For plone.dexterity, I've 
done this:

http://dev.plone.org/plone/browser/plone.dexterity/trunk/plone/dexterity/browser/add.py

The add view traverser is called @@add-dexterity-content. It's 
deliberately framework-specific since I want particular semantics (a 
default add view based on FTI information only if no type-specific add 
view is registered). That's all fine, though, since we look up the exact 
URL for add view in an action anyway. We don't need a one-size-fits all 
traverser (which the + view had to be).

I'm monkey patching the TypesTool to backport the changes Yuppie already 
made to CMF trunk to support folder/add actions.

For CMF, how about a simple @@add or maybe @@add-content?


>> 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?

No. That's how IAdding works, and it's basically what we're trying to 
avoid. If the context of the view is the IAdding view, then self.context 
is not a content item, which makes for all kinds of self.context.context 
type lookups, messes with vocabulary factories, makes security tricky in 
some cases, and generally is confusing.

(If you *do* want this, then we should just use CMFAdding form 
Products.Five, by the way).

The add view should be registered for IContainerish, unless it's a type 
addable only in one particular type of container.

The add view needs to do some checking that adding is allowed, too; see 
the pasted file above.

>> 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.

I think if you access @@add directly, you get an error. I can't see 
there being a use case for a default type.

>> 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.
> 
> I agree.

I agree with that sentiment, but it doesn't really matter, I don't 
think. Users never type add view URLs anyway, do they - they come from 
actions :)

My preference is actually @@add. However, that's very generic. Like I 
said, Dexterity needs its own version to have its own semantics, which 
means it needs its own name. I didn't want to do an @@add "override" or 
anything like that, since not all content is going to be Dexterity-managed.

So, in summary:

  +1 for http://site.com/folder/@@add/PortalType

  -1 for anything with .html

...and + is probably not going to work.

One last thing to note: You need to put the portal type in the URL, but 
portal types can have spaces and the like in the name. That's probably 
not a problem, but there may be a case for some kind of normalisation.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book