[Grok-dev] Re: grokcore.view feedback
faassen at startifact.com
Sun Jul 20 03:09:27 EDT 2008
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!
[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.
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)
It's pretty cool Grok's spinning off libraries like this. :)
More information about the Grok-dev