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 -
Cheers,
A
More information about the fluid-work
mailing list