Paul Winkler wrote:
I'm hoping to see a similarly interactive, yet long-term-sane, working style evolve for in zope 3. Maybe we'll get there with Persisent Modules and fssync.

This is an issue that's important to me, and to Jim. We had a discussion about all of this in various weblogs a few months ago - I referenced them earlier in some of these threads.

I get the impression that Jim wants to drop the promise that Zope 3 is going to gain TTW development features though. It hasn't happened so far, and it's misleading peope. He wants to refocus these efforts to Zope 2's ZMI as far as I understand.

I'm not sure whether this is the right wa to go - any presumed new-style TTW development tools would hopefully leverage the Zope 3 components, so even though I'm targeting a Zope 2 audience initially perhaps I'd still like my newly developed system to work with in a pure Zope 3 environment. This means that dropping our promise that we're going to regain functionality in Zope 3 may not be the optimal approach in all this.

If there's a moral to this story, it's this:
Scaffolding that gets you up and running with a minimum of
fuss is a great thing.  Rapid interactive and iterative development
is also a great thing.  But if you can't easily transition from there to
more complex apps that are still maintainable, it sucks. It's irritating
to have to throw away some of your knowledge and completely replace it
with new ways of thinking; it's better if the new knowledge strictly
supplements the old.  It's worse than irritating to have to throw away
your work and rebuild it from scratch; it's better if your new work can
cleanly leverage the old.

Put another way, if we consider Jim's first two audiences, how do we
teach a single person to move from "i don't want to have to care" to zope zen master / SVN contributor with minimal wasted effort along the way?
Today I don't know if there's a clear coherent story to be told there,
even for zope 2. If there was... wow, that would be a great.

Sorry if I haven't really said anything new.

It's good to say more people say this in different words. I have a very similar experience.

On the one hand, Zope 2 TTW development is a great marketing feature to draw people in, and a great way of working for a certain group of people, some of whom will never become a software developer because they don't even want to.

On the other hand, this way of working in Zope 2 has produced hard to maintain code, and creating UIs for it all sometimes has been a waste of effort that could've been better spent on making the APIs better, say.

We need a way to enable the Zope 2 TTW person to be productive without that person creating huge maintenance costs later on. Code created by ZMI developers should look like something that could also be on the filesystem, and can be checked into SVN, and refactored and developed further, i.e. be taken into real maintenance without major hurdles.


Zope3-dev mailing list

Reply via email to