On Oct 3, 2005, at 11:19 AM, Tim Middleton wrote:
I've done a few Zope 2 projects, and am trying to wrap my head
around Zope 3
now. The style I evolved for putting together Zope 2 applications
have been very orthodox.
Basically I found that I disliked (and mistrusted, maybe because at
I didn't understand the security wrappers very well) calling any
from within ZPTs. Thus my pattern eventually became that all pages
themselves methods of my objects, which would do whatever setup is
necessary, stuff the self.REQUEST object with whatever is required,
method would then return the ZTP object. Something like this...
_page = PageTemplateFile('www/somePage.htm', globals())
"""do whatever is necessary to set up REQUEST then call
It's a fairly straight forward approach really (probably betraying
ugly CGI roots). It may not be the most efficient, but it makes it
explicit for my templates where info is coming from: it *always*
from the method which returns the template before calling the
So, now, Zope 3... somewhat different, to say the least! There is
not 100% enforced, certainly more strongly segregated, "view"
portion of an
app. And perhaps it's time to change.
If you write "big" apps (I'll let you define "big" :-) then probably
so. For small apps I still find it to be a good choice, but YMMV.
Perhaps I have no choice. Perhaps I
have a choice, but it would be just easier (and better) in the long
figure out the more zope3ish ways of doing things.
You do have a choice. The recipes are all going to guide you along
the One True Way of using views, though.
In the maze of interfaces and frighteningly magical zcml glue, I
figure out how to get ahold of the request object outside of a ZPT.
FWIW, we're trying to reduce the "frightening" and "magical" aspect
of the glue. :-) That said, glue still has its place, and I think
zcml is actually working out pretty well overall.
I've looked through bugtracker and a few other bits of code that
slight use of 'self.request', but still can not figure it out (at
everything i have tried has not worked in my tries at it. And many
samples I found seem to get the request via different methods,
which is a
bit confusing. Do I implement, adapt, subclass, call... what? I'm
would be possible for me, eventually, figure out how to perpetuate my
pattern in a zope 3 context... (though the paradigm shift has been
brutally painful so far, and I've barely yet begun) and it would make
porting a whole lot faster... (assuming also i can figure out how
traversal working, or restructure my code so I don't need it...)
So, I understand how you came to your Zope 2 approach. The nice
thing, from your perspective then, is that you could say that Zope 3
agrees with you: it's a lot simpler if you just have some Python to
work with, and you use a template for the stuff that makes sense,
right off your Python view class.
Yes, you ought to divide up your view code and your model code, but
your view class can now have multiple templates attached to it; your
templates can call methods on your view class. It's nice.
Benji York is working on a quick start for Zope 3. He wants to do a
lot more on it, but it already starts from a nice place, I think, and
it might give some examples of what I'm trying to show.
So still, I wonder... how can I get that request object I love so
Do I answer your question, to show it can be done, and that we want
to support practical development, rather than stubbornly insist on
what we believe to be the right way of doing things? I guess so.
But, as the comment says...
# DON'T DO THIS unless you have a real reason to!!
from zope.publisher.interfaces import IRequest
i = zope.security.management.getInteraction() # raises
for p in i.participations:
raise RuntimeError('No IRequest in interaction')
I hope the view classes work out for you. :-)
Zope3-users mailing list