Rob Miller wrote:
i'm picking up a thread from january that sort of petered out...
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
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