[Grok-dev] Re: Grok patterns for content types

Martijn Faassen faassen at startifact.com
Thu Jul 17 15:09:05 EDT 2008

Hey Martin,

Thanks for the questions, sorry it took a few days to answer.

Martin Aspeli wrote:
> I'm interested in experimenting with Grok-like patterns in Zope 2 and 
> Plone. In particular, I want to try to make it possible to build a 
> content type from a schema interface, a class for the persistent object, 
> a default view, and edit form and an add form.
> What is the current "canonical" pattern for this in Grok? I have skimmed 
> some of the documentation, but I'd quite like to see an example or have 
> it spelled out, just so that I don't end up making incorrect assumptions.
> How does Grok deal with add- and edit- forms? Is there a standard way to 
> do "configure-and-create" add forms without having to duplicate an edit 
> form?

I'm not sure what you mean about duplicating an edit form with add forms.

The default in Grok is pretty minimal already:

class Edit(grok.EditForm):
    form_fields = grok.Fields(ISomeInterface)

    def handle(self, **kw):
        self.applyData(self.context, **kw)

this will work on a context that doesn't have much logic of its own. Add 
forms are similar.

an add form would typically be a view for a container:

class Add(grok.EditForm)
    form_fields = grok.Fields(ISomeInterface)

    def handle(self, **kw):
        self.context['name'] = obj = Object()
        self.applyData(obj, **kw)

This is so minimal it doesn't really feel very much like duplication...

If you want to do higher-level approaches where add and edit forms 
automatically exist for some content object just supplying the schema, 
we don't really have this yet. This would be part of the hoped-for crud 
in Grok project.

 > Finally, I'm curious about how Grok implements the logic that says a
 > view defined in the same module as a content type/model class defaults
 > to being a view for that content type, and a template with the same name
 > as the view ends up being the template for that view.
 > Is there some standard support for this in martian or grokcore.component?

Yes, it's in grokcore.component now, we factored it out in the 
Grokkerdam sprint to support things like megrok.rdb (and hopefully soon 

If you want to create a new model object that views auto-associate with 
and the like, you should implement grokcore.component.interfaces.IContext.

Making this work for containers still currently requires the Grok core 
however (grok.interfaces.IContainer). The only thing different for 
containers if I recall correctly is setting up different traversers, 



More information about the Grok-dev mailing list