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 alsoProvides(request, 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 convention-over-configuration. 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 or vice-a-versa. Martin -- 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
