[Zope] RE: Bizarre error with standard_html_header

Curtis Maloney curtis@umd.com.au
Thu, 13 Jul 2000 10:53:12 +1000


On Wed, 12 Jul 2000, Martijn Pieters wrote:
> register will look in internal for objects, but only if it can't find them
> first in the mysite (root) object. Read Jim's acquisition algebra texts:
>
>   http://www.zope.org/Members/jim/Info/IPC8/AcquisitionAlgebra/
>
> So we have:
>
>   mysite/
>
>     standard_html_header
>     register
>
>     internal/
>
>       standard_html_header
>
> and you are calling mysite.internal.register, which in turn tries to call
> mysite.internal.register.standard_html_header. mysite.internal.register is,
> in Jim's algebra: ((register o mysite) o (internal o mysite)), so when
> register tries to call standard_html_header, it will go from left to right
> through this list, and will find mysite.standard_html_header first.

I'll go back and read Jims algebra.. sounds like an eminently logical way of 
keeping things in order. (o8

However, there are some problems with what you say.  If it's using 
/standard_html_header, then why did things change (not exactly for the 
better, but changed) when i started messing with 
/internal/standard_html_header ?

>
> If this worries you about your view of Zope, you're about to reach your
> next level of Zope Zen. =)
>
Oh, goodie!  Do I get a badge for this one? (o8

> >   File /usr/local/Zope-2.1.6-src/lib/python/OFS/DTMLMethod.py, line 146,
> > in __call__
> >     (Object: standard_html_header)
> >   File
> > /usr/local/Zope-2.1.6-src/lib/python/DocumentTemplate/DT_String.py, line
> > 502, in __call__
> >     (Object: standard_html_header)
> > TypeError: (see above)
>
> The first 3 lines let us know that we are _inside_ an object called
> standard_html_header. In your case this will be the on in the root Folder
> of your site, I suspect.

Well, yeh.  From reading the traceback, I thought the problem was in 
standard_html_header, too.  So, first I tried to establish WHICH.

>
> What actually goes wrong I don't know. It _probably_ goes wrong inside the
> rendering of this object, but this is masked, I think, by the fact that the
> next step on the stack is in render_blocks, which is implemented in C.

Well, what still gets me is it complaining of  the wrong number of 
parameters... how can this be?

I think if we can work that out, we'll be a step closer to heaven.

Have a better one,
	Curtis.