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

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.


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.


Framework-Team mailing list

Reply via email to