[Zope-dev] Michel's Reply

[Michel Pelletier]

Toby Dickenson wrote:
> 

Sorry for the delay (book ... crushing ... head ... )

> Perhaps the hippo analogy isnt helping, so heres a more concrete example. In
> zope today it is possible for a user who has been granted the 'View
> Management Screens' permission in *one* folder to create a one-line dtml
> method that lets him see the management page of any other dtml method in the
> whole site.

Even above where the user is defined?  Are you sure?  That would be a
bug.

Your arguments are all pretty solid, I think we are just looking at
things from different perspectives. 
 
> > > Ive now nearly finished converting all my newbie zope
> > projects back to
> > > a conventional O-O design. I have been bitten by all the problems
> > > listed above. The feed method *should* *be* implemented in
> > a ZooAnimal
> > > base class.
> >
> > Ok, that's a valid approach.
> 
> Can you explain any advantage of the approach you are advocating?

We're working to make Zope usable from the perspective of many
different, possibly non-programming users.  I agree that a feed method
on an animal base class is a good way to do it from the perspective of
an python OO programmer (which you and I are), but people need to be
able to pick up, say, our book, and start creating useful dynamic
content by dropping in objects, scripts, HTML and other stuff they can
grok.  

I agree that this can also be a hinderance, I did some training in
california a few months ago and the company was doing all of their
application in DTML and external Methods and I convinced them (rather
easily because they were all coders) to make a Python product instead.  

Zope's audience can be pictured, like many things, as a bell curve. 
We're (most of us at least) all sittin' up on the top of the hump
looking down.  Understanding the perspective of someone at the bottom
looking up is essential to making sure Zope succeeds.

Python Methods are a perfect example of an object that is useful to us
at the top for advanced things, like methods of a animal base class we
use in our complex Zoo application, but they are also just as useful to
those at the bottom, as a simple little script written in python that
feeds the hippos.  Or unobfusicates their DTML.  Or iterates over a
database query.  It's useful and saves the time of these novice Zope
users if these methods can be flexible and reusable in different
contexts.  To me, this is the heart of the container vs. context binding
argument.  We at the top ususaly want the container because we're
engineering methods on classes.  Those at the bottom usually want
context for entirely different reasons.  Evan has done a great job
making an object that satisfies the entire spectrum, but in the process
has come up with something that is not entirely unlike a method in
python.

I'm not longer arguing or advocating a particular stance on container
vs. context, Evan talked me into the legitimacy of both approaches. 
Right now, I'm arguing that we need a name that makes sense to
everybody.  'Method' makes sense to us at the top, but not to those on
the bottom, and there are a lot more of those people than us.

-Michel