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
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
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
>> add views directly? In that case we would register the add view for
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 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
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.
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
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests