On 3/7/06, Paul Everitt <[EMAIL PROTECTED]> wrote:
> Shane Hathaway wrote:
> > It is a beautiful story and I dearly want it to work.  But the story
> > currently has major limitations; developers reach a point where they
> > have to make a big switch, learn numerous libraries, and rewrite a lot
> > of their code.  How can we fix that?
> >
> > 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.
> Yikes, I'm about to disagree with Shane [gulp].  And on a point where
> ChrisM agrees with you.
> At this URL (from Jonah's blog post):
>    http://www.bricklin.com/wontprogram.htm
> ...Dan, the co-creator of VisiCalc, argues an interesting point:
>    [after discussing programming as imperative statements,
>    debugging, testing, etc.
>    The question really isn't "Why Johnny can't program" but
>    rather "Why Johnny won't or doesn't choose to program".
> I still don't think scripters and developers are the same people.  I
> won't repeat Dan's arguments here, but I think his essay is a valuable
> read for understanding an audience that isn't like most zope3-dev people.
> I won't belabor the point, as I realize that at least half the folks
> here aren't necessarily against the idea, they're against the mechanical
> problems and the "who's gonna implement it" reality.

And some of us just fear it making our jobs harder. Johnny's not going
to program his own ability to purchase tickets to local club shows.
He's going to want to buy tickets. I need to be able to write and
deliver a solid, high availability,
application that is specialized to this task. Drag and drop and
filling in 'tagged values' isn't going to get things done. Having
scripts and through-the-web editing isn't going to get things done.
Neither are active record based O-R mappers if we stay with our
relational storage - the queries in the consumer side are just too

Actually, I want TTW editing of some sort for the new generation of
this application, but nothing like the way it's done in Zope 2. Not
even close. So even if it was there as an option, it probably wouldn't
do what I want and I'd still have to invent my own.

But anyways, my only objection to a lot of this vision has been: what
about me? I know I'm being awfully selfish. But I've supported and
fought for the "Python Programmers As Primary Initial Audience". Zope
3 does a pretty darn good job as it stands now, but there are still a
lot of headaches and rough edges to rub against. And concepts that
still feel like they took far too long to comprehend, like
Vocabularies (months later, I finally understand them and find them
indispensable, but man! Rough!)

Doing the 'Time Tracker' app wherein it's basic add / edit / list?
There's a hundred options for doing that all automatically. The hard
part comes in totally custom applications, or even partially custom. I
think Rails does things right here: it doesn't generate a complex or
pretty interface, controller, model, whatever for you. It generates
usable structure that makes it pretty obvious how the system works and
where to start building.


There are no leaps one has to make - you just keep on going and
building from there.

Adding zope.formlib to the Zope 3 core was a step in the right
direction, in my opinion. We need more pieces like that (zc.table
looks equally impressive and beneficial). I've been so damn productive
with formlib - more than I've ever been even with Formulator or most
Zope 2 systems. Why has it been productive? Clean API, smart objects,
lots of options and extension points as well as good base classes and
helpers that pull it all together for immediate usability. It's
beneficial to programmers. It has an air of 'scriptability', I guess,
because it offers so many features that makes Form programming
possible with practically zero code, and customization can start with
just a line or two, and full customization with just a few more. 13
lines of Python was all it took to make the server side of an AJAX-y
'in-place' editor, and that included custom traversal. I'll keep
repeating that story because I think that's the one worth repeating.

It's the easy start interface. But it's also the easy-customize one. I
think if zc.table were used too, someone could come up with a better
CRUD application that's flashier and more dedicated than the ZMI, is
less overwhelming than Plone, is easy to generate from a base Schema,
and is easy to start branding to one own's desires and morphing into
one's own application. Add viewlets/content providers on to that and
you could really really have something. Add a TTW management interface
that worked on the viewlet/wrapper level instead of the folder's full
of miserable to edit templates level and you *really* have something.

At least, so thinketh I. At least, for the present late moment.

Jeff Shell
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to