[Zope-CMF] [dev] 'add' actions and views - a proposal

[yuppie]

Hi Martin!


Martin Aspeli wrote:
> yuppie wrote:
>> Proposed CMFDefault changes
>> ---------------------------
>>
>> 1.) CMF add views adapt not only container and request, but also the 
>> type info object. This way the views can't be accessed directly and have 
>> self.fti available.
> 
> This is quite interesting, and possibly necessary. However, it means 
> that CMF add views are not just "views" and will need to be registered 
> differently to other views (i.e. you can't just use <browser:page /> 
> which also means that you won't get the Five security treatment etc).

Yes. This causes more problems than it solves. I think I found a much 
better solution:

CMF add views are registered for a special layer called IAddViewLayer. 
Like any other layer, IAddViewLayer extends IBrowserRequest. And it 
defines an additional 'ti' attribute for the request.

Like before views can't be accessed directly and have self.ti available. 
(I now use 'ti' instead of 'fti' because we have other type info 
implementations than FactoryTypeInformation.)

>> 3.) A traversal hook looks up the type info based on the view name. And 
>> then returns the corresponding add form:
>> queryMultiAdapter((container, request, fti), name=fti.factory)
> 
> Why do we need to *both* adapt the FTI and use the factory name as the 
> view name?

Because we want to use different views for different content factories 
*and* pass the type info to the view. This way we don't depend on an 
environment that sets the ti value later. And all view methods work from 
the beginning without fallback code for a missing ti.

As mentioned above, I now propose to pass in the type info as part of 
the request object.

>> 6.) An IPublishTraverse adapter is used for IFolderish objects. It tries 
>> to resolve names starting with '+' and falls back to 
>> DefaultPublishTraverse behavior if no add view is found. This way URLs 
>> like http://www.example.org/folder/+PortalType are supported.
> 
> -1
> 
> Or maybe -10 now that I think about it a bit more...

I also started with -1, but thinking a bit more about it my vote is +1.

> This is pretty invasive. It'd make it impossible to have another 
> IPublishTraverse adapter for any IFolderish without either subclassing 
> from the CMFDefault one or breaking all add forms.

Shrug. That is how the IPublishTraverse adapter works. There are many 
use cases for the IPublishTraverse hook and only one available slot. You 
never can be sure that this hook is free. If you write your own 
IPublishTraverse adapter, you always have to look at the code base and 
subclass those adapters you want to use.

> Rather than invent a "pseudo" namespace with a naming convention, why 
> not use a proper namespace, i.e. 
> http://www.example.org/folder/@@add/PortalType ?

What's the difference between a 'pseudo' namespace and a proper namespace?

The 'add' view you propose is a 'pseudo' view. It just exists to be 
bypassed, not to be returned.

> This is short, simple and allows alternative implementations if people 
> want to use a different name (e.g. the @@add-deterity-content traverser 
> in Dexterity), and does not require a clunky traverser for all 
> IFolderish. Instead, you register the @@add view for IFolderish and have 
> it implement IPublishTraverse as well.

We have a trade-off here: clunky traverser vs. clunky URL.

I don't want to have names like '@@add-dexterity-content', 
'@@add-cmf-content' or '@@resize-plone-image' in my URLs. '@@add' looks 
a bit more generic, but it isn't.

'+PortalType' works with any add view implementation. If you hardcode 
the portal type, you can register the add view directly for the default 
skin. If you want to use the CMF traversal or dexterity traversal, you 
can still support the same URL.

Following your proposal, we have '@@addPortalType' for simple add views, 
'@@add/PortalType' for CMF traversal and 
'@@add-dexterity-content/PortalType' for dexterity traversal. I don't 
think that's what IPublishTraverse is made for.

Are the IBaseObject traversers used by Archetypes and plone.app.imaging 
also 'bad'? Or what's the big difference to the adapter I propose?

>> Proposed CMFCore TypesTool changes
>> ----------------------------------
>>
>> 7.) listActions of the types tool returns add actions for *all* portal 
>> types.
> 
> +1 - this change is already done, right?

Yes. Checked in yesterday.

>> 8.) If no add view expression is defined in the type info, a default add 
>> view URL is returned.
> 
> -0
> 
> Would it not be better to push this logic higher up, i.e. in the view 
> code that's actually using the add views?

Can't follow you here. How should that work?

> The default for CMFCore is 
> probably not going to be a suitable fallback for Plone, for example, 
> which means we either need to customise/override or ensure that all 
> types always have such an add action.

With a default value CMFDefault needs no migration code and copying type 
infos is easier. But I agree that it might be useful to make it 
customizable. Maybe we should use a types tool property for that setting?

>> If there are no objections, I'll make the proposed changes on the trunk.
> 
> Apart from the traverser stuff, I think this sounds great. :)

The traverser stuff can easily be changed later, so I can't see a need 
to put my work on hold. And working on a branch isn't very useful 
because you get much less feedback.


Cheers,

	Yuppie