[Grok-dev] Re: grokcore.view feedback
Philipp von Weitershausen
philipp at weitershausen.de
Sun Jul 20 05:54:50 EDT 2008
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Martijn Faassen wrote:
>> Introducing IApplication isn't a bad idea by itself, it's just doesn't
>> seem to make much sense in grokcore.view.
>> I don't see why grok.View couldn't be a simple wrapper around
>> grokcore.component.View that simply added the application_url() method
>> and potentially other Grok-only stuff. How useful would
>> application_url() be outside of Grok anyway? grok.Application is a
>> pretty Grok-centric concept right now.
> True, we could do that while still having the grokker and friends in
> grokcore.view. I.e. grokcore.view's View class would work standalone,
> but with Grok we subclass it and add a couple of methods.
>>> grokcore.view also needs documentation like grokcore.component has.
>>> This documentation should describe the two use cases:
>>> * use out of the box by Grok and Zope 3 applications
>>> * reuse of base classes for use in five.grok
>> I don't see why the second point needs to be part of the grokcore.view
>> documentation. It seems to me that this should be part of the
>> five.grok documentation only (since five.grok would expose all of
>> those baseclasses etc. itself anyway...).
> Well, something needs to be stated as a purpose. Currently the *only*
> (non-stated) purpose of grokcore.view is to provide base classes that
> another framework can subclass to expose views. We need to say something
> about that use case at least.
>> As you said yourself, Martijn, grokcore.view *primarily* is for
>> writing Zope 3 views the Grok way. So that's what should be
>> documented. If it happens to be used as a library by some other
>> integration layer, well, that's a different concern.
> I think the use as a library in this way is important to state, as it
> requires a refactoring into base classes that otherwise has no point. If
> we don't state it as a purpose, you and I can come along and say: why
> are all these unnecessary base classes here? Let's flatten them out!
Sure, though I don't think the code has to be arranged around base
classes as much as it currently is. I already refactored the
> [grokcore.view straight-up in Zope 2]
>> I suggested to Godefroid on IRC that we may want to split up the
>> ViewGrokker into a grokker that just did the registration bits and
>> into one that did the security. That way, Zope 2 could reuse the
>> former one but reimplmenet the latter.
> Yes, that sounds like a good idea, I see you already cleaned things up.
Yes, I wanted to bring some of the ftests over so that the use case of
writing pure Zope 3 browser views with grokcore.view.View was covered by
tests. I didn't get that far yet because I decided to clean up things
> Nice also that we don't really need a ViewBase after all. It'd also be
> nice to split out the form grokking stuff from the view grokker finally.
> So, we will eventually have:
> And we also have our eyes on eventually gaining:
> grokcore.security (right now folded into grokcore.view as that's the
> main bit that uses it)
Yep. I think grokcore.security would make a lot of sense, though it
would be very small. It would pretty much only contain Permission, the
corresponding grokker, and helper methods for defining checkers. I don't
think it should contain support for Role (because that's specific to a
particular security policy, as it happens, the one used by Grok).
More information about the Grok-dev