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

Raphael Ritz r.ritz at biologie.hu-berlin.de
Wed Sep 13 13:18:19 UTC 2006


Martin Aspeli schrieb:

[..]

>>>>    - An just in passing: is there really no sane way to fix
>>>>      'installTypes' from Archetypes.Extensions.utils?
>>>>      This will break **a lot** of 3rd-party products!
>>> What exactly is the problem here? We cannot have installTypes() not
>>> work, it'll break *everything* and as I said, GS isn't (yet) the answer
>>> for everyone wanting to install a third party product!
>>

Said truth: installTypes doesn't work at the moment. I also consider
this serious that's why I brought this up. And I would even agree
that this is a show stopper.

>> See my notes above, but in general I agree. The problem is some methods
>> where removed from CMF that dealt with FTI installation and I wasn't
>> able to fix the code. Mostly I postponed this as it did not produce any
>> unit test failures and ran out of time in the end.
> 
> I see. Is there some reason why AT can't just adopt those methods back, 
> in the worst case?
> 

Yes, there is. It's not as trivial as it may seem at first glance.
Let me see if I can explain:

'installTypes' from AT calls 'listDefaultTypeInformation' on
the types tool to make sure it only adds types that are installable.
This method was removed in recent CMF versions. Since the switch
to GS it is just not needed anymore.

Of course it is easy enough to re-introduce this method in "our own"
(aka Plone's) types tool but that does not help because it just scanns
all installed products for registered ftis.

The registering of ftis used to happen in CMFCore.utils.ContentInit
but there the passed in ftis are now just ignored.

So the easiest "fix" from an AT perspective would be to reintroduce
support for the old behavior at least with respect to the fti
registering in ContentInit.

But I doubt the CMF people would be happy with that
(and I could understand this).

Alternatively, AT could try to provide an extension profile
on the fly for the types to be installed and load that
but as of now at least I would not know how to do that yet.

I tried a bit to work around the call to 'listDefaultTypeInformation'
from 'installTypes' to begin with and indeed I managed to get
a bit further. The product's installer (I used my CMFBibliographyAT
product for testing but all that matters is that it uses default AT
type installation for its content types) went through without error.
The install log claimed to have installed the types, it looked like
they were there in the types tool in ZMI but looking more closely,
important values where missing from the installed fti and the
types couldn't be instanciated. Looking more closely into this
I figured out that 'manage_addTypeInformation' again relies
on the ftis to be registered by calling and filtering on
'listDefaultTypeInformation' and we are back to square zero.

This is where I currently gave up.

This is not to say that we are necessarily stuck but before
investing more time here we should probably think a bit.
I see at least to options or routes:

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?

Raphael

> Martin
> 
> 





More information about the Framework-Team mailing list