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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests