At 06:59 PM 12/17/98 -0600, Jeff Bauer wrote:
In general I write methods that should be accessed from the web the same way as you do:
Then I must be doing something right <wink>.
def spice(self,salt,pepper,REQUEST=None): "spice the meal" ... if REQUEST is not None: return self.some_dtml_class_attribute(self,REQUEST, message="meal successfully spiced")
If there is no need to specifically confirm the spicing operation, you could return a different method, like index_html, the PARENT's index_html, or manage_main, etc. depending on context.
Okay, just getting independent confirmation that I'm not totally off-base helps. Or at least I'm in good company.
At any rate, the round-trip nature of dtml to object methods to dtml to whatever probably makes useful how-to fodder. How will the proposed JimF changes to DocumentTemplate affect this idiom?
Well there are a couple different scenarios, it's not always DTML to object method to DTML, etc. Often you can view the request->response, request->response cycle of interaction of you app as simply DTML -> DTML -> DTML, etc. Since the URL often refers to a object method that *IS* DTML. So this scenario involves a succession of DTML generated pages being displayed that include links to other DTML pages. You still with me here? In fact my spice example could be written in this style by having the request URL go to a page that looks like this: """ <!--#call expr="spice(salt,pepper)"--> <h1>Meal successfully spiced</h1> """ I personally find this style less appealing. But you can structure things either way. In fact, you will probably encounter this style a lot more in Zope that you would in Bobo, since it's much easier to write DTML in Zope than it is to write Python code. Additionally, this style is more conducive to objects with ad hoc attributes--like Folders. In fact it may help Bobo programmers to think of Zope folders as essentially empty instances whose attributes are built by adding Documents, and External Methods, and other objects to them. I think if you grok this Zope will make a lot more sense. Finally, as to how Jim's new DTML Document Product will changes things, I predict that from the programmer's point of view it won't. You will still probably be best served by using DTML Methods as you always have. DTML Methods are a view of an object--a template though which the object can be displayed. DTML Documents will be objects that hold their own content. Is the difference clear? It's confusing because we haven't had real DTML Documents until now, and so templates have been perverted into content objects. working-to-reduce-perversion-ly yrs, -Amos