[Zope3-dev] RE: Separate presentation packages

[Dominik Huber]

> Philipp von Weitershausen wrote:
[...]
> 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.

I know, excuse my stupid example :S

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

I try to express my concern in an other way (excuse my clumsy english).

IMO presentation (view) and application (model) are two different aspects of the same logical level.
I think Jim states the same:
>I think it's pretty jarring. This is what we have now.  (Well,
>what we have now is worse, because of different levels within
>the app and browser hierarchies.

If I structure a simple package x in a pure hierachical way which accounts that presentation and application are on the same level, the following structure might obtained:

x.application.app.Foo
x.application.interfaces.IFoo
...
x.presentation.browser.FooView
x.presentation.xmlrpc.FooView
x.presentation.webdav.FooView
...

IMO this is a deep hierarchy. The "separate but close" way might remove the classification application and presentation (but it will be still easy to mentaly reproduce the beneath deep hierarchy):

x.app.Foo
x.interfaces.IFoo
...
x.browser.FooView
...

It looks like yours (Philipp's) <thinking-out-loud-mode>-suggestion:
> - zope.app   -- containing flat packages with application code
> - zope.browser   -- containing just as flat packages with browser code
> - zope.webdav   -- ........ with WebDAV presentation

If I have to a provide a sophisticated package I would be forced to split up into subpackages because my modules become to complex:

x.app._foo.Foo (import in __init__)
x.app.bar.Bar
x.interfaces._foo.IFoo
x.interfaces.bar.IBar
...
x.browser._foo.FooView
x.browser.bar.BarView
...

Deepness comes with complexity. ("separate but close" = the simplest possible hierarchy which can display a certain complexity but not simplier!)

My concern: Anyhow a package is implemented (simple or sophisticated) a potential reader or contributor should come across the same logical hierarchy in both scenarios. That implies the naming of root modules/packages must be conservative. It's a temporal aspect of unambiguity.
It's not a question of affectation, it's only a trade-off between programmers to provide an unique way code is structured: exp.
- x.app -> application implementation
- x.products -> options and extensions, nested subpackages
- x.interfaces -> interace definition
- x.browser -> http presentation

When I look at zope.app today I think the main advantage is we could establish a prototype of such a trade-off.

I really like those conventions how people have to structure their code. It makes it easier to browse packages. The only thing is that the current prototype shows some weak points. I compare the current situation with the above mockup to illustrate some mismatches, IMO:

- There are no x.app.X but a lot of x.x.X
  
  Application code naming does not behave conservative. 
  Application code complexity is not encapsulated.

- There are often one or two hierarchical levels more because we have to handle zope.apps complexity:

  x.app.interfaces.catalog.catalog.ICatalog
  x.app.browser.catalog.catalog.CatalogEditView

- There is that problem of different levels within application and presentation

  x.app.browser instead x.browser
  x.app.interfaces instead of x.interfaces

- Subpackages are not nested packages (encapsulate). Everything is in an absolute structere.
  There are a lot of packages which doesn'ot belong to the core and increase the complexity. 
  They will be refactored out soon. This will induce more clearness.

  At least remove thematical/functional packages (-> products)
  Nested product packages have a deep hierarchy.

When I consider those mismatches I assess their *impact on usability* is pretty huge and all that is that *what we have now and Jim thinks most people hate it*.

Anyhow it is dangerous to project all those impacts on to the dotted package hierarchy!

> >> 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?
It's a usability question of the editor vi and a personal decision of each developer. Nobody would rename code if I say it's pretty hard to develope zope3 using wordpad. ;)

regard,
dominik