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, 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.

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

Any thoughts?

WBR, Dan Korostelev
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to