[Grok-dev] solving the grok.template() bug - part A of the solution
faassen at startifact.com
Mon Jan 12 17:28:55 EST 2009
Jan-Wijbrand Kolman wrote:
> On Mon, Jan 12, 2009 at 5:38 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> 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.
More information about the Grok-dev