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

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

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to