[Zope3-dev] Separate package trees for presentation and interfaces

[Jim Fulton]

Martijn has proposed giving views their own hierarchy within the Zope
software packages:

   http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ViewDirectoryHierarchyReorganization

See also:

   http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ProposedDirectoryHierarchy

The reason for this is to provide a focussed place for web developers where they will
not be `distracted or confused by non-presentation code.

I endorse this idea.

I have a couple of minor quibbles:

   - We have official actors,
     http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/UserGoalsAndUseCases

     This proposal is really aimed at the site designer.

   - The focus should be on presentation not just views. Presentation includes resources.

Some notes:

   - There should be a separate tree for each presentation type
     (e.g. "browser", "ftp", "xmlrpc")

   - This proposal and the package organization that Martijn proposed
     should apply on a project by project basis. Browser presentation
     software included in the Zope core should be under zope.app.browser,
     but other Zope 3 projects or products should have their own hierarchies.

     In separate packages, presentations might be collected in simple modules,
     rather than packages. For example, the Contact example should be a single package
     with no sub-packages, other that tests, and a browser.py file containing the
     browser presentation code.

Part of the rational for separating the presentation code into it's own hierarchy
is that the presentation should be independent of application implementation.
View code should only depend on interfaces, not on implementation. View developers
shouldn't have to refer to or search through the application implementation code,
because they depend soley on interfaces.  Given this, it makes sense to separate the
interface code from the implementation code as well. Otherwise, view developers
will *still* have to navigate and understand the implementation hierarchy to
find the interfaces that they depend on.

Another problem with including interfaces in the implementation hierarchy is
that it leads to either overly large and incohesive interface files or to
multi-word file names, like "iview.py" or "viewinterfaces.py".  For example, this
last week I did quite a bit of work in the services package implementing various
facilities to implement adapter and view services.  I ended up with a large
interfaces module that contained a bunch of unrelated interfaces. Had I merged in
other interfaces defined in the same package, the situation would have been much worse.
The adapter-service-related and view-service-related interfaces really need
to be broken out into separate files (e.g. adapterinterfaces.py and viewinyerfaces.py).

I propose that interfaces be given their own hierarchy within a *project*. This means
that the zope.app would have a package/module tree rooted at zope.app.interfaces.

Note that projects that fit in a single package will generally have a simple interfaces
mdoule, rather than an interfaces package. For example, the contact example would
have a single interfaces.py file, rather than an interfaces package.

With this change, the adapter-service-related interfaces would live in:

   zope.app.interfaces.service.adapter

rather than:

   zope.app.service.adapterinterfaces

Note that, for a separate Zope top-level package, like schema, the interfaces
would go in an ordinary interfaces module, like zope/schema/interfaces.py.

The advantages of providing a separate interface hieratchy are that:

   - Individual modules remain cohesive and have simple names

   - View developers don't have to navigate the implementation hierarchy to
     find the interfaces they need.

The disadvantage of this approach is that absolute imports will be necessary in
many cases where relative imports can be used otherwise.  This is not so much of
a problem now because relative imports are currently implicit and, thus, frowned upon.
If Python introduces an explicit relative import syntax, then the inability to
use relative imports will be more significant.

So, unless someone convices me otherwise, we'll move forward with separate presentation
and interface hierarchies.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org