[Zope3-dev] Re: Separate presentation packages

[Philipp von Weitershausen]

Jim,

> I sent this earlier in response in another thread, but didn't
> get any response.  I'd be happy to assume no one disagrees
> and accept silence as assent, but, I thought this would be more
> controversal and a terser version got -1's before, so, here it is
> again.  :)

I actually wanted to respond to this and didn't find it in the labyrinth 
of recent packaging threads. :) So, please take this as a big yell to 
cut the silence.

> I think that continueing to separate presentations has a number
> of advantages:
> 
> - It *does* make iteasier for people who just want to modify
>   presentations to find them.

Yup.

> - It makes it clearer that presentatations are pluggable and how

We need to make that *very* clear now. I like to talk to experienced 
Zope2 developers from time to time and have them tell me how they cope 
with application vs. presentation code in large applications. A few 
people have come up with their own frameworks of making presentation 
pluggable in one way or another. Of course, they still have to keep 
everything in one place, 'cause it's Zope2.

The fact that application code, presentation, security, configuration is 
all in different places in Zope3 repells these people (as they have told 
me so personally). So we need to make this separation very attractive in 
a practical and convenient sense.

> The disadvantages of separate subpackages are:
> 
> - More packages, some of which are very small

That's ok. I rather have many small items than few large items.
(modules like zope/app/browser/form/widget.py with >1100 lines scare the 
hell out of me).

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

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.

> I think that the advantages of separating the presentation code far 
> outweigh the disadvantages.

Agreed.

> Note that we won't separate interface code except in the case of 
> "framework" packages that define pluggable frameworks with interfaces
> where there are expected to be multiple implemantations.

+1

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

> 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', while 
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 :).

> Silence is assent. :)

Waaaaaaaaaaaaaaaaaaaaaaaaaaaa. :)


Philipp