death to index_html; ObjectManager?
I am seeing some undesirable effects of the recent 'death to index_html' changes. Folders now have a 'Settings' tab to allow managers to change the default document. This is good. However, the implementation of this lies in the ObjectManager class. The browser-default capabilities may not make sense for other classes, derived from ObjectManager, which are not general purpose 'folders'. I think it would make more sense for the browser-default implementation to sit in a new mixin base class, perhaps OFS.BrowserDefaultManager.BrowserDefaultManager, to be included as a base class of OFS.Folder.Folder but not OFS.ObjectManager.ObjectManager. Any thoughts? Toby Dickenson tdickenson@geminidataloggers.com
The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than "index_html" What was the specific "undesirable effects" you were seeing? If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose. Thanks for the feedback. -Casey Toby Dickenson wrote:
I am seeing some undesirable effects of the recent 'death to index_html' changes.
Folders now have a 'Settings' tab to allow managers to change the default document. This is good.
However, the implementation of this lies in the ObjectManager class. The browser-default capabilities may not make sense for other classes, derived from ObjectManager, which are not general purpose 'folders'.
I think it would make more sense for the browser-default implementation to sit in a new mixin base class, perhaps OFS.BrowserDefaultManager.BrowserDefaultManager, to be included as a base class of OFS.Folder.Folder but not OFS.ObjectManager.ObjectManager.
Any thoughts?
Toby Dickenson tdickenson@geminidataloggers.com
On Tuesday 16 Apr 2002 3:53 pm, Casey Duncan wrote:
What was the specific "undesirable effects" you were seeing?
1. The extra tab in the management interface. 2. That an ObjectManager-derived classes might have a default method which is something other than index_html. (I havent digested this proposal enough to see whether an ObjectManager-derived class can prevent his default method from being changed, but It feels wrong that he should have to)
On 4/16/02 8:53 AM, "Casey Duncan" <casey@zope.com> wrote:
The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than "index_html"
What was the specific "undesirable effects" you were seeing?
If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose.
+1 for the separate mix-in. I use ObjectManager as a base class frequently for non-folderish objects, for which the whole 'death to index_html' notion is moot. -- Jeffrey P Shell www.cuemedia.com
Well I honestly hadn't considered that. So, I suppose changing to to a mix-in inherited by folder is better. However, you should know that the crux of this change is really to the publisher, the mixin is just the management piece. *any* object can define a browser_default hook that overrides 'index_html', not just objectmanagers. -Casey Jeffrey P Shell wrote:
On 4/16/02 8:53 AM, "Casey Duncan" <casey@zope.com> wrote:
The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than "index_html"
What was the specific "undesirable effects" you were seeing?
If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose.
+1 for the separate mix-in. I use ObjectManager as a base class frequently for non-folderish objects, for which the whole 'death to index_html' notion is moot.
On Tue, 16 Apr 2002, 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. *any* object can define a browser_default hook that overrides 'index_html', not just objectmanagers.
All the more reason to make it a mixin, yes? --RDM
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.
*any* object can define a browser_default hook that overrides 'index_html', not just objectmanagers.
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 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: *** lib/python/ZPublisher/BaseRequest.py 27 Mar 2002 21:51:05 -0000 1.47 --- lib/python/ZPublisher/BaseRequest.py 17 Apr 2002 08:39:49 -0000 *************** *** 254,256 **** entry_name = path.pop() ! elif hasattr(getattr(object, 'aq_base', object), 'browser_default'): --- 254,258 ---- entry_name = path.pop() ! elif getattr(getattr(object, 'aq_base', object), ! '_implements_browser_default', 0) and \ ! hasattr(getattr(object, 'aq_base', object), 'browser_default'):
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
On Wednesday 17 Apr 2002 4:23 pm, Casey Duncan wrote:
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^)
Ahhh, that makes sense. Im currently not following Zope3 too closely.
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.
It would be extinct as far as the content manager can see. index_html would still be exposed to product and ZClass developers, but that is unavoidable.
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
IZope3PublisherSemantics ?
participants (5)
-
Casey Duncan -
Jeffrey P Shell -
R. David Murray -
Toby Dickenson -
Toby Dickenson