[Zope3-dev] Re: Separate presentation packages

[Jim Fulton]

Philipp von Weitershausen wrote:
> Philipp von Weitershausen wrote:
> 
>> <thinking-out-loud-mode>
>>
>> What if we had
>>
>> - zope.app   -- containing flat packages with application code
>> - zope.browser   -- containing just as flat packages with browser code
>> - zope.webdav   -- ........ with WebDAV presentation
>>
>> Hmm... What about a different top-level package?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopepresent.browser  -- contains flat browser packages
>> - zopepresent.webdav  -- contains flat WebDAV packages
>>
>> Or a different top-level package for each presentation type?
>>
>> - zope.app  -- containing flat packages with application code
>> - zopebrowser  -- contains flat browser packages
>> - zopedav  -- contains flat WebDAV packages
>>
>> </thinking-out-loud-mode>
> 
> 
> I took this crazy idea one step further: Why not make zope.app a 
> top-level package as well?
> 
> Consider:
> 
> - zope      -- contains general application code, just like now
> - zopeapp    -- like zope.app above (flat packages, etc.)
> - zopebrowser -- like above
> - ...
> 
> I really like this one. And it'll make packaging easy, too. Don't want 
> the Zope application server? Don't install zopeapp! Don't want browser 
> code? Don't install zopebrowser!

It doesn't make packaging any easier, IMO.  You still have container packages
that you need to install things into. (That reminds me of another
distutils issue.)

> Using several top-level packages has the following advantages:
> 

But that moves things that are closely related (application code for
some topic and the presentation code for some topic) far apart.


> - The package hierarchy is not deep at all. In fact, it'll be even less 
> deep than with zope.app.foo and zope.app.foo_browser...

This is only because you are using a naming convention, a zope
prefix, as a substiture for structure. This is what you objected
to originally.

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

> - It'll make source code navigation pretty easy. You have zope.XYZ or 
> zopeapp.XYZ and need to find its browser views? Well, simply look in 
> zopebrowser.XYZ. Pretty easy to find, I think.

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.

> 
> I see the following disadvantages:
> 
> - The top-level package namespaces will be bloated. This danger is 
> limited, though, since we can safely assume than other people will not 
> make packages starting with the 'zope' prefix.

You are using the same thing you objected to before, a naming convention
as a substiture for structure.

> - The "core" of Zope (whatever that is) will be spread over several 
> top-level packages. People might consider this unaesthetic.

*everything* is separated over multiple trees. This is what we have now
and I think most people hate it.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org