[Grok-dev] solving the grok.template() bug - part A of the solution

[Martijn Faassen]

Jan-Wijbrand Kolman wrote:
> On Mon, Jan 12, 2009 at 5:38 PM, Martijn Faassen <faassen at startifact.com> wrote:
> snip
>> A good question to ask is why is rule 3) not below rule 4), instead of
>> after 2)? I think conceptually the automatic association to a IContext
>> should be read as implicitly defining a module-level grok.context. The
>> result of this is that a subclass of a view in a module with just one
>> model will automatically associate with *that* model. This is preferred
>> to associating with the model that the base-view was associated with.
> 
> I do not agree this would be preferred, but that's mainly because of
> the implicit part - see below.
> 
> The situation that could quite easily happen is, if you have
> subclassed a view (e.g. to inject a different template on a different
> layer) and by simply adding a quite possibly unrelated context class
> in the module (that quite possibly has its own set of views) you break
> your application.

That's true; if we put rule 3) below rule 4) you'd likely get less 
unexpected behavior. Too bad, the hook seemed elegant in rule 2), but 
perhaps we can come up with an elegant hook nonetheless.

We could consider giving up rule 3) altogether as "too magic" and 
requiring everyone to spell out grok.context() on the module-level at 
the least. That's not a very onerous requirement. Perhaps we need a 
design rule that a directive default can be either a fixed value, or a 
value based on properties of the class it is used on, but cannot be 
dependent on other things in the module. grok.context would violate that 
rule, but I cannot think of other directives that do.

We'd need to widely discuss this with the community though before making 
any such move.

Regards,

Martijn