[Long] Development in Zope (Was: Re: [Zope] data point on ease of learning Zope -- I give up.)

[Cees de Groot]

 <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