[Grok-dev] Re: grokcore.view feedback

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
[snip]
> 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.

[snip]
>> 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:

grokcore.component
grokcore.view
grokcore.viewlet
grokcore.formlib

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

Regards,

Martijn