Hi Antranig, 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? Colin --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
