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