[Zope3-dev] Re: Separate presentation packages: Not :(

[Jim Fulton]

The response to my proposal to have parallel, rather than nested
application and presentation packages has been overwhelmingly negative.
I'll bow to this sentiment, but, as Chris said: "the idea seems all but
stillborn anyway given the reaction of most people.  They will be sorry,
but that's the way it goes. ;-)"

:)

So, we'll move to a very flat organization of zope.app where
most things will be subpackages of zope.app that contain both
application and presentation logic.  Often the presentation
support will be in subpackages:

as in:

zope/
      app/
          folder/
                  __init__.py
                  folder.py
                  configure.zcml
                  tests.py
                  browser/
                          __init__.py
                          browser.py
                          configure.zcml
                          folder.gif
                          tests.py

Other times, the presentation will not be in a separate subpackage,
as in:

zope/
      app/
          folder/
                  __init__.py
                  folder.py
                  configure.zcml
                  browser.py
                  browser.zcml
                  folder.gif
                  tests/
                        test_folder.py
                        test_browser.py

The good news is that,since presentation components are not persistent,
this it will be easy to change our mind when we realize we have erred. :)

Jim

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