[Framework-Team] Re: first comments on plip 148 (moving to CMF 2.1)

[Raphael Ritz]

Martin Aspeli schrieb:
> Thanks for the summary, Raphael,
> 
>> 1. try by any means to support the "old" behavior (maybe
>> the fti registering could be done by AT's process_types
>> instead of CMF's ContentInit (I might actually try that
>> - time permitting)
>>
>> 2. Switch to using GS for AT at least internally now!
>>
>> Anyone up for 2?
> 
> Switching all content types to use GS is fairly nasty. If they would
> all break anyway for various other reasons, fine, but then we're
> saying that 95% (or so) of third party products available today will
> not work with Plone 3.0. That's fairly depressing.
 >

noticed I said _internally_?
By that I mean instead of constructing and passing along
ftis as of now AT could as well generate the respective
bits and pieces for a setup_tool-based type registration

> 
> As I said, I'm still wary of using GS as the main install mechanism,
> even if the quickinstaller can now find them thanks to Hanno. The
> uninstall question is still unresolved as far as I can see, in cases
> where you need custom cleanup code,
 >
the approach sketched above wouldn't necessarily interfer
with the quick installer

>  and the
> re-run-all-import-steps-every-time idea scares me - it depends on
> every extension profile being well-behaved with respect to
> re-installation, which it very well may not be.
> 
I still know too little about the internal workings of GS
to be able to say whether could be avoided
 >
> I haven't gone through all the code to try for myself, but in *theory*
> I would've thought that AT had enough information to construct FTIs
> already. 

Sure it has. That's not at all the point. It's more that
up to now, it tried to play nicely with the tool and
use it's higher level API but I agree that this could
be circumvented by moving to an even lower level. It
would be just even more hackey than the AT auto-install
magic is already.

> That is because we call registerType()  gets passed the class
> and can extract the FTI metadata. installTypes() should be able to
> just manually construct FTIs by looking at portal_types to ensure
> uniquness, creating the necessary FTI object and settings its values.
> At the end of the day, and FTI is just a class that you _setObject()
> onto portal_types.
> 

If it were only that easy ... :-(

Welcome to the magic world of Zope 2
product initialization.

Raphael

PS: again, I'm not saying this cannot be done.
It's more a question of whether we want to make
a current hack even more obscure or whether we
want to move towards playing nicely with our
framework (the CMF) instead of fighting it.

> Martin
>