[Zope] Re: Traversal of ZODB

[Steve Alexander]

Hi David,


David Trudgett wrote:
> 
> Some questions I have in my mind:
> 
> 1. I used "raw" and you used "PrincipiaSearchSource()" . The reason I used
> raw was because I wanted to be sure that what I got wasn't munged in any
> way, and that what I put back reflects what was actually there before.

Sounds fair enough.
I really shouldn't have used PrincipiaSearchSource(), as the method name
doesn't reflect the function I wanted it to perform. The method
read_raw() would have been more appropriate.

However, my background developing Java applications programs causes me
to favour calling methods to directly pulling in attributes. I *know*
the Python idiom, but I'm not completely comfortable with it yet :-)


> 2. You used the "manage_edit()" method, whereas I just assigned to the
> "raw" property. My way seems to work OK, but I'm not sure how yours works:
> I assume it brings up an edit page in the browser for each document?

My external method isn't returning anything, and isn't passing a REQUEST
or a RESPONSE, so there is nothing returned to the browser at all.

A better version of the external method would return a nicely formatted
status message to the browser.


The difference between setting "raw" directly and using manage_edit() is
that the latter will parse and check the syntax of and save a cooked
version of the DTML. As you just directly set the attribute "raw", you
*might* find that your change aren't all reflected in the operation of
the methods you've changed. However, as you've only changed some HTML
formatting, this shouldn't be a problem with what you've done as yet.

Using manage_edit() will also alert you to invalid syntax in your
changed version by raising a ParseError, that will be visible in the
browser.

If there are additional triggers in a class to get it recatalogued in
various special ways, these might only be triggered from methods like
manage_edit(), whereas setting an attribute will only trigger standard
catalogue awareness.

> 3. I don't like resorting to testing the "meta_type" for a particular
> string value. As you noted in your code, it doesn't allow for subclassing,
> so it's not fully general.

I agree somewhat. However, I think that testing the meta_type is the
most Zope-friendly way to do it :-)
For example, in a pathological case, I could write a Python class in a
Product that ostensibly inherits from DTML Method, but completely
changes the way the attribute "raw" is used.

> 4. I was surprised that the import statement (not to mention
> "re.compile()") could be put outside of the method definition, considering
> that Zope's external methods grab on to individual methods within a Python
> module.

Think about the way Python loads in functions and classes: the file gets
read into the interpreter, and statements get executed (which runs
them), whilst function definitions get executed (which causes their
definitions to appear in the namespace somewhere).

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net