[Grok-dev] changing martian to support class decorators

[Martijn Faassen]

On 03/21/2011 09:26 PM, Martin Aspeli wrote:
[snip]
>> module_config = grok.module_config(
>>     grok.context(Foo),
>>     )
>
> +0 - what's the module_config variable for?

It's because we don't have frames to poke into the module from function 
calls anymore. So we have to set information on the module some way, and 
the typical way is assignment.

>> or maybe this:
>>
>> @grok.context(Foo)
>> class ModuleConfig(object):
>>     pass
>
> -1 -- I really don't like the idea of classes used just for
> configuration with no body or Python implementation logic. It feels
> like language abuse.

It's not pretty, but we need something to do module level directives, 
and this is one alternative to explore.

> For the same reason, I prefer ZCML for defining
> permissions and resource directories instead of "faux" classes like
> grok.Permission and grok.ResourceDirectory.
>
> It may be worth looking at the pattern that Google Guice uses:
> basically the template method pattern. It may look like:
>
> class ModuleConfig(grok.Config):
>
>      def configure(self):
>          this.setDefaultContext(IFoo)
            ...

We want to reuse the directives somehow to set the defaults for 
directives, not introduce a new set of methods just to set defaults. So 
how do we do this? Any more suggestions beyond the ones I listed?

>> Yet another approach would be to expose *two* sets of directives per
>> grokcore package, one old-style, the other new-style. But
>> 'grok.context()' reads so nicely I don't want to give it up...
>
> I think people would get very confused by this and we'd end up with mismatches.

Unfortunately I don't have a solution yet to do it in another way so 
that it's backwards compatible, so it's going to be interesting.

I guess one way to deal with this issue is to grok the classes first, 
*then* read the directives on the classes and set them up. This is going 
to lead to interesting consequences for inheritance however, as base 
classes might use directives but not be grokked.

Regards,

Martijn