[Zope] Re: ZClass Bug (was: Re: [Zope] How to access id and title of document calling standard_html_header)

[Tim Hicks]

----- Original Message -----
From: "Dieter Maurer" <dieter@handshake.de>
To: "Tim Hicks" <tim@sitefusion.co.uk>
Cc: <zope@zope.org>
Sent: Tuesday, September 05, 2000 9:44 PM
Subject: ZClass Bug (was: Re: [Zope] How to access id and title of
document calling standard_html_header)


> Tim Hicks writes:
>  > OK, I think that I am perhaps misusing zclasses then.  Here is
what I
>  > have.
> No you did not.
>

That's a relief.

>  > I have a Folder that was created by using the 'Add new item' menu
>  > within Zope.  This folder is called 'Site'.
>  >
>  > I have a Zclass called 'theatre_class' that has "Base classes
ZObject,
>  > _ZClass_for_CatalogAware, _ZClass_for_DTMLDocument"....
>  >
>  > Within the Folder 'Site', I have standard_html_header dtml-method
...
>  > However, if I try to put <dtml-var id> into the
standard_html_header,
>  > I get nothing...
>
> I analysed your problem (in Zope 2.1.6).
> It is *NOT* a problem of "standard_html_header".
> Instead, it is a ZCLass problem.
>

OK.

> The id of a ZInstance created as
> you described it returns "<string>". The browser shows this
> as "empty" because it is a tag it does not understand and
> therefore ignores.
> You see it, though, when you look at the HTML source.
>

Yup, I'm with you on that.

> The reason for this strange id lies in a mismatch between
> your ZClass, more precisely its __init__ method, and
> the content of REQUEST:
>    For some reason, your ZClass uses
>    "DocumentTemplate.DT_String.__init__" as constructor.
>    "DocumentTemplate.DT_String" defines a "id" function
>    and lets it return the value of the "__init__" parameter
>    "__name__". The default for "__name__" is, you guess it,
>    "'<string>'".
>

You are losing me a bit with the "__init__",
"DocumentTemplate.DT_String" and "__name__" (I'm afraid my Python is
limited, to say the least!).  I do see the results of <string> being
the default value though ;-).

>    "ZClass.createInObjectManager" constructs the ZInstance.
>    If the instance has a 'id', it takes this id and
>    ignores the 'id' passed as parameter.
>
>    Thus, you get a ZInstance with this strange id.
>

I think I'm with you there.

>
> I am convinced, this is a ZClass bug.
> I think, that the bug results from the fact, that
> the constructor for a ZCLass deriving from DTML Document
> used "__name__" as "id" replacement.
>
>
> The analysis provides a workaround for you.
> In your ZClass constructor, add
> <dtml-call "REQUEST.set('__name__',REQUEST['id'])">
> before the
> <dtml-with
"<yourClass>.createInObjectManager(REQUEST['id'],REQUEST)">
>

Great.  I presume that this will only work for all *new* instances of
this class however!  I don't suppose you know of a way of remaking all
44 instances of this Zclass I have using this adjusted constructor? I
have tried (see below), but I think I come up against the same
'<string>' problem that I'm actually trying to counteract!

<dtml-in Catalog>

<dtml-call "REQUEST.set('sequence-item',REQUEST['id'])">
<dtml-with "theatre_class.createInObjectManager(REQUEST['id'],
REQUEST)">

     <dtml-call
"propertysheets.theatre_class_property.manage_editProperties(REQUEST)"
>
     <dtml-call "manage_edit(REQUEST)">

</dtml-with>

</dtml-in>

Anyway, I guess this is a different problem again really isn't it?  I
think for now, it will be easier to use my less elegant workaround of
giving the zclass another property called 'counter_id' * that is the
same as the actual id.  I know that this works, and it won't take as
long as remaking all the instances again... I don't have the strength
for that I don't think.

I'll definitely file away your fix for future reference though.
Thanks very much.

>
>
> Now, after I did some work for you, I have some tasks for you:
>
>   * check, whether the bug is in Zope 2.2.1, too

Yes, it does.  I have now found this to occur in 2.1.6, 2.2.0 and
2.2.1.

>   * if this turns out to be the case, file a bug report into
>     the collector.
>

Right, I have done that, hopefully satisfactorily!  Hope you don't
mind, I used 'extensive' quotes from your reply... no point in using
my words to confuse the issue!
Thanks very much Dieter, you've been a MASSIVE help.

tim

>
> Dieter
>