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

[Garrett Smith]

Somehow, this thread got redirected to the 'zope package organization'
topic :-)

Steve Alexander wrote:
>> There will be not many UI designers working on the core components
>> and for products (where I would expect to see a lot of UI people
>> working) the hierarchy looks anyway like::=20
>>=20
>> productX
>> productX/browser
>> productX/interfaces
>>=20
>> which brings me to another point. The zope.app hierarchy is
>> different and therefore inconsistent with all other base zope
>> packages and third party products.
>=20
> How is it different and inconsistent?
>=20
> We have
>=20
>    zope/app
>    zope/app/browser/...
>    zope/app/interfaces/...
>=20
> That seems to be the same as your productX example above.

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.

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

Granted...structurally, files, images, and sql are indeed related to
each other. But that's merely coincidence -- and could easily change
over time. A file's interface, implementation, and views are
unequivocally related and, therefore, form a tighter association. That's
my thinking anyway.

Btw, I think a lot of this is academic -- the fact is that to make a
change to a content type, one has to forage through disparate packages.
The leads to a lot of "huh?" for those not used to the structure.

 -- Garrett