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