On Fri, 2 Mar 2001 08:59, zooko@zooko.com wrote:

Hi Zopesters!

It is now about 3 hours later and I have not yet found any "example code" or instructions that shows how to set up a basic web site or how to write Python code that gets executed, CGI-style, in response to an HTTP transaction. I browsed zope.org, the ZDP, and a site called

Why on earth would you want to do CGI when you have Zope? The whole point of Zope is to supercede CGI, I thought. Zope changes the paradigm from "run this script" to "invoke this method of this object".

"ZopeNewbies". I looked at the "QuickStart" that came with the zope server, but all I saw was how to edit web pages using DTML. I don't want to have anything to do with DTML (though we use it in my product, Mojo Nation[2], which BTW is probably the second-biggest open source Python app, after Zope), and I don't want to edit any static pages, so I stopped reading the "QuickStart".

Your mistake. DTML is the quickest way to get simple, dynamic pages happening. I know I had some functional stuff happening within 10 minutes, and I had no Python experience at all. Looking at what you said you had to do, and recallign the HowTos and Tips I have seen on the Zope.org site, I think you could have had something close to what you wanted within 1 or 2 hours, including learning curve.

So now I give up. I'm going to install apache (`apt-get install apache'), and use the Python bsddb module for a simple dict-like database.

Even though I wasted about half of my scheduled time on trying to set up a basic Zope server, I'll probably still have my prototype up and running 3 hours from now, when I have a meeting with my co-workers.

A couple of recommendations: 1) Be open to learn new things. It seems to me you have come at this problem with a bent to use old style solutions (like CGI) with new style tools. If you think about this for a couple of seconds, you will see this is just absurd. 2) Learn how to search. There are well over a hundred documents on Zope.org, conveniently catalogued and indexed, containing help and examples on doing all sorts of things! I know people from a Perl background wouldn't agree, but perhaps the guys at DC have made this info TOO easy to find?

Regards,

Zooko

[1] apt-get is the app that implements Debian's package management system.

[2] http://mojonation.net/

Have a better one, Curtis Maloney

<zooko@zooko.com> said:

I thought I would look at using ZODB so that I could have the coolness of nearly transparent persistence. Then I thought I would use Zope so that I wouldn't have to bother with connecting the HTTP transactions to the logic.

The latter one was probably the wrong thought. Next time around, you may want to check out WebWare. If you plug the ZODB below that, you've got quite a powerful tool. This raises a question that I've been wanting to discuss. I think I brought up the point before, but I think it is important. Zope currently is a content management system, not a development platform. Note that this is just my momentary conclusion. Because it excels in the content management side, I'd like to see it excel in the development side, but either I'm dumb or it ain't there yet. For reference, my development environment of choice is Smalltalk. Plain Python comes a close second. Why? - Clean language; - Fast code/test/debug cycle; - Refactorable. The second position of Python is caused by two things: - Compared to ST, negligible debugging capacity (in ST, you can actually code in the debugger); - Testing/Debugging means instantiating an interpreter and initializing your whole system, which slows things down for more complex systems. My problem with Zope is that it offers two modes of development: - Through the web: comes close to Smalltalk w.r.t the lack of need for continuously restarting your software system, but frankly: development with Netscape as your IDE sucks big time, Emacs is only partially usable and there is no debugging support whatsoever. I'm a version management freak, and the lack of decent support for e.g. CVS is a showstopper as well (I know about the CVS product, that's why I added "decent"). Furthermore, there are lots of restrictions on the code you can created TTW (where's the switch to get rid of all these security checks?) - Product development: comes close to normal Python development, but as soon as you want to hook up your code to Zope, you're doing continuous restart cycles especially when you want to include domain model code that is also useable elsewhere (i.e., outside of Zope's Product directory and therefore not seen by the Refresh product which alleviates some, but not all, of the pain). I think both modes take away a lot of the advantages of plain Python. What should be done, probably, is connect IDLE and Zope or something in that direction so you can do "local" development, but that's a major undertaking. In both cases, Zope takes away a very big advantage of Python: simplicity. I've been bitten very often by Acquisition and the security model, and most people I talk to solve problems by trial-and-error. Having tried both modes of development for a moderately complex product (on-line domain registration, including handling of the actual registration work), I am starting to regret my choice for Zope as a development environment and looking around for other things (like Webware, or maybe Smalltalk straight away). However, our portal is being developed in Zope, and that works just plain great. Lots of content, and only little bits of code. Nicely structured, clean DTML code, and a lot of faith that this (European) portal will hold up when we translate it to 10 or 15 countries and around the same number of languages. So, what should I do? a) get a life and stop whining, web development sucks whatever method you choose. Not an option for me, the reason I finally landed at languages like Python and Smalltalk is that I'm constantly trying to become more productive. b) junk Zope and fire up VisualWorks. But that'd mean junking a completely useable content management platform. c) listen to you guys tell me how one should go about developing in Zope so that all my problems are solved. I fear that this won't happen... d) all of the above, especially the part about combining Zope for content management and <something_else> for development. This is something I've been considering. Would it be possible to tightly integrate Zope plus <my_future_favorite_development_platform> so you get best of both worlds? What I am aiming at is for example an "Integrator" Zope object, that routes calls to some application server and basically is a content intermediary. <freewheeling thought mode> Say that a call comes to URL x/y/z. 'z' is an Integrator object, probably acquired, and sends out a call to its configured application server with quite probably the URL and all the form data. Maybe in an XML-RPC call. The app server sends back a DTML page, which is parsed by Zope in the usual manner and returned. So you get the benefit of <dtml-var standard_html_header> and small DTML scripts and things like grabbing virtual host configuration data from somewhere else, and still have the Big Chunks of Serious Code somewhere in an environment better suited to software development. The tricky bit is probably what to do with forms returned from the app server. Let's assume it has full knowledge about the fact that it is talking through Zope - would it be possible to do all the necessary rewrites, etcetera? Have people on the list tried this? -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B