yuppie wrote:
Hi Rob!

Rob Miller wrote:
i'm picking up a thread from january that sort of petered out...

yuppie wrote:
Tres Seaver wrote:
Florent Guillaume wrote:
Because the "current base profile id" is not stored, there's no way to
do detect the change to a different base profile. Should I store that
property to allow for that use case?

Yes.  In fact, I would prefer to be able to introspect both "current
base profile" and "applied extension profiles" from the tool.

I don't want to go down that road.

I have to refine this statement: *For now* I don't want to go down that road. In the long run I think we have to keep track of applied profiles. That would help to make the setup tool more powerful and to implement features like reloading or uninstalling. But AFAICS doing this right requires a major refactoring and would come to late for CMF 1.6 or 2.0.

Major refactoring? I don't think so, at least not for storing the basic information about which profiles are applied, which is a first step toward more powerful features.

The next step would be to keep track of the applied profiles a snapshot is based on. Things become more and more complicated and we still can't rely on that information: Sites created with older CMF versions don't have that information and manual customizations can make it quite useless.

i, on the other hand, am very interested in being able to see which profiles have been applied. i don't think it's unreasonable to record and expose this. of course this can't be treated as the final word on the current site configuration, but just because someone may have done further manual configuration doesn't seem to me a good reason to make it harder to figure out which profiles have been applied in the first place.

i'm going to cut a branch to experiment a bit w/ implementing this. in the meantime, this conversation can continue. if the consensus ends up being against these features, i can put any code from the branch in at the Plone level.

I can see that this information might be useful, but it doesn't represent a state of the tool or the site. It has more the character of (sometimes incomplete) history information and I'd prefer to use the logging machinery for that.

It's not state per se, but it's information about what the administrator did to the site. It has the character of history, yes, but needs to be introspected by the tool to provide further features. Just logging the info doesn't cut it.

What about adding that information to the import logs and creating an import log for the initial site creation as well?

Logs aren't useful to implement better features.

FWIW, while we're on the topic of GenericSetup, CPS now has a strong need for extension profile dependencies and ordering. Or choice between mandatory alternate extension profiles (like, choose which extension profile will provide the authentication aspects of the portal). At some point we'll have to spec out something and code it.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to