Martin Aspeli wrote:
> 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.

That's about right.

> 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. ;)

This is a bit off topic, but BFG actually also supports the "view as a class" 
view construction form, ala Zope:

The form is overkill for lots of common things, so we also support the notion 
that a view can also just be a callable.

>> 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)

You could try to mess around with an INewRequest event subscriber, ala:

> 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.

Figuring out the real difference here would be 99% of the work in making it 
work, I imagine.

> 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, 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 
> 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.

Repoze-dev mailing list

Reply via email to