Martijn Faassen wrote: [...]
It's obvious from this that Zope 3 doesn't seem to be accessible to Python programmers as it's supposed to be. I think that's only minimally a technical issue, largely a documentation and presentation issue, and in part I think a historical baggage issue.
One issue seems to be that Python programmers are automatically allergic to domain specific glue languages like ZCML, especially when they look like XML. I think this attitude is not really reasonable, but it's extremely widespread. Jim Fulton looked into a Zope 3 based bobo a while back; something I haven't studied, but might be a way to avoid ZCML for some projects.
In my gut -- and I don't think I'm alone -- ZCML doesn't feel right to me. It's quite literally a gut feeling, or maybe you could call it a code smell, it just doesn't smell right to me. Experience might or might not change that feeling, but it's there nonetheless.
[...]
This:
http://svn.zope.org/Zope3/trunk/src/zope/app/demo/hellopackage/
is a documented hello world package in Zope 3 by the way. It creates a persistent hello world object that can be added through the Zope 3 UI, with a page template and the like. It's too verbose as a minimal case; dumping the UI requirement and some stylistic issues could cut it down a bit more. If you were to add 'hello world' as a template to an existing object, it'd be a lot simpler still (cutting away all Python code and just leaving a ZCML snippet to hook up the template, and the template itself).
Looking just very briefly, I think the issue is one of approachability and incremental learning. There's some big concepts there, and it's unclear where to start. Interfaces, adaptation, ZCML, ZPT... they are all somewhat foreign, at least to the typical Python programmer. I think Jeffrey Shell has been trying to create a more linear tutorial with a to-do list, which is probably a good idea.
A good tutorial -- challenging to make, to be sure -- is one where each step seems clear, relevent to previous steps, and creates something usable. I think this is really where my gut feeling about ZCML comes from -- it's intimately tied to other pieces of the code, and often is a prerequesite to making that code functional (at least functional with respect to its real intention, which is usable in a Zope context), and separate files that have to be subtley in sync always makes me uncomfortable. Of course, that kind of dependency happens all the time, and in an interconnected system you can't expect otherwise. But I won't try to make it an entirely rational argument, that's not actually where my uncomfortable feeling is coming from.
I also think some concepts are being overused in Zope 3. Adaptation, specifically -- multi-argument Adapters break my understanding of what Adaptation is supposed to be, and I think they are being used for all sorts of clever, useful things, where "clever" is meant as a pejorative ;)
It's not monkey-level yet. I think the framework is clean enough to get there. I think it's very important to reach monkey-level.
I think monkey-level means you start with the most obvious thing that people understand. I *think* that is HTML, and imperative form- and link-based interaction (though it could be argued that for different audiences this isn't the most obvious place to start). The first thing I see in Zope 3 tends to be objects and interfaces. Maybe this is because Zope 3 seems sexy and interesting when you start from this direction -- you can do exciting things quickly that way -- and people want to show that off. But exciting isn't accessible, and maybe that's a problem.
Why don't you hop on over and talk to the Zope 3 developers to try to improve this? Are you sure you're truly dealing with something horribly overengineered here, something that could not be improved at all? I.e, were you actually serious when you said this?
> I really want to be able to say that we should all come together to > improve Zope, the "king" of Python web frameworks
... for you seem to have discarded Zope 3 so easily. No questions on a Zope 3 mailing list that I can find, for instance...
Well, I'm not Peter, so you can't call me out about getting involved in Zope 3 since I've made no suggestion I've wanted to ;) But nevertheless, I am interested on some level -- I think there's substantial middle ground where Zope 3 and other Python web projects can come together.
On some level Jim's bobo experiments might be this kind of direction, though as just experiments it's hard to say where that might go. A more decoupled Zope 3 might be both more accessible and more flexible. By "decoupled" I don't necessarily mean code changes -- I don't know the details, but I get the impression that what I'm thinking about might be possible right now, that there's been a lot of work to keep Zope 3 decoupled in light of the coupling problems in Zope 2. It's more a matter of perspective, documentation, and packaging. I suspect this would process would be useful inside Zope as well -- for instance, I think there are users that don't want to use the ZODB at all with Zope 3, but right now there's some trivial dependencies on it (like the root object has to be in the ZODB or something). If Zope 3 was factored into separate pieces -- traversal, introspection, ZMI, etc. -- it could be both more usable outside of Zope 3 (allowed for incremental adoption), and more usable inside of Zope 3 for people with specific needs or desires.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
