Hey,
Not much debate from me here on this front, just a lot of agreement.
Ian Bicking wrote:
Martijn Faassen wrote: [...]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.
Do you think domain specific component configuration/glue languages are not right in general, or is it something specific about ZCML in particular?
[...]
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.
Agreed completely, very good point. I harped about this on the Zope 3 list for a while last year.
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.
And where you don't have to say "ooh, this stuff is something you can ignore for now", *and* where you don't have to explain a lot of irrelevant material as well. My favorite example of this is "Hello world" in Python versus "Hello world" in Java. In Java, to new programmers, you'll either have to say "well, ignore this class thingy for now. Just look at the method. Ignore this too. And that", which gives a bad impression of programming. Or alternatively, you'll have to explain it all "well, this is a class, and that's to do with object oriented programming, which is.." which will confuse and overwhelm new programmers entirely.
Zope 3 suffers from the same problem. I think in part this can be solved by writing a good tutorial as you say, and in part we need to ruthlessly eliminate stuff that we otherwise cannot avoid in the tutorial.
The Zope 3 tutorial as written by Jim Fulton is very complete, but is not a good tutorial for beginners in my mind. It introduces functional doctesting using tcpwatch before you write your first adapter, or something...
I attempted to write something like a simple tutorial in the context of Five (Zope 3 in Zope 2). Here they are, in all their magicpoint glory:
http://codespeak.net/svn/z3/Five/trunk/doc/five_interface_tutorial.mgp http://codespeak.net/svn/z3/Five/trunk/doc/five_views_tutorial.mgp
Most of this can be safely translated to Zope 3, which in fact I did in part for a presentation once. It is still too overwhelming perhaps for the amount of stuff you end up doing, which isn't that much.
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 recognize the feeling. Python was liberating after having to mess about with header files in C and C++ for me, and they are slightly similar to ZCML. ZCML and interface files bring the "header file" feeling back to Python, which is not good. Even though I also agree that this kind of dependency really happens all the time, and you can't really expect otherwise in larger systems.
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 ;)
Can't disagree with you there. I don't think a typical user will run into multi-argument adaptation that often though, so I'm not too worried about this.
[snip lots more stuff I can only agree with]
I agree completely! We need to get this clear to the Zope 3 core hackers though, and I'm not exactly sure how to do that. I mean, I'm sure they understand, but I am also fairly certain it's less high on the priority list than I think it should be. Then again, there is only so much energy available to work on Zope 3 in general, so even if it were high on the list, it might still not make fast progress..
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.
Yes, this would be good. It's always been a specific intent of Zope 3, and has been reached in a large part; personally I've been using Zope 3 as a "library" to add some of its facilities to Zope 2 for instance, with quite some success (Five). It needs to be promoted better though, somehow. Zope 3 has a complicated zpackage framework that I don't really like (as I think it's a new wheel that nobody will end up adopting, but I may be wrong), but it's intended to make packaging individual libraries of Zope 3 more easy.
I think another attitude shift related to this that might benefit Zope 3 is to become *far* more happy to just reuse other people's code than it's been historically. The whole idea of "well, it needs to be in ZPL and in our repository for us to use it" has got to go somehow. I can see where it is coming from, as it makes maintenance and testing more easy, but being willing to reuse other projects is the flip side of what you're describing.
Sometimes I feel like all these Python web frameworks are sitting there and say, there are too many frameworks, why don't you all just use *mine*? Never they consider using code written for some other framework. :) I am exaggarating, but not that much.
Zope 3's guilty of that; I did it a bit in my reply to Peter, to try to make a point. :)
To get a cluster of reusable components all these frameworks can start using we need to have two sides:
* more decoupling of the web frameworks, such as Zope 3
* more willingness by the web frameworks to adopt code not in their control
On the good news front, I saw some checkins today indicating Zope 3 is gaining more WSGI capabilities, and even Twisted integration now. That's exactly what we need more of.
Anyway, I'll try to take action myself in Zope 3 land to improve the situation where I can, but I only have so much time and too many things to do. :)
Regards,
Martijn _______________________________________________ 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
