[Zope3-dev] Re: Separate presentation packages

[Philipp von Weitershausen]

Dominik Huber wrote:
> 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

It is not core vs. browser. 'core' is the wrong word. It is application 
  vs. presentation. Whether something is part of Zope core, optional, or 
somethine else, is not part of this discussion. We want packages to be 
able to change their status with respect to coreness or option.

Back to your hierarchy mockup:

- You are putting packages in a deeper hierarchy. That means:

   * The package hierarchy will not be flattened. Paths and import 
statements will be very long

   * In order to get from zope.app.core.foo to its browser package, you 
need to navigate a lot.

   Bottom line: It will be just as confusing as it is now

- I hope that we won't have packages such as 'zope.app.core.bar.bar', or 
even 'zope.app.bar.bar'. One more layer below zope.app should be enough 
in most cases. Exceptions are test packages which are hopefully being 
replaced by test modules where appropriate.

> 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.

I agree with you that hierarchy is a good way to solve ambiguity. I 
don't think that ambiguity is our main problem, if it is one at all. I'm 
not going to repeat our goals again. Jim has listed them at the 
beginning of the thread.

The bottom line is that we want application and presentation packages 
"separate but close". That cannot be solved by deep hierarchy. Since 
Python does not leave us with much else, a naming convention seems like 
the only solution. Believe me, I don't like underscores in package names 
either and I'd be happier if I knew a better solution.

>>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 ;)

What do you mean with better tool support?

Philipp