[Zope] Argument passing and DTMLFile methods

[Terry Hancock]

Hi all,

First of all, thanks to Dieter Maurer, Charles Riemann,
Michel Bencur, and Joachim Werner for help on the last
couple of headaches on this project! I am getting really
close to releasing this sucker, but ... ;-)

Next up is how to properly pass implicit arguments to
a class-method created by DTMLFile. This probably requires
some explanation, though ...

I'm converting a prototype of the product which I developed
through the web. The presentation layer is fairly large.

In it, I have a few instances of explicit DTMLMethod calls,
like this:

<dtml-var expr="mydtmlmethod(_.None, _, explicitarg=explicitval)">

This syntax is based on the note in the back of the
Zope Book on the equivalent explicit call to a DTMLMethod.

E.g., it claims that:

<dtml-var expr="mydtmlmethod(_.None, _)">

is equivalent to

<dtml-var mydtmlmethod>

And, in the "through-the-web" prototype, this is apparently
true. (That is, I have verified it experimentally).

However, I am now trying to make the prototype into
a product, and I want these DTML methods to act similarly
to their Python method counterparts (NOT python scripts --
I have converted the scripts to product class methods, 
which become object methods when an instance of the object
is created in Zope). 

So far, I've used SQL(), ImageFile(), and DTMLFile() to
successfully convert ZSQL methods, images, and DTML methods
over to the same sort of usage as I have with Python:

from Globals import ImageFile
from Globals import DTMLFile
from Products.ZSQLMethods.SQL import SQL

dbc = database_connection_object	# Defined elsewhere

class MyClass(Folder):
	meta_type = "my_class"

	def python_method(self, ...):
		#... python code adapted from python script ...
		# container/context converted to self, etc.
		# Naturally, this works just fine, as this
		# this is the stuff that's well-documented
		pass

	zsql_method = SQL('zsql_method', '', dbc, args, zsql_code)
		# Works perfectly

	dtml_method = DTMLFile('dtml/mydtmlmethod', 
			globals(), document_id='mydtmlmethod')
		# Works great for implicit DTML usages. Variables,
		# acquisition, etc, all seem to work.

	image_data  = ImageFile('www/myimage', globals())
		# A little weird, because this is the actual
		# image data, not the Zope image object, but
		# still very usable.  Basically, I can't
		# use "tag" or "absolute_url", but I can
		# access it via a URL.


I wasn't certain this would work, since this is different from
containing these objects within the folder (which can be done
either by manage_addMyClass() or MyClass.__init__()).  However,
so far, it works pretty well -- DTML methods are able to find
each other and include subsets, pass implicit variables, etc.

They can be accessed by URL:

	MyClassInstance/dtml_method

and acquisition works on them as expected.

They exist for all instances of the object, and if the methods
are altered, I only have to restart Zope to propagate the
change to all instances. (I.e. I don't have to delete and
re-add the instances).

Furthermore, they are hidden from the management interface,
and are thus "read-only". Great! This is all exactly what
I want -- I'm freezing the prototype into a fixed product.
Changes now have to be made to the product source code to
take effect. This greatly reduces the hazard of accidently
screwing up the product when you're trying to administrate
it. The idea is that only objects which the administrator
would need to alter are made available through the web.

In short, they have all the properties of ordinary python
class methods.

So I'm not sure if this meets "best practice standards",
but it seems like a very natural solution.

I was beginning to be really happy about how smooth this
was all going -- I could even get the correct context in
included DTML methods. "Wow!" I thought, "this Zope thing is
really coming together..." (and "I might actually make
that July 1st date")

EXCEPT... :-(

This only works if I use *implicit* dtml-var substitutions,
like:

<dtml-var mydtml_submethod>

If I try to use the explicit form mentioned above,

<dtml-var expr="mydtml_submethod(_.None, _)">

I lose my context!  I can see variables passed by keywords,
but not the implicit ones. They were visible in the implicit
form, but not the explicit one.  Ack!

Ironic, isn't it?  You'd think I might have to be *more*
explicit in this situation. My guess is that I've somehow
chosen the wrong thing to pass to this method (perhaps "_"
doesn't mean anything in this context?).  Presumeably,
Zope is doing the right thing for implicit references,
but I can't figure out what that is. (This is *after*
"reading the source". Some of the source is quite readable,
but the DTML publishing parts are pretty hairy stuff!).

For one thing, I'm not exactly sure what the difference
is between my DTMLFile object and a DTML Method or
DTML Document (it seems like it can't actually be either
of those, but something related).

I have the frustrating feeling that a simple answer exists
for this, but that I'm just not seeing it, so I'm hoping
this will seem obvious to somebody.

If there's no other way around it, I can probably work-around
this with dtml-let and passing all variables implicitly,
or by sticking huge lists of variables in as keywords, but
these are ugly solutions, and it seems like they ought
to be unnecessary.

Thanks in advance for any ideas.  We *are* very close to
release if this conversion process can be made to work
(the prototype, while basically working, is not up to
production use for a lot of reasons -- we think it will
significantly benefit from being converted into a Product).
I suspect "July 1st" is out the question at this point,
but maybe *next* Monday at this rate. ;-D

I have some screenshots of my prototype version on our
website, for the curious:

http://www.anansispaceworks.com/Columns/News/A.2002.05.20
http://www.anansispaceworks.net/NaryaInfo/naryaintro.html

Naturally, Narya will be open source (GPL), but I do feel
it should have at least minimal functionality before trying
to release it.

Thanks,
Terry

-- 
------------------------------------------------------
Terry Hancock
hancock@anansispaceworks.com       
Anansi Spaceworks                 
http://www.anansispaceworks.com 
P.O. Box 60583                     
Pasadena, CA 91116-6583
------------------------------------------------------