Re: [Zope-CMF] index_html acquisition
Off the top of my head and completely untested, I would change my __init__() function do to something like this: def __init__(self,...): """Initialize my content""" # do stuff here ... del(self.index_html) ... # do more stuff here Obviously, I wouldn't try this in production, and I'm no python supergenious, but there has to be a way to do this...unless the python interpreter chases down attributes by looking at parent classes instead of merely copying the attributes to the child classes... Hmmm this could be more problematic than I thought. Give it a shot. Give us a shout. We'll figure it out. Troy David Hart wrote:
Hi,
Err, sorry my previous post went to the wrong list (zope-dev).
I have a product based on PortalFolder & PortalContent, among other classes.
Brian Lloyd wrote on 2003-01-02 in thread "Why is index_html() called instead of ..." :
ZPublisher looks first for index_html, and will only use __call__ if it doesn't find an index_html on the published object.
I've discovered PortalContent is setting index_html = None.
Is there any way this variable can be 'unset' to re-enable acquisition of index_html?
Would I possibly be better off with my own patched version of PortalContent?
Other than grepping source code and using DocFinderEverywhere showDocumentation?expand_all=1, what are other good ways to trace issues like this one?
-dave
_______________________________________________ Zope-CMF maillist - Zope-CMF@zope.org http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Troy Farrell wrote:
Off the top of my head and completely untested, I would change my __init__() function do to something like this:
def __init__(self,...): """Initialize my content"""
# do stuff here ... del(self.index_html) ... # do more stuff here
Obviously, I wouldn't try this in production, and I'm no python supergenious, but there has to be a way to do this...unless the python interpreter chases down attributes by looking at parent classes instead of merely copying the attributes to the child classes... Hmmm this could be more problematic than I thought. Give it a shot. Give us a shout. We'll figure it out.
Good idea! But, it didn't work. :( ZPublisher still is not picking up the acquired index_html, hence my __call__ function is being called. I could try to make my __call__ function do what ZPublisher would do, but that's a nasty hack, IMO, and breaks the possibility of a standard override to index_html with __browser_default__ and other stuff. -dave
I've discovered PortalContent is setting index_html = None.
Is there any way this variable can be 'unset' to re-enable acquisition of index_html?
Would I possibly be better off with my own patched version of PortalContent?
Other than grepping source code and using DocFinderEverywhere showDocumentation?expand_all=1, what are other good ways to trace issues like this one?
I tried my own patched PortalContent without "index_html = None" and it works, so this is obviously the cause. But, this approach is not ideal. It would be ideal if there were an easy way to 'unset' or 'del' the [class] local variable index_html! -dave
David Hart wrote:
I tried my own patched PortalContent without "index_html = None" and it works, so this is obviously the cause. But, this approach is not ideal.
It would be ideal if there were an easy way to 'unset' or 'del' the [class] local variable index_html!
I answered this for you on zope-cmf... cheers, Chris
participants (3)
-
Chris Withers -
David Hart -
Troy Farrell