[Grok-dev] Re: five.grok

[Godefroid Chapelle]

Sylvain Viollon wrote:
> On Thu, 31 Jul 2008 21:59:12 +0100
> Martin Aspeli <optilude at gmx.net> wrote:
> 
>> Hi Sylvain,
>>
> 
>   Hello,
> 
> [...]
> 
>>>> Would it work to use the context() and name() directives from 
>>>> grokcore.view instead of five.grok?
>>>>
>>>   Yes, they are just imported in five.grok, if I remember correctly.
>>> It's just that's better to have one import instead of two.
>> Except that it makes existing documentation/examples that use 
>> grokcore.view seem to not apply when in fact they do.
>>
> 
>   Well, you have to change an import. The common fact is that in grok,
> you don't import things from grokcore.component, or grokcore.views and
> so on, you just import things from grok:
> 
>     import grok
> 
>     grok.require(...)
> 
>   So in Zope 2, your import will be:
> 
>     from five import grok
> 
>     grok.require(...)
> 
>   Grokcore packages are just parts of grok implementation, which can be
> used in other context than grok itself, like to build grok in Zope 2.
> So I think documentation are preserved, you just have your first import
> which is different.
> 
>   But recently a lot of work have been done on grokcore packages, and
> not everything from grokcore packages are imported in five.grok like
> in grok, I think.
> 
> 
>>>   I think in grok documentation. 
>> I did look for a canonical "how templates and views and forms work" 
>> document, but found only the general tutorial. I may've missed 
>> something, though.
>>
> 
>   I never look at the grok documentation, but you don't have anything
> new if you compare to the Zope 3 way of doing things. That's just you
> don't have to register explicitly everything.
> 
>>> The rule is unless you used the
>>> templatedir directive in module to configure a different template
>>> directory, if a view don't define a render method, a template named
>>> with the name of your view class in lower case is search in a
>>> directory which have the same name than your python module (in
>>> lower case as well I think).
>> Cool. I can't wait to try this out. :)
>>
>>>   So if your view is in wheremyviewis.py, the template
>>> wheremyviewis/myview.pt is going to be used if you remove the render
>>> method above.
>> And what about the template directory stuff? Is that explicit, or
>> does viewname_templates work always?
>>
> 
>   Yes, it's wheremyviewis_templates/myview.pt, not the first I gave (I
> forgot the _templates), unless you specified an another directory with
> grokcore.view.templatedir in your module.
> 
> 
> [...]
> 
>>>   Basically, we have to build a grokker which create the form_fields
>>> attribute like for formlib, wrap actions ... We will have to
>>> register the form to the ZCA as view wrapped with the form_wrapper
>>> provided in plone.z3cform.
>> Right. Please let's talk about this. I need this exact same thing for 
>> Dexterity, with support for add and edit forms (as well as standalone 
>> form views, but that's not really specific to Dexterity). I think 
>> plone.z3cform would be a natural place to keep the grokking code.
>>
> 
>   If you add the grokking code to plone.z3cform, this going to mean
> that's everybody who want to use z3c.form in Zope 2 will have to either
> use Grok, or if they don't work, rebuild their own support. I will
> prefer to have a five.grok.z3cform, which depends on plone.z3cform.
> 
>   I may have some time to work on that today, or at the beginning of
> next week.
> 
>   Sylvain,

I am a bit skeptical about importing everything from grok.

I think it is better to see what is coming from where !

However, I understand others might like to use "from five import grok"

iow, can we keep code like below working ?

import grokcore.component
import grokcore.view
import grokcore.security

class Branch(grokcore.component.Context):
     pass

class Clean(grokcore.view.View):
     grokcore.component.context(Branch)
     grokcore.security.require('zope.View')

(or sthing similar, code above not tested)

Further, as you might see above, I would not import five at all !

I think the grokkers can do the work to include the right base classes 
for Zope 2.

What I mean is that by configuring its own grokkers instead of Grok 
grokkers, five.grok can do the specific Z2 work.

IOW, I think code written with grok might be kept clean and compatible 
with both Z2 and Z3 (without "try except ImportError").

Can you keep that in mind while doing the z3c.form integration ?

PS I'll be away from keyboard from tomorrow until August 15th included.

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be