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.



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