[Grok-dev] Re: five.grok

Martin Aspeli optilude at gmx.net
Thu Jul 31 16:59:12 EDT 2008

Hi Sylvain,

>   five.grok is a bunch of changes for Zope 2, and yes,
> grokcore.{view,component} are dependencies of five.grok.


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

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

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

>> Cool! I'm more interested in a z3c.form version, though. Is anyone 
>> working on that? If not, I would be interested to figure out how to
>> do that.
>   Yes, I am currently trying to do that. We need the support of
> plone.z3cform (it will act like formbase of Five for formlib). I
> discussed of that yesterday with Daniel, and he removed all CMF
> specifics parts from plone.z3cform (I am building it for Silva, and I
> don't want CMF).

I'm involved in plone.z3cform as well, so feel free to include me if you 
want talk about its use cases. My particular use case is Dexterity, 
which uses plone.z3cform to (I hope) simplify making CMF types. So I 
need the CMF stuff, but not too much of it.

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

/me is all excited


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

More information about the Grok-dev mailing list