Le 11 mai 2006, à 14:00, yuppie a écrit :
Georges Racinet wrote:
Le 11 mai 2006, à 00:36, Rob Miller a écrit :
I still believe a refactoring as proposed here would be an
improvement, it would also resolve the multiple catalogs issue:
i'm not so fond of this idea, actually. while i'm all for
simplifying things, i'm loathe to give up the flexibility that you
admit we'll be sacrificing. GenericSetup is likely to be used in a
myriad of ways, just because we can manage to get CMF itself to work
with a less flexible GenericSetup doesn't mean that other use cases
won't need it. i'm especially concerned about losing the ability to
have one tool's import step depend on another's.
i'm all for reducing boilerplate, though; i 100% agree that there's
too much of it currently. can you imagine a way to reduce the
boilerplate without sacrificing the flexibility?
Sorry. I did not mean to start that discussion again at this point. I
just wanted to make sure that *if* we decide to implement that
proposal the catalog support changes don't make implementing it
To start the discussion again the mentioned proposal is inappropriate
because it doesn't reflect the discussion that already took place. The
proposal is deferred because one result of the discussion was that we
need a replacement for the partial imports: An import/export tab for
the tools themselves.
Well, sorry to react to outdated things then :-)
And this is not just about reducing boilerplate, it's also about
moving to a more object orientated approach that makes new features
like the import/export tab on object level easier to implement.
I see, I can understand that, since I make a frequent use of the XML
export tab in CPS. Also, the list of I/O steps is so long that I have
to scroll in the setup tool import tab. What you're saying would indeed
be user-friendlier (at least for me).
Also getting rid of the handler functions which don't do much would be
without any doubt better.
Hi, sorry to be late to this party, I didn't notice this proposal,
but maybe was it simply because I didn't use GS at all at this
time... I'll take the opportunity to mention that the two flexibility
features you mention are quite important to me.
When developing with GS I rerun just one step all the time, be it for
quickness or because I may be fixing a small dent while working on a
bigger thing at the same time. It's also interesting when you want,
say, to update a broken workflow on the fly without changing
site-dependent parameters, like LDAP connections and such.
As for dependencies, it's true that the one mentionned is a bit
artificial, but there are more serious ones outside of the CMF. One
really needs to have portal_types set to initialize an object built
on a FTI, for instance. This is of course much more serious.
I'm not sure I understand your example. After the proposed change
there still will be 3 setup steps:
1.) Setting up all the tools with default (empty) settings.
2.) Importing the settings for all the tools in random order.
3.) Importing dependent import steps like content import.
AFAICS your example will work with that order. But I would be
interested in learning about use cases that will not work with that
No, no this looks fine, at least at first sight. I think all
dependencies within step 3 get automatically solved by the intrinsic
tree nature of the thing. I'll get back to you if something comes to my
mind, and it doesn't fall in the 'bad design anyway' category.
Finally, having the tools being exported under their true id breaks
snapshots (although I'm not 100% sure if they are a feature of the GS
tool itself), because of the UniqueObject inheritance, but that could
be easily solved.
Yes. Snapshots are a generic GS feature. And of course we need
backwards compatibility code if we change the file names. But the
renaming might not be necessary.
Well, if the snapshots add '.xml' to the objects id, they won't fail.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests