Hey,
Dan Korostelev wrote:
2009/2/25 Martijn Faassen faas...@startifact.com:
I hope in fact zope.app.* will soon become a dumping ground for
deprecated packages providing legacy ZMI support. Of course that will
need the consensus that the ZMI *is* legacy software. I think do we
already have a consensus that packages that provide other useful
functionality shouldn't be providing ZMI support within the same
package.
Though it's a very big +1 from me that packages providing useful
functionality shouldn't contain ZMI-related stuff within the same
package, and that's our goal,
Good :)
I wouldn't say that ZMI is a legacy
software, as it's very useful out of box and can be easily extended to
make real use of Zope. I'd rather say that ZMI is an example of
extensible application built on top of zope frameworks and it should
be positioned like that.
I spoke a bit too quickly about this, then. If there are people
interested in maintaining the ZMI then it should certainly be
maintained. I'd see that as a project that's not part of the Zope
Framework project but part of the Zope 3 app server project (or possibly
a project by itself).
BTW, I have a thought about an additional refactoring strategy: we
could move ZMI-related packages to separate packages, like zmi.* or
something, leaving imports in zope.app.* and making zope.app.* really
deprecated. That way we can state that ZMI is not the Zope, but
something built on it. And this way gives us more refactoring freedom
:)
If people want to do this I would be fine with it. I won't focus my own
refactoring efforts on this though as I think factoring out the
framework functionality has a higher priority, and I have far less use
for the ZMI. I do agree it would make it a lot more clear what the ZMI
is about if it were in its own set of packages, and would also be a
better kind of example.
It's not necessary to have a zmi packages for each package now in
zope.app.*; several packages could be combined in some cases, I suspect.
If later on for flexibility it turns out that it would be good to
separate bits out again, this extraction can be done then. Anyway,
whatever is the easiest way to go forward.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )