[Zope3-dev] Re: Separate presentation packages

[Philipp von Weitershausen]

Jim Fulton wrote:
>> 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.

Why is that a problem?

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

 From a physical point of view, yes. From a hierarchy point of view, no.

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

You're right, the distance is bigger. That is a clear disadvantage of my 
idea.

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

Right, what we have is worse! Much worse.

With zope, zopeapp, zopebrowser, etc. There will be two levels of depth 
usually. (zope.foo, zopeapp.foo, zopebrowser.foo), and normally you'll 
always be working in level 2. The only times you would have to descent 
into level 3 would be for tests or when 'interfaces' becomes a package.

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

I objected it not for being what it is. I objected it because of taste...

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

You can't separate and keep stuff together at the same time. What do we 
weigh more important? Do we want to

- emphasize separation OR make navigation easier?
- allow easy customization OR have compact structures?
- have a scrutable hierarchy (IOW, flat but meaningful) OR minimize 
distance?

Philipp