[Zope] Re: Zope digest, Vol 1 #2140 - 48 msgs

Dan Shafer pydan@danshafer.com
Wed, 05 Jun 2002 09:37:29 -0700


At 07:19 AM 6/5/2002 -0400, Simon Michael wrote:

>Dan - for what it's worth, here's how my zope product learning curve went.
>
>I probably had it easier than some - there was an existing product that
>was quite similar to mine - DTML Document. I copied this, changed the
>meta_type, and got it showing up in the ZMI etc. Then I started making
>modifications, tackling problems and gradually learned more about how it
>worked. I've kept doing that ever since.

Perfect example, Simon. How in the world do you "copy" DTML Document class? 
It doesn't show up in the Product Management Control Panel. Yet I know that 
to change its meta-type, I'm going to have to get into the Control Panel, no?

>When I hit problems I would search for insights in the docs and would
>learn something, but never used them as my main guide (the books didn't
>exist then). I would also search the lists for clues (these days I would
>probably turn to #zope first).
>
>I didn't have a really usable debug setup until recently (using ZEO).  I
>would say this is a must, or failing that at least set up a comfortable
>way to print debug messages. When testing/debugging you end up using a
>complex cocktail of web browsers/code windows/editors/server control
>windows and you need to develop a feel for when things need refreshing,
>when you are really not looking at the code you thought you were because
>of a syntax error, etc.

I have learned that debugging is a borderline nightmare. I've read 
everything I can get my hands on and still it seems Zope debugging is 
primitive to non-existent. I'm sort of surprised that's the case given the 
relative maturity of the product.

>It's still often frustrating, and makes me miss the relative simplicity of
>smalltalk, but for now I don't see any other platform providing what zope
>does, as well as it does.

Sigh. That's sort of where I am. I miss the power and simplicity of 
Smalltalk. I could even *choose* Smalltalk because I'm in complete charge 
of those decisions. But when the finished app has to work over the 
Internet, requires a remote object store, and needs to be deliverable in 
small enough chunks that dial-up users can use it, Smalltalk disappears as 
an option. I spent a LONG time looking at options before settling on Zope 
and I'm loath to give up on it. But programming in this environment is 
reminiscent of some of the labor-of-love languages and tools I used over 
the years that were always a bit short of commercial success and viability.

The absence of an IDE for Zope makes the experience of building Zope apps 
so cumbersome that I feel confident much of the time that all of the time 
I'm saving coding because of the nice OO environment and the cool built-in 
ZODB is being lost in the procedural and mechanical details of getting even 
relatively simple product-type stuff to work.

Periodically, I go into a fit of pique and I search to see if there's 
anything else out there I could use that would be better. There is, but not 
within the affordable range of my finances, system infrastructure, and time 
for learning. I guess I shouldn't be surprised but it is starting to make 
me believe that I should simply abandon the idea of creating real-world 
Web-based apps and services and just go back into my writing hole, leaving 
software development to younger, more agile and more patient minds.