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, doesn't-charge-the-credit-card-three-times-due-to-conflict-errors 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 complex. 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. http://www.loudthinking.com/arc/000533.html 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 Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com