[Zope3-dev] Mandatory Viewing!

Terry Hancock hancock at anansispaceworks.com
Tue Mar 7 16:18:04 EST 2006


On Tuesday 07 March 2006 12:27 pm, Shane Hathaway wrote:
> Part of the problem is that Zope 3 makes too great a distinction between 
> developers and scripters.  Successful scripters become developers, and 
> developers often act as scripters.  I think the use cases need to see 
> scripters and developers as the same people.  The other Python web 
> frameworks seem to be oriented this way and they've had a lot of success.

I would add that scripters and developers are often the same people,
but with greatly different levels of commitment: For a project I
care a lot about (or am well paid for), I might be perfectly willing
to make the "buy in" to develop a complete app from components. For
this, I want something flexible, modular, and well-engineered, which I
can use as a solid foundation for my project.

OTOH, for a quick project to help a local non-profit out, I might
only be willing to do through-the-web scripting (so I want something
quick and easy that's almost ready "out of the box" -- flexibility
is good, but immediate results are better).

In fact I have been in both of these situations (at the same time).

The framework-based Zope 2 is probably better for the latter case
(at present), though the learning curve to do anything beyond the
most simple tasks is steep.  That's partly because it's a framework,
but also partly because of the "historical accidents" of design
that make Zope 2 so inconsistent (and hence confusing to use). E.g.
why the heck do I have to remember an attribute named
"bobobase_modification_time"?

This sort of thing is why the Zope 2 API *must die*. ;-)

Zope 3 is clearly targeted for the high-buy-in case, but paradoxically,
reduces the buy-in because of its modular design.  Zope 3 is
actually what I wanted when I found Zope 2 in the first place.

OTOH, I have a lot of uses for plain scripting environments. I
do program (and I'm more proud of that work), but I do
*more* website "crafting" in my everyday life.

A framework built *on* Zope 3 can solve the "historical accident"
problems, which would make for a better scripter environment than
Zope 2, but it's always going to have limitations to its flexibility.
Which is okay, IMHO -- I have the choice to leap from "scripter"
to "developer" if I want that flexibility.

That's a small leap if I'm leaping from TTW on top of Zope 3, to
Zope 3 component development.

That's good, because a free software development environment thrives
by maintaining a smooth "graded slope" between user and developer,
rather than drawing a distinction -- somewhere along that slope you
can call people "designers", "maintainers", "scripters" or whatever,
but the important point is the continuity -- not just of skill,
but also of interest (or time-available).

Again, I'm not a core Zope developer, so this is an outsider view,
but I feel like I'm in your "market" which is why I should respond.

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com


More information about the Zope3-dev mailing list