[Zope3-dev] Re: Separate presentation packages

[Jeffrey P Shell]

On Feb 16, 2004, at 5:11 AM, Stephan Richter wrote:

> On Sunday 15 February 2004 17:57, Philipp von Weitershausen wrote:
>>> <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>
>>
>> I took this crazy idea one step further: Why not make zope.app a
>> top-level package as well?
>>
>> Consider:
>>
>> - zope      -- contains general application code, just like now
>> - zopeapp    -- like zope.app above (flat packages, etc.)
>> - zopebrowser -- like above
>> - ...
>
> I find all these a step in the right direction. Certainly much cleaner 
> than
> the underscore.

It's cleaner than the underscore.  I don't really like it.  It feels 
redundant to have 'zope' there so many times, like the damn 'z' in 
front of so many product names.

I like zope.app
I like zope.app.content

Those were very intuitive.  The separation of components (presentation, 
interfaces) could be tricky and annoying to deal with - but the 
structure was clean and consistent.

As far as navigation goes - I think it's a lot harder to stare at a 
directory listing in a terminal with hundreds of similarly named 
entries and trying to narrow one out.

So, I think that some of the current organization is a bit difficult, 
but I like the general concept of good and deep package hierarchy.

I don't want

folder
folderbrowser
folderwebdav
folderftp
folderxmlrpc
folderrest
foldersoap
folderrdf

For every ******* little item.  Granted, that list is a little extreme, 
but I hope the idea carries.  It seems awfully redundant, and smacks of 
C code naming conventions {where in the absence of namespaces, all 
API's tend to pick up prefixes}.

I liked the ZCML <disable> idea.

If we have to have file and i18n_file, and browser and ftp and xmlrpc 
and yada yada yada stock presentations for each thing like that - then 
I've got lots of terminal paging and scrolling and squinting to deal 
with.

And if, as Jim infers (and I don't think he's off base with this) a lot 
of these packages become small - why have folder [which may be a bad 
example in this case] be a package at all?  If half of these become 
single module packages with a configure.zcml file that I've got to 
track down and winnow out and figure out what's going on - I don't see 
the improvement.  It seems to me to be a step back.

--
Jeffrey P Shell
jeff at bottlerocket.net