[Zope3-dev] Separate presentation packages

[Jim Fulton]

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

- It makes it clearer that presentatations are pluggable and how

- It enforces the separation of presentation and application code

- If we don't separate presentation into separate packages, some
   will create presentation-specific subpackages anyway.

The disadvantages of separate subpackages are:

- More packages, some of which are very small

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

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

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.

So, I feel rather strongly that we should have packages like:

folder
folder_browser
file
file_browser

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.

Silence is assent. :)

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