[Grok-dev] Re: grokcore.view feedback

[Philipp von Weitershausen]

Martijn Faassen wrote:
> 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.

Exactly.

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

Sure.

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

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

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

Yes.

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

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