Why is index_html() called instead of __call__()?
I've been trying to use PropertyFolder for awhile now. Almost all of my projects depend heavily on functionality that it would make *much* cleaner. I'm running a fairly standard Debian distribution of Zope, but I have to modify PropertyFolder to define index_html() instead of __call__(), otherwise the "object_type" renderer is ignored. I'm not sure PropertyFolder is to blame. Should an object's __call__() method be used to render it? Any ideas why index_html() might be used instead? Where could I go to track down the misbehavior? I'd like to fix this so I can move on to some enhancements. Thank you. --kyler
Kyler Laird wrote:
I've been trying to use PropertyFolder for awhile now. Almost all of my projects depend heavily on functionality that it would make *much* cleaner.
I'm running a fairly standard Debian distribution of Zope, but I have to modify PropertyFolder to define index_html() instead of __call__(), otherwise the "object_type" renderer is ignored. I'm not sure PropertyFolder is to blame.
Should an object's __call__() method be used to render it? Any ideas why index_html() might be used instead? Where could I go to track down the misbehavior? I'd like to fix this so I can move on to some enhancements.
Hi, I've changed the "object-type"-renderer for PropertyFolder > 1.2. It now hooks into __browser_default__. I'm not sure if this works with 2.5.1, with 2.6 it's a fine solution...:) -mj
I've been trying to use PropertyFolder for awhile now. Almost all of my projects depend heavily on functionality that it would make *much* cleaner.
I'm running a fairly standard Debian distribution of Zope, but I have to modify PropertyFolder to define index_html() instead of __call__(), otherwise the "object_type" renderer is ignored. I'm not sure PropertyFolder is to blame.
Should an object's __call__() method be used to render it? Any ideas why index_html() might be used instead? Where could I go to track down the misbehavior? I'd like to fix this so I can move on to some enhancements.
(Apologies if this has been answered already) ZPublisher looks first for index_html, and will only use __call__ if it doesn't find an index_html on the published object. Note that the index_html may be acquired from a containing object, so an object that always wants to control its own rendering should define its own index_html to prevent that. It sounds like the PropertyFolder implementation might want to do something like: class PropertyFolder(...): def __call__(...): ... # alias to be sure we always control our rendering index_html = __call__ Hope this helps, Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Thu, Jan 02, 2003 at 06:04:48PM -0500, Brian Lloyd wrote:
(Apologies if this has been answered already)
It hadn't - to me at least. I appreciate you taking the time to explain it so well.
ZPublisher looks first for index_html, and will only use __call__ if it doesn't find an index_html on the published object.
Ah! That makes sense. What doesn't make sense to me is that PropertyFolder seems to work just fine for other people. Why would my PropertyFolder have index_html defined as something that runs whatever index_html is in the object's context?
Note that the index_html may be acquired from a containing object, so an object that always wants to control its own rendering should define its own index_html to prevent that. It sounds like the PropertyFolder implementation might want to do something like:
class PropertyFolder(...): def __call__(...): ...
# alias to be sure we always control our rendering index_html = __call__
That's pretty much what I've been doing. I even submitted a patch like that, but I was told that it broke in the maintainer's system. Something is not right. (I've been testing this on two systems and they both behave this way, but I suspect PropertyFolder is in use widely.) Unfortunately PropertyFolder *also* does a check like this. It says "If there is an object named [object_name] in the context, run that. Otherwise run index_html." That exercises the "maximum recursion depth" trap if I make index_html == __call__. So...I overrode this behavior and made it just fail if it can not find [object_name]. This works for now, but I'd prefer to have the old behavior where it fails over to using the context's index_html. I suppose I could explicitly call the context's index_html, but I'm not sure how.
Hope this helps,
It does. Thank you. --kyler
Brian Lloyd wrote:
I've been trying to use PropertyFolder for awhile now. Almost all of my projects depend heavily on functionality that it would make *much* cleaner.
I'm running a fairly standard Debian distribution of Zope, but I have to modify PropertyFolder to define index_html() instead of __call__(), otherwise the "object_type" renderer is ignored. I'm not sure PropertyFolder is to blame.
Should an object's __call__() method be used to render it? Any ideas why index_html() might be used instead? Where could I go to track down the misbehavior? I'd like to fix this so I can move on to some enhancements.
(Apologies if this has been answered already)
ZPublisher looks first for index_html, and will only use __call__ if it doesn't find an index_html on the published object. Note that the index_html may be acquired from a containing object, so an object that always wants to control its own rendering should define its own index_html to prevent that. It sounds like the PropertyFolder implementation might want to do something like:
class PropertyFolder(...): def __call__(...): ...
That's what it already does...:) And it hooks into ZOPE's __browser_default__ to determine which template for rendering should be used (user-defined via an attribute or existing default index_html).
# alias to be sure we always control our rendering index_html = __call__
If you set index_html this way, you can't add a index_html into a PropertyFolder anymore. That's the reason why I use __browser_default__ and don't want to set index_html. With Zope2.6 it works pretty well...
Hope this helps,
me too..:) Cheers, maik
participants (3)
-
Brian Lloyd -
Kyler Laird -
Maik Jablonski