[Zope-dev] Re: death to index_html; ObjectManager?

[Casey Duncan]

Toby Dickenson wrote:
> On Tuesday 16 Apr 2002 10:25 pm, Casey Duncan wrote:
> 
> 
>>However, you should know that the crux of this change is really to the
>>publisher, the mixin is just the management piece.
>>
> 
> Hmmm. Thanks for raising this. I wasnt aware that these browser_default 
> changes went so deep.
> 
> Im curious as to *why* they do. It looks like the requirements on the wiki 
> could have been implemented by getting the management interface to add a 
> smart index_html attribute that delegates to the real method.

Yes it could be, but I felt like that was not a proper integration of 
the solution. Perhaps the name of the proposal crept into my thinking 
here. To me killing index_html is not the same as hiding it behind a 
custom index_html.

> Ive just checked through the implementation to see if you really mean *any* 
> object..... and you do. The name browser_default is in the namespace 
> accessible to PropertyManager (for properties) and ObjectManager (for 
> sub-objects).  I guess this choice was deliberate, but I can see it being a 
> problem for all those objects that are "objects" not "content".

I more or less copied the spirit of the Zope3 implementation. Whether 
that was a good idea or not in this context is debatable 8^)

> I would be happier if this change to ZPublisher was conditional on something 
> outside the through-the-web manageable namespace, and something which means 
> it is turned off by default for legacy objects. Either an interface 
> assertion, or something like:

I think you are on to something. However I might take this idea a step 
further (into Zope3 land) and make the assertion in the __implements__ 
attribute. So that objects supplying a custom browser_default can assert:

__implements__ = ICustomBrowserDefault

Than the publisher can check for this assertions before trying to use 
the browser default hook (rather than just checking for the hook as is 
current).

Otherwise, you are just polluting the namespace with two names: 
_implements_browser_default and browser_default and hoping this is less 
prone to unintended behavior.

The problem I see with both of these ideas is that they are different 
from the paradigm of Zope2, however at least there is some precidence 
for using __implements__ and you are asserting an interface that defines 
a callable method.

Thoughts?

-Casey