On 08/03/2011 06:18, Justin Obara wrote:
Hey Antranig,
This looks really nice, and I can't wait to start using it. Looking forward to learning more about it. In advance of the dev meeting anddocumentation, here are my first two questions. 1) Since the grading is specified in the defaults, does that
mean that an integrator
will be able to change the grading, and wouldn't this potentially lead to issues if the expected grade
doesn't match the supplied one? 2) What is a case where you wouldn't want to use "autoinit"? Is this just
for backwards compatability? What would happen if you didn't use "autoinit" and supplied an incompatible
creator function?
Sorry, that was more than two questions.
Thanks
Justin
Thanks for these questions, Justin, which I think are great questions - and which relate to material that I
wanted to address anyway but left out of my original posting for reasons of length :)
i) Yes, it would indeed be hazardous for a user to be able to override the grade names (or at least, some of
the configuration derived from grade names, such as signatures and argument maps) and this places them in a
wider context of "inviolable options" that we had already accumulated - for example, overriding elements of
the "events" structure could probably only lead to breakage of the component (although with "event
injection" this would now no longer perfectly clear - it might be a reasonable choice for a user to replace
an event which had been defined inline in the component with a compatible one that had been injected from
elsewhere in the tree). But certainly this points the way to a *further* configuration related to
"inviolable options" which should, presumably, ALSO be supplied as part of the graded configuration. For
example it should be considered impermissible to override options such as - argumentMap, gradeNames,
mergePolicy, and of course, the "inviolable" list of options itself by means of configuration supplied
directly by the user. I'll put in a system like this in before 1.4
ii) In theory, yes, we simply want to make "autoInit" the default at some ultimate point in the future.
Allowing framework users to write their own creator functions seemed like a useful concession of control at
the outset, but now the IoC framework is maturing, it is creating a fragile point in the architecture. In
particular there is a quite serious risk of corruption in the component tree now, should the author of a
component creator function not proceed to IMMEDIATELY construct the expected component but instead perform
some unrelated activity, construct a non-component, or construct a component which is not the one related to
the current construction. However we have so much "manual construction code" (in fact - a 100% set since
before "autoInit" there was no other option) that we will have to put off a full migration over several
release cycles. Here was a draft roadmap I was wanting to propose, which we should discuss amongst other
roadmap issues at the dev meeting:
1.4: Every "defaults" block issued in framework code is supplied with a grade
1.5: A call to "defaults" triggers an error if no grades are supplied, by any
client code
2.0: All code migrated to "autoInit" construction form
iii) If you don't use autoInit and supply a creator function incompatible with the supplied argument map,
there is a risk of the component being incorrectly initialised when it occurs in some IoC contexts. This
risk isn't any greater than it was before - in the past, any function with a non-standard signature needed
an explicit demands block supplied in order to explain to the IoC framework how to invoke it. Any function
without a demands blocks was usually inferred to be a "little component" (whether it was or not) or perhaps
an "arguments pass-through" in the case of an invoker. Another case where in the absence of grade
information there is risk of corruption is the case of a "fluid component invoked as renderer decorator",
where the framework simply assumes the component to have the view component signature, whether it has or
not. This is a more serious problem than the previous case since it is impossible to write an appropriately
scoped demands block which solves the incompatibility. This case was also not possible before the FLUID-4106
implementation.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
