[Zope3-dev] Re: Separate presentation packages

[Philipp von Weitershausen]

Jim Fulton wrote:
> I said a disadvantage was:
> 
>>> - More navigation, but the navigation is simple under the new
>>>   shallow organization.  For example, if I'm in foo and I want
>>>   to get to the directory with the browser code, I only have to
>>>   cd to ../foo_browser, which isn't so bad.
> 
> and you agreed:
> 
>> We need to reduce navigation, for the reason I've stated above: not to 
>> confuse and scare away people that are not familiar with that scheme.

Yes. All I'm saying is that we need to make it extemely easy to 
understand and even easier to grok the package hierarchy.

>>> So, I feel rather strongly that we should have packages like:
>>>
>>> folder
>>> folder_browser
>>> file
>>> file_browser
>>
>> I don't have a constructive competitive idea, but I firmly dislike the 
>> underscore. Could be that this is a matter of taste. I wish I had an 
>> idea of my own. All I can do right now is think aloud:
>>
>> <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>
> 
> But this moves things far apart.  Now the packages relared to foo
> are in different trees.

I realize that it is less convenient for immediatedly practical 
navigation. It think it'll be easier to understand, though.

> I think foo-related-ness is at least as important
> as browser relatedness.

Too bad their two different kinds of relatednesses. We would really need 
three-dimensional directory trees.

> I *hate* looking in different trees for browser and application code
> related to a topic.

Fair enough, I can see why.

>>> and so on. Note, again, that this separation is a good bit different
>>> than what we have now. The presentation code is *close* to the 
>>> application
>>> code while still being separate.
>>
>> But it'll look as if it were on the same hierarchical 'layer',
> 
> Right. That's a good thing. I can see foo and foo_browser together
> in one place.

But they are not two of a kind. That's what I was trying to say::

>> conceptually it's not. I still think of it as a trabant, a satellite 
>> of the actual application code-containing package. An exchangeable 
>> satellite, if you want :).
> 
> Yes. I expect to find satallites close to their primary bodies, not off
> in a separate solar system.

I'm thinking more of a parallel universe :). Seriously, the relation foo 
to foo_browser is a different one than foo to bar:

zope.foo ---browser-package---> zope.foo_browser
zope.foo ---peer-package---> zope.bar

Philipp