Martin Aspeli wrote:
> yuppie wrote:
>> Martin Aspeli wrote:
>>> [...]
>>> Let's consider a type Alpha that has a custom add form registered as 
>>> such a (context, request, fti) adapter with name "Alpha". fti.factory is 
>>> "Alpha", and there's a corresponding IFactory utility (with name "Alpha").
>>> Now, let's say I want to create a new type Beta (e.g. by copying the FTI 
>>> object TTW), based on Alpha. I want this to use Alpha's add form, but 
>>> construct objects with portal_type Beta.
>>> Is this possible? If I set Beta's fti.factory to be something other than 
>>> "Alpha", then it won't find the add view, but if fti.factory is "Alpha" 
>>> then the objects constructed will use Alpha's factory.
>> You should be able to register the same add view twice. One registration 
>> for the name "Alpha" and one for the name "Beta".
> Sure. I was thinking more about the case of customising by copying the 
>>> I can't quite decide whether this is a problem in real life or not, 
>>> although it does seem a bit strange that the add view adapter name and 
>>> the factory utility name have to be the same.
>>> Would it make sense to decouple these, e.g. with a new "add_view_name" 
>>> property?
>> If people really have that problem we can decouple this later. For now I 
>> can't see a need.
> I suspect it's YAGNI since the add view calls _setPortalTypeName() on 
> the newly created instance as well, so the resulting object will have 
> type Beta, not type Alpha.

Oops! I just realized that I didn't read your example correctly. I 
thought you would *want* to set Beta's fti.factory to something different.

As you noticed, using the same factory *and* add view for different 
portal types is supported. In fact that's the reason why we adapt the 
type info and can't use normal browser pages.

Cheers, Yuppie

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to