[Zope3-dev] Re: Separate presentation packages

[Jim Fulton]

Garrett Smith wrote:

...

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

I am.  I can look at a single directory listing and immediately
see all of the presentation packages.  To find subpackages named
browser, I need to use find. But maybe subpackages aren't used,
maybe there are browser.py modules.

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

foo/bar is a bit too abstract.

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

I think it would be unlikely for the maintainer of
zope.app.folder and zope.app.folder_browser to create a second
browser UI.  A third-party developer will likely create an
alternative presentation somehere else, like zc.folder_browser.
They could start by just copying zope.app.folder_browser.

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

Because it is a separate package, with it's own configuration file.

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

Nothing. :)

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

It's not. But a disadvantage of folder_browser is that it will often cause
us to create extra packages. My point was that we'd often create extra
packages 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.
> 
> 
> Not to beat a dead horse, how is typing:
> 
>   cd ../foo_browser
> 
> faster than:
> 
>   cd ../foo/browser

If you are already in foo, you wouldn't type cd ../foo/browser,
you'd type cd browser. but If there wasn't a separate browser package,
then you wouldn't have to cd at all.

...

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

yes

>   modfoo/browser.py or modfoo/browser/ depending on UI complexity
>   modfoo/*.py (other implementation modules)

plus:

    modfoo/*.pt (template modules)
    modfoo/*.jpg (images)
    configure.zcml

And I think that this provides less separation than we should have.

People who *just* want to focus on presentation need to sort it
out from the other code.  People who just want the application code
have all this extra browser code.
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