On 9/13/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
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.

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, 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.

Because Hanno's solution uses the QI, it has the same uninstall
features as the QI, regardless of whether the install was procedural
or done using GS.  The repeatability of install steps is important,
but it was true for procedural installs with the QI too, I don't see
the issue really.  If one has non-repeatable install steps in their GS
profile they will figure it out very quickly dring development in my

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. 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.

Yeah, an FTI is just a persistent object in the types tool that
implements a specific set of interfaces.  CMF certainly doesn't requie
GS to create these things, though some of the convenience APIs for
doing this are now gone, it's not so hard to do anyway AFAICT.  I
would suggest however that e.g. ArchGenXML start generating GS
profiles automatically for workflow and fti stuff, which would help
make it clear that the old AT magic class variable way is no longer
the "right" way".


Framework-Team mailing list

Reply via email to