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.
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.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
