> 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
That's weird though. In the worse case it means writing an XML file to
a temporary location and running an import. Surely, it's better to
just construct the FTI objects appropriately, based on the class
variables set and forget about GS altogether.
> 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
Right, get you now.
> 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 don't think it can, it's the whole way GS works. You define a
sequence of import steps. An import step is essentially a handler that
looks for a particular XML file across the active profile and all
active extension profiles. E.g. the type install one looks for
types.xml. It simply gets all these and then runs through them. You
could restrict to do one import step, i.e. only do the "types" one,
but you'd still be invoking the type installation for all active
That's what I mean when I say that GS is designed to dump and load
site state. It's not raelly designed for the
products-as-add-on-components way that people use Plone, where they
download a bunch of products, try them out and then possibly uninstall
> 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.
I'm not quite so sure that it's hacky. The CMF guys construct an FTI
by way of an XML file and an import handler. AT has always had a
different approach (i.e. it generates methods and forms from the AT
schema). Part of that approach has been the convenience notation of
putting FTI information in class variables. CMF used to require them
to be in a dict, and we converted to a dict before calling its install
methods. I don't really see the problem with us constructing the FTI
from the same information in a slightly different way.
> 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 ... :-(
Why isn't it?
Welcome to the magic world of Zope 2
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.
My point is just that "faking" an XML file (whether it's a physical
file or some intermediary DOM representation) for the GS import
handler feels really wrong. That import handler plays a purpose -
transform an XML file to an FTI (in fact, it requires that the FTI
object is already there, it just sets values on it). We have our own
transform, fsomewhere else, from class variables to an FTI, that ends
up creating an FTI object.
Framework-Team mailing list