[Zope3-dev] Allowing views to be registered for classes ratherthan interfaces.

[Steve Alexander]

> I think zope/app is too big to be compared to a product. In fact, it
> contains a lot of plugins -- e.g. each content type is a pluggable unit,
> for the most part. Zope 3 is designed to eliminate explicit
> interdependencies, yet it's package structure suggests that everything
> is one unit.

So, maybe the problem is that zope.app is too large a "project", and 
should be split up into zope.app.foo and zope.app.bar etc.?


> E.g. I would say that the file interface, implementation, and views are
> *more* tightly associated with each other than they are with their
> respective peer interfaces/implementations/views. E.g.
> 
>  file/interface
>  file/implementation
>  file/view
> 
> forms a tighter association than
> 
>   interface/file
>   interface/image
>   interface/sql

The associations between implementations and interfaces and views are 
very well defined by interfaces. These dependencies are easy to see and 
inspect. There are other dependencies that are less well defined, such 
as those brought about by subclassing.

I would suggest that you will find subclassing for code reuse among
implementations within zope.app.(not interfaces or browser).

I suggest that there is subclassing for reuse among implementations 
within zope.app.browser.

I suggest there is no subclassing for reuse between zope.app.browser and 
zope.app.(not interfaces or browser) and zope.app.interfaces.


Do you think this is a good reason to keep the packages separate?

--
Steve Alexander