Framework merge: FLUID-4055 branch for GRADES

[Antranig Basman]

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.