Summary of "Framework Futures" meeting recommendations

[Antranig Basman]

We had an interesting community meeting this afternoon, as well as some excellent suggestions on possible 
uses of the new framework from the team. I wanted to summarise some of the more important recommendations 
which we should start adopting:

i) Every component written from now on should have "autoInit" applied - and we be making a continuous effort 
from now on to upgrade all old code to this standard. I demonstrated in the meeting the new implementation 
of the ProgressiveEnhancer which uses the new "dynamic grades" facility in order to obtain a standard 
workflow. This is believed to represent the most difficult of the cases we have in the framework - if anyone 
discovers a component which seems problematic to implement as "autoInit" they should report this 
immediately. There should be no further manual calls to lifecycle functions such as "initView", 
"initLittleComponents", "initDependents" etc.

ii) With the improved power of invokers and expander blocks, we should now be making strong efforts to 
eliminate all code written INSIDE lifecycle "init" functions (e.g. preInit, postInit, finalInit, etc.), 
which had become for a while our recommendation for "semi-modern" initialisation code. Because some areas of 
the framework are still incomplete, we can't yet succeed in this completely, but we should expect to be able 
to shed, say, 50% of the material we had, especially with the aid of the new "members" directive 
(FLUID-4918). The two main causes we expect for "unexplained" material remaining in init functions should be:

- a) Binding onto changeListeners and dealing with changeAppliers in general. This part of the framework is 
still very ancient and still has no standard for encoding in a declarative form. This will be pursued as 
part of the work package relating to the "new Renderer" which will follow upgrading the existing 
RendererComponent grade to current framework standards.
   b) Material which should be explained in terms of improved versions of the "visibility model" grade which 
Cindy has worked on for the VideoPlayer - that is, code which maps some aspect of appearance of DOM elements 
based on contents of the component's model. Part of these responsibilities will also lie with the "new 
Renderer".

If anyone finds any material inside an initFunction which they're unable to eliminate or explain in terms of 
a) or b) above, they should also report this immediately. The existing lifecycle functions will remain 
available for a few more framework releases, and can continue to be used with the same expectations on 
initialisation state of the component, but we expect to be able to reduce their contents down to nothing 
over the next few releases and eventually deprecate them properly. The absence of "autoInit" should be 
considered deprecated immediately.


Cheers,
A