[Grok-dev] Re: on the name "Grok"

[Martijn Faassen]

Philipp von Weitershausen wrote:
> Martijn Faassen wrote:
>> Hi there,
>>
>> Philipp von Weitershausen wrote:
[snip]
>>> I'm against calling it five.grok, to be honest.
>>
>> Why? It aims to provide the same API as Grok, after all.
> 
> Does it? I haven't read its README yet, so I don't know what the 
> intentions of the authors are. Even if those were the goals, I don't see 
> the point of replicating Grok in Zope 2.
> 
> Five in Zope 3 doesn't reimplement all of Zope 3 either. It just 
> provides the most important and commonly used components. Perhaps I'm 
> missing something, but why does five.grok need to do more than Five 
> already does (not counting conventions over configuration, etc.)?

I always saw as the ultimate goal of the Five project the ability to run 
Zope 3 code unchanged in Zope 2. That goal hasn't been reached yet, but 
it's slowly moving forward nonetheless. (__parent__ based acquisition, 
for instance, thanks to you). Eventually I hope you can store a content 
object that's Zope 3 based in a Zope 2 container, and then forget about 
the rest of Zope 2 (except security).

>>>> This is a partial re-implementation of Grok.
>>>
>>> No it isn't. five.grok is not a web framework. It's not integrated in 
>>> any way. You may say I'm splitting hairs here (and you may be right), 
>>> but conceptually I find grok and five.grok quite different. One is a 
>>> framework, one is a library to extend another framework.
>>
>> five.grok is a web development framework.
> 
> Do you consider Five a web framework? I'd say five.grok is whatever Five 
> is. To me, that's an extension to Zope 2.

Yes, an extension to Zope 2, a web development framework, to let you do 
Zope 3 web development frameworky things. :)

[snip]
>> Grok and five.grok allow the developer to do the same thing and aim 
>> for API compatibility: write the same code and have the same thing 
>> appear on their web page. The only difference is the underlying 
>> framework they are integrated with (which is still largely the same, 
>> actually).
> 
> Again, I question both the existence of such goals (API compatibility) 
> and the usefulness. I doubt that much of the community is looking for 
> API compatibility beyond the basic components and views. The rest is 
> Plone-specific stuff, really, which we already agree, shouldn't be 
> called Grok in any way.

Yes, you give the impression you're excluding quite a large bunch of 
stuff, but let's make a list of what the base classes are, right now, in 
Grok:

Model - little use in Zope 2 until Z3 content can be stored (which I see 
as a future goal)
Container - same as for model
Site - should be useful in Zope 2.
Application - should be useful if this can be mixed in with a Zope 
2-based content class
Adapter
GlobalUtility
LocalUtility
MultiAdapter
Annotation
View
XMLRPC
REST
JSON
template language pluggability
resource support ('static')
Traverser, 'traverse' method
Form
AddForm
EditForm
DisplayForm
Indexes - can be used in conjunction with five.intid
Permission - maps to Zope 2 permission
Role - maps to Zope 2 role
grok.require - view level security
IGrokLayer
Skin
RESTProtocol
ViewletManager
Viewlet

I'd say *most* of these look like something that the 'five.grok' project 
should make work in Zope 2. The model and container case don't make 
sense to port right away. The Indexes bit is hard to port, and I expect 
so might be the traverser support, the REST support and XMLRPC support, 
but that doesn't mean they wouldn't be useful to have.

[snip]
> I think the mental work is minimal. Nobody objected when Five (due to a 
> technicality) had to introduce a BrowserView base class. 

True, though base classes don't play a fundamental role in Zope 3 
programming.

> five.grok is in 
> a way a special animal because it brings over some commonly used 
> components to Zope 2. I still don't think that bringing over all of Grok 
> is an important or even sensible goal. Therefore, five.grok will always 
> be just a subset. And to be honest, probably a small subset (I suspect 
> the future plone.grok will most likely be the rising star of Grok 
> technology on Zope 2). But, who am I to predict the future :). Point is, 
> it's not Grok and thus shouldn't trick the developer into thinking 
> everything from Grok is available.

I'd like to you to elaborate on the subset argument, as above.

> Making certain examples work both ways is an admirable goal which I 
> completely support. The mental work translating namespaces is something 
> developers can easily deal with. And if they end up doing it with an 
> "import foo as grok", then so be it.

If that is going to be the common pattern in examples, then I'd say 
let's just make it the default and have them 'from five import grok'. 
I'd actively try to *discourage* any examples that do 'import 
plone.whatever as grok', though. We can make a very strong point that 
this is wrong.

Regards,

Martijn