[Web-SIG] Re: Just lost another one to Rails

[Ian Bicking]

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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org