Thomas G. Willis wrote:
> I was kind of expecting that the book would have some gaps as far as bfg
> goes. I was hoping that going through the exercise of struggling through
> those gaps would help me arrive at a better understanding of all things
> zope(a lofty goal I'm sure).
I guess what I was saying that BFG is more "inspired by" Zope than
actually based on it. It does use a number of low-level Zope packages,
but it doesn't try to be consistent with "Zopeish" ways of doing things.
One good example is the way that views work. In Zope, you register a
view factory (usually a class). The publisher will invoke the factory,
and then call the result (usually). Therefore, a basic view is a class
that takes two parameters in __init__, the context and the request, and
has a __call__ method that returns a string (or renders a template).
In BFG, a view is a method that gets called, i.e. the factory bit is
lost. If that's good or bad probably depends on your point of view. It's
certainly simpler. ;)
> thanks so much for the info. I'll check out z3c.form.
> But if I understand what you are saying about the request needing to be
> marked with the IFormLayer interface, I would assume an adapter could be
> configured to provide that. I'll try that first anyway.
I can tell you how to do it in Plone. ;-)
I'm sure repoze.bfg has a simple way to hook in an event handler to do
this. You basically want:
from zope.interface import alsoProvides
from z3c.form.interfaces import IFormLayer
The question is where the request comes from, and what kind of an object
it is. A Zope 3 request (from the zope.publisher package) is different
from a BFG request, as far as I understand. So, it may be that z3c.form
would require some kind of a "zopeish" request adapter to even work.
The same would be true of zope.formlib, of course. I suspect you may be
the first person to try this, though. If you're also just learning, then
maybe that's making life very hard for yourself.
My advice would be to read Philipp's book because it's very good and
will teach you a bunch of stuff about Zope. If you like the way it
works, take a look also at grok.zope.org, which uses all the Zope stuff
underneath but aims to make it easier to get started through
At the same time (or before or after) read the bfg docs on
bfg.repoze.org. They're very good too. But I'd maybe try to keep
repoze.bfg and "Zope" (at least as far as Philipp's book goes) separate
in your mind until you become more proficient with both and understand
them well enough to be able to help integrate Zope technologies into BFG
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Repoze-dev mailing list