[Zope3-dev] Re: Separate presentation packages

[Dominik Huber]

Jim Fulton wrote:
>> - Browser and application packages are not in the same container 
>> package. That'll help to make the pluggability of presentation code 
>> quite clear.
>
>At the cost of too much distance. This is what we have now, and I
>think it's a disaster.

IMO the disaster originate from an ambiguous hierarchy. The code hierarchy isn't hierarchically layered into .core (model) and .browser (view) packages etc. like...

exp. package zope.app with module foo and subpackage/module bar.bar

zope.app.core.foo 
zope.app.core.bar.bar
zope.app.browser.foo 
zope.app.browser.bar.bar

... but it's more hierarchically shift-layered into . (model) and .browser (view) etc.:

zope.app.foo
zope.app.bar.bar
zope.app.browser.foo
zope.app.browser.bar.bar

Given the fact that we split up all our code in such a hierachically shift-layered way into a huge package (exp. zope.app), we end up in babel because we are mixing differnt kind of logical hierarchies on one physical context:

- thematical packages -> products (like dublincore, content)
- core packages
- presentation packages -> browser, xmplrpc, webdav
- ...

In one level of our *logical* hierarchy we don't provide a clear mental discriminator. That generates an extra portion of needless complexity (selection/decision). We have an additional mental navigation problem, too.

IMO an unambiguous (exp. hierarchacally layered) code hierarchy and attempt for smaller packages solves most of the disaster whitout abandon the adavantages of the logical established way of information encapsulation by dot's.

>Jim Fulton wrote:
>These is especially painful for people who don't use emacs. :)
>I just spent a week with a room full of vi users doing Zope 3
>coding.  They spend way too much time cd-ing,

IMO the physical navigation problem should we solve with better tool support and it's not legitimation for a crucial naming work-around ;)

>Jim Fulton wrote:
>Guido hates deep hierarchies.  I wouldn't normally go as far as he would,
>but I find that the experince with coming up with a package structure
>for Zope 3 tends to support his point of view.

There is only a problem with ambiguous hierarchies because of there missleading behavior (probability of decision selectivity -> babel effect).

regards,
dominik