[Zope3-dev] RFC: ViewDirectoryHierarchyReorganization

[Martijn Faassen]

Shane Hathaway wrote:
> Martijn Faassen wrote:
> >The directory hierarchy navigation skills are in 
> >a sense a 'dead chicken' in Zope 3. :)
> 
> Is it possible to have "emergent dead chickens"? :-)  I guess it is, 
> because as the hierarchy gets deeper, it gets progressively harder to 
> find things, especially for developers not familiar with the codebase.

Yes. I think an important realization should be that the physical location
of code is part of the implementation. Since we're supposed to be
about interfaces, how come we need to know so much about the 
implementation here?

> Do you have a specific solution to propose?

I would suspect a separate hierarchy containing all browser views.
Presuambly there will also be separate hierarchies containing XML-RPC
views and VFS views and the like, but that's not the prime business.

This hierarchy could reside in Zope.App. I imagine something like:

Zope.App.Views
  
    Browser

      Container

      Folder

      ZPTPage

      File
    
    XMLRPC

    VFS

    ..

Since most close reuse relationships (in the form of inheritance and page
template macros) will be between views, it seems to be sensible to have them
in one place. They will refer to the rest of the codebase primarily through
interfaces. So a single physical location seems to make more sense.

A related question is how to best refer to interfaces (from ZCML files
and to read the API docs in the first place); right now an understanding is
necessary of the physical location of interfaces in order to use them in
these ways. There are shortcuts possible using the dot notation, but I wonder
if something cannot be done here as well.

I understand that a namespace partitioning of interfaces is useful. I 
can also see the case for them being defined near the code they implement,
though I could also imagine they're *not*. So as a far out proposal I'll
suggest a physical separation of interface definitions as well (in a 
separate hierarchy). I know there are many tradeoffs there that need to
be discussed, but some discussion here may be useful. Arguments pro
interface separation are:

  * Interfaces by their very nature can be implemented by multiple
    implementations. It does not make sense that they're physically near
    one particular implementation.

  * Why do I have to know about implementation
    details (where a particular implementation of an interface resides) to
    refer to an interface?

  * Interfaces are there to be read. Readers of interfaces should not
    have to encounter code to read.

  * Close reuse of interfaces (interface inheritance) is also between
    interfaces. The rest of the code *uses* interfaces. There's a 
    partial analogy to views here.

Am I on to something here?

Regards,

Martijn