Framework merge: FLUID-4055 branch for GRADES
colinbdclark at gmail.com
Tue Mar 8 20:36:34 UTC 2011
On 2011-03-08, at 12:32 PM, Antranig Basman wrote:
> 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
The second item in your roadmap seems a bit ambitious, unless I'm mistaken. We have a number of users outside of Infusion today who are creating their own custom components and their own demands blocks. These users are, more than likely, not using IoC or Grades (I still want to debate the name, btw).
Wouldn't triggering an error if no grades are supplied cause confusion and backwards compatibility problems for non-IoC users upgrading to 1.5?
Technical Lead, Fluid Project
More information about the fluid-work