[Zope3-dev] Zope 3 Source organization

[Tres Seaver]

On Sun, 2003-07-13 at 18:35, Jim Fulton wrote:
> 
> Hi,
> 
> Last december, we made a concerted attempt to improve the organization
> of the source tree:
> 
> - Made the tree somewhat shallower
> 
> - Adopted the twisted module naming conventions
> 
> - Separated presentation code into separate trees to make it
>    easier for people working on presentation only.  The idea was
>    that presentation folks didn't want to scan through the regular
>    sources to find presentation code.

I think this was a false goal:  we were trying to satisfy an audience
who doesn't (yet, anyway) exist, penalizing the folks who actually work
in the Zope3 code every day.

> 
> - Separated interface code into separate trees.  This was driven
>    by two things:
> 
>    o People working on presentation need to consult interfaces.
>      There's no point separating the presentation code if people
>      still have to search the regular code for interfaces.
> 
>    o Tres at one point lobbied for separating the interface code
>      into a separate tree.

The only case I can see for separation is where true pluggability is a
high-priority goal:  e.g., you have an important use case for supplying
alternate implementations of a component, and the real cost of
abstracting away the interface and the browser bits will pay *immediate*
returns.

Note that I will contend that pluggability is *not* a goal for
straightforward content objects!

In cases where the abstraction is worthwhile, the browser bits will
presumably depend solely on the interfaces;  we should therefore locate
the browser bits *with* the interfaces on which they depend.  Such
interfaces and dependent browser bits then form the framework into which
concrete implementations plug themselves.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com