- RE: Zope programming idioms
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.
At 08:38 PM 12/17/98 -0600, Jeff Bauer wrote:
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.
This is a difficult issue. I don't have a good answer right now. Part of my motivation for writing 'External Objects' was to try out a possible answer. Bobo is much more simple and flexible than Zope. The Zope framework provides lot of services, but it also imposes lots of conventions in order to play ball. It's hard to know how or even if it's possible to marry to "raw power and flexibility" of Bobo to the fuller services of Zope. I'm definitely open to suggestions. Maybe there could be some way to code in Bobo, but write the UI in Zope... Or maybe we just need to better document the Product API so that writing a real Product doesn't seem so daunting. Maybe we should consider further segmenting the Zope Framework so that you can pick and choose the pieces you want. I think this is a fairly deep question, and hopefully we can learn more about what some answers might be as people outside DC get more experience with Zope. Zope's-not-right-for-absolutely-everything-but-Bobo-is-ly yrs, -Amos
Amos Latteier wrote:
Bobo is much more simple and flexible than Zope. The Zope framework provides lot of services, but it also imposes lots of conventions in order to play ball.
It's hard to know how or even if it's possible to marry to "raw power and flexibility" of Bobo to the fuller services of Zope. I'm definitely open to suggestions.
Maybe there could be some way to code in Bobo, but write the UI in Zope... Or maybe we just need to better document the Product API so that writing a real Product doesn't seem so daunting. Maybe we should consider further segmenting the Zope Framework so that you can pick and choose the pieces you want.
For example, we have a "web tool" coded in bobo and it would be great, I think, if we could add a "newsgroup" for the tool embedded inside it, along with the other documentation. The way I imagine this to work is by simply importing a newsgroup python module (confera?), making a newsgroup instance and giving it a name to publish it. Would something like that be possible in principle? Or is it possible right now? Regards, Jan -- =================================================================== Jan Decaluwe === Easics === Design Manager === VHDL-based ASIC design services === Tel: +32-16-395 600 =================================== Fax: +32-16-395 619 Interleuvenlaan 86, B-3001 Leuven, BELGIUM mailto:jand@easics.be http://www.easics.com
On Fri, 18 Dec 1998, Amos Latteier wrote:
This is a difficult issue. I don't have a good answer right now. Part of my motivation for writing 'External Objects' was to try out a possible answer.
Bobo is much more simple and flexible than Zope. The Zope framework provides lot of services, but it also imposes lots of conventions in order to play ball.
It's hard to know how or even if it's possible to marry to "raw power and flexibility" of Bobo to the fuller services of Zope. I'm definitely open to suggestions. My solution to this has been a bit radical ;) (Admittingly my Zope allergy stems more from my BoboPOS reluctance (but Emacs & CVS make for a much nicer site management.)
I basically wrote my own file based object server with Bobo and DTMLs, it's basically not that difficult ;) In fact, after the fact I've noticed that my solution has by default a completely different object usage: -) Objects are short lived. That is a disadvantage that you have to write activation/deactivation code right into the object, but it has the advantage that such code that explicitly loads/saves the object to the filestorage object exists, and that the data is available from the outside. -) Actually, there are usually two different classes for an object: One Runtime class, and one Management class. This has some disadvantages, including the fact that normally the management URL is reached by prefixing the path with "edit/" but I (personally) don't consider that a major problem: The editing interface IMHO MUST run via https, while the Runtime interface in many cases is better served by http. (Be it the additional cost and hassle of obtaining an additional domain certificate, be it that stupid user will probably enter http:// and not https://, etc.) It surely on the other hand has the advantage in Intranet/Internet solutions where there must be TWO servers: One Intranet one, which is edited, and one Internet version, which by design is NOT to be edited. This is quite easy to produce with a file tree based server, and the Editing functions are all killed by leaving out the /edit/ Entry or pointing it to a different class than "DirectoryEdit" :)
Maybe there could be some way to code in Bobo, but write the UI in Zope...
Even better. Offer the possibility to write the UI via the Web AND via any normal file editor :) So basically, the question how much interest there is in such a ``much nearer to Bobo environement''? Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
participants (4)
-
Amos Latteier -
Andreas Kostyrka -
Jan Decaluwe -
Jeff Bauer