<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