[Zope3-dev] Separate presentation packages

[Martijn Faassen]

Jim Fulton wrote:

> Martijn Faassen wrote:
>
>> Python already provides a namespacing mechanism, involving the dot 
>> notation (foo.browser). You're inventing your own prefix based 
>> namespace mechanism here. Prefix based namespace mechanisms aren't 
>> necessary in Python and seeing one is a bad code smell.
>
>
> True, but then too much hierarchy is considered unpythonic. <shrug>

So we need to find a way without prefixes and without too much hierarchy. :)

> I have reasons why I thought this was better, twice, so I won't
> repeat them.

Okay, I missed the first message initially.

Some observations.

In some sense, the browser package is not independent from the main 
package. If I am distributing my package to you, you'd need *two* 
packages in most cases, one browser, and one core. Of course there are 
cases where I'm distributing browser package only, and (less frequently) 
where the non-view package is being distributed separately, but the 
usual pattern is to distribute a package with its default views. Single 
package with both would make life easier for the common case.

Besides it being two packages, it also means you need to adjust your 
ZCML twice to include both browser as well as content package.

Then again, it becomes easier in ZCML to selectively disable a view 
package. Again though this is not the common case..

So by splitting it into two packages we're making the common case 
harder. Besides the namespace changes (especially invented for Zope, 
nobody else uses this, not Pythonic, etc), we're also making the common 
case more difficult.

You could say we should just improve the distribution mechanism, but 
this is a non-trivial task.

Of course, looking at a package system like debian, you do sometimes see 
a split between 'core app' and 'ui' package distributed separately. This 
is often because there's a command-like UI in the main package, or it's 
a client-server architecture, or the UI is developed by someone else, or 
there are multiple implementations of the UI already available. 
*Usually* however you only install a single package to have a functional 
UI however.

The reasons given for splitting off the UI are similar to this; we want 
the UI to be replacable, etc. But wanting and it being so are two 
different worlds, and we've already learned that structuring our app so 
we anticipate our wished-for reality doesn't necessarily lead to 
anything but extra overhead for the developers...

Regards,

Martijn