[Zope3-dev] Re: Separate presentation packages

[Garrett Smith]

Summary: I really, really hope folder_browser doesn't win. :-)

More painful exposition follows...

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.

I'm not sure that looking for packages ending in "_browser" is any 
easier than looking for packages named "browser".

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

How? What is the recommended best practice for plugging new UI into:

   foo/bar/folder
   foo/bar/folder_browser

If I'm maintaining "foo/bar", I suppose I could add:

   foo/bar/folder_browser2

Of course, I could just as easily add:

   foo/bar/folder/browser2

If I'm not the maintainer of "foo/bar", I'd probably do something like this:

   mystuff/folder_browser

But I'd opt for:

   mystuff/folder/browser

or just

   mystuff/folder

if mystuff is strictly a pluggable UI.

> - It enforces the separation of presentation and application code

So does:

   folder/folder.py
   folder/browser.py

among lots of other configurations. Why is folder/folder_browser any better?

I know...shallower hierarchy. What stops us from flattening everything 
into underscored packages?

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

I don't follow this as an argument in favor of "folder_browser" over 
"folder.browser".

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

Not to beat a dead horse, how is typing:

   cd ../foo_browser

faster than:

   cd ../foo/browser

> 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

-1 (if you hadn't guessed :-)

I'm certainly in favor of separating presentation from 
interface/implementation, but using the underscore pattern would be a 
very, very bad thing, IMO.

I'd like to see modular functionality (hand waving) organized as follows:

   modfoo
   --------------------
   modfoo/interfaces.py
   modfoo/modfoo.py or modfoo/_modfoo.py
   modfoo/__init__.py + imports of modfoo.py/_modfoo.py (optional)
   modfoo/browser.py or modfoo/browser/ depending on UI complexity
   modfoo/*.py (other implementation modules)

  -- Garrett