[Grok-dev] Re: grokcore.view feedback

[Philipp von Weitershausen]

Martijn Faassen wrote:
a lot of stuff that I agree with, especially prioritizing Zope 3 support

> * application_url is the hardest to support cleanly. It presupposes a 
> knowledge of grok.Application that grokcore.view shouldn't really have. 
> I think we should just bite the bullet and move at least the 
> IApplication interface over into grokcore.view, and make application_url 
> check for IApplication instead of isinstance on grok.Application directly.

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.

> When this package is used in a Zope 3 context (such as with Grok), 
> depending on grokcore.view should just make the regular grok.View and 
> grok.*Form available to the programmer, just like grokcore.component 
> makes grok.Adapter and so on available.

Yes. In particular, grokcore.view needs a bunch of Zope 3-based ftests 
that make sure that views written with grokcore.view are absolutely 
equivalent to the ones registered with browser:page.

> Alternatively, we could explore expanding the functionality of the 
> 'grok' directive to allow the grokking of individual classes in a 
> module, though that will be harder to implement as some grokkers expect 
> global grokkers to have done their work.
> 
> 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...).

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.

> We can more cleanly support these two use cases from an import 
> perspective as well. What about making __init__.py only expose those 
> things that Grok itself exposes concerning views, and introducing a 
> grokcore.view.base that exposes those things reusable as base classes or 
> are needed in the implementation of sub classes?
> 
> Finally, hopefully in time we can just make grok.View and friends work 
> straight-up in Zope 2, simplifying grokcore.view again. Not today, however.

I think the Zope 2 trunk is pretty much there yet, minus security. 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.

> Thanks for all the work. I hope this feedback is not too intimidating. 
> I'm trying to make sure that grokcore.view is the best it can be.

+1 me too :)