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

[Martijn Faassen]

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)

    @grok.action("Submit")
    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)

    @grok.action("Add")
    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 
megrok.rdf).

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

Regards,

Martijn