[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.
Regards,
Martijn
More information about the Grok-dev
mailing list