[Zope] - RE: Zope programming idioms

[Jeff Bauer]

  >> 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, 

Yes, that is what I was using the 'whatever' placeholder
for, but you elucidated the principle better.

  > 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.

I've done this too, and had considered it as a kind
of alternative that makes me feel slightly queasy.

  > 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.
  
I think I intuit it okay, given my prior experience with
Bobo, but full grokking can only occur when one has a
chance to break things <0.4 wink>.

  > 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. 

Thanks, this is a useful data point.

Okay, what started off as a simple post has brought us to
the edge of where Bobo left off and Zope begins.

One issue to be addressed is how to combine the raw power
and flexibility of pure Bobo within the Zope framework.
I think Amos' experimental External Objects (12/14/98)
is one attempt to address this issue.

I confess:  Although I can see the overwhelming usefulness
of Zope in distributing the "web-construction-maintenance"
portion of the workload to users (esp. non-programmers --
no mean feat), I'm still uncertain as to how I can apply
it all programatically (i.e. without bci/ZPublisher.Client)
with the ease I've enjoyed using Bobo.

Best regards,

Jeff Bauer
Rubicon, Inc.