[Grok-dev] Re: A plan for removing the fields inner class support

Martijn Faassen faassen at startifact.com
Thu Sep 13 05:28:22 EDT 2007

Luciano Ramalho wrote:
> OK, things are not going to be as simple as I described...
> The ModelGrok.grok method can't be simply removed, even though the
> only thing it does is what we don't want it do do anymore.
> class ModelGrokker(martian.ClassGrokker):
>     component_class = grok.Model
>     def grok(self, name, factory, context, module_info, templates):
>         for field in formlib.get_context_schema_fields(factory):
>             setattr(factory, field.__name__, field.default)
>         return True
> The reason is that martian.ComponentGrokkerBase.grok raises
> NotImplementedError, and ModelGrokker is the first
> ComponentGrokkerBase subclass that actually does implement the grok
> method.

I don't understand this bit. Why is there a problem with this 
NotImplementedError? Looking at the code, it looks to me like we could 
remove ModelGrokker and everything that derives from it 
(ContainerGrokker, LocalUtilityGrokker).

> Then I started reading some of the tests which use the fields inner
> class, and realized we may want the ModelGrokker to do something for
> us after all.
> What if the ModelGrokker created attributes in our model class from
> the attributes declared in an interface which our model promises to
> implement?

-1. I think this is too much magic. We thought it was a good idea at the 
time, but the less-magic way (using applyData() on forms) works fine in 
practice. If any tests are in the way and would really serve no function 
anymore when rewritten to use schemas, feel free to remove them.



More information about the Grok-dev mailing list