Problems of "Overinjection"

Antranig Michael Basman antranig.basman at Colorado.EDU
Wed Mar 20 12:13:41 UTC 2013

An issue mentioned by Justin in the channel yesterday:

[20:23] <Justin_o> Bosmon8: I'm trying out the code changes now for 
merging gradeNames.. although now if i add the gradeName, my applier 
seems to disappear.. getting an error that it is undefined

I haven't seen the exact code in question, but my guess is that this 
might be caused by injecting an overly-broad reference via IoC into an 
invoker or other material that participates in an early ginger process.

For example, writing

args: "{that}"

and then in

myInvoker = function (that) {
     var applier = that.applier;

runs the risk of observing the applier before it is instantiated.

A better model is to write

args: "{that}.applier"

and then

myInvoker = function (applier)

This was always a good design practice (for good logical design) but is 
now a good physical practice in that it heads off bugs due to observing 
overly-broad references and also reduces the risk of cycles of 
references. We used to work hard to avoid visibility of an entire "that" 
in methods attached to components because it decreases the brittleness 
of design and improves the ability to reason about the behaviour of 
methods - with the FLUID-4330 "ginger world" we now have even stronger 
reasons to inject into methods only those exact references they require 
- and to design them so that the pattern of required references is as 
small and tight as possible.

Apologies if this isn't the cause of this particular problem, but I 
thought it was worth writing up in any case -



More information about the fluid-work mailing list