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

[Jan-Wijbrand Kolman]

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.

snip
> I hope I got the rule right this time, whenever JW and I talk about it
> we both get confused. :) Note that the rule above suggests some way to
> hook in the grok.context behavior into the process, which is nice.
>
> Now if we dropped the grok.context auto-association rule and we dropped
> module-level directives, it'd become much simpler to implement everything:
>
> * just get the value from the class.
>
> I think that's too big a change to drop on people though. Besides, I do
> use auto-association and module-level directives quite frequently in my
> code and they're quite nice to have and I don't think usually make
> things much harder to read either.

I agree module level directives are useful.

On the implicit part (in case of auto-associating templates or
contexts for example) however, I am more and more convinced that the
"cost" of explicitly typing a directive a few times extra, has a big
big benefit: when reading the code (and we all agree code is far more
often read than written) it is self explanatory, the information is
right there[1].

And as a result, while reading someone else's code, besides
understanding its intention I do not also have to remember and
interpret  a rule for implicit information. It also makes explaining
how things work (to newcomers for example) easier, since there're less
rules to explain.

As an example, I have been bitten more than once - and it that sense
my experience is exactly opposite from yours I guess - by an
incorrectly implicitly associated template to a view, where my only
solution now is to having to rename either the view class or the
template - which as I see it is countering symptoms.

My opinion on this matter is getting stronger over time as you might
notice. I really think grok should do without the implicit rules,
making both the implementation and its use simpler[2].


kind regards,
jw
-- 
Jan-Wijbrand Kolman


[1] Note that I'm not against the default values that are in effect
when a directive is not used on a component!

[2] Luckily, the situations wherein implicitly derived information
actually conflicts with explicitely defined information are rare and
in almost all cases can, some way or another, be overcome. So, I can
happily continue using grok directives explicitly and encourage my
co-workers to do the same :-)