Infusion 1.5 Documentation Changes
This page contains notes on API changes, new function, etc. that need to be added/updated in the documentation before 1.5 is released. Please add to and edit this page as necessary.
Documentation edits for 1.5 will be made in the latest documentation space: Infusion Documentation.
A 
indicates that a change has already been reflected in the docs.
Framework
- "autoInit" should always be used
- avoid using init functions wherever possible
- avoid using demands blocks where the use of dynamic grades will do - basic facility described in http://issues.fluidproject.org/browse/FLUID-4916, however as well as this elaborate case, we now also support the use of gradeNames supplied straightforwardly as direct options to the component - whether delivered in the subcomponent record, demands blocks, or "Skywalker Options", and are discovering that this is generally a much more straightforward and readable way of enabling adaptation in almost all cases. It has better "community properties" since the actions of "1st parties" and "3rd parties" now seem identical - they simply write some grades. Demands blocks "were" less symmetric since the integrator in general does something different to the original author. We will not remove or deprecate demands blocks but it seems quite likely that their uses will increasingly be reserved for "integration emergencies" and for reconfiguring invokers for which they remain the main mechanism.
- Major new framework features for 1.5/1.9 are the "globally ginger world" described by http://issues.fluidproject.org/browse/FLUID-4330 - it is hard to provide "API docs" for this feature since it introduces no API calls or even new kinds of recognised configuration - it simply causes vastly more kinds of IoC references to be safely resolvable without causing a circularity failure than before. With FLUID-4330 we may resolve arbitrarily many references back to the same component from itself, or return to the same component after resolving references through other components in a cycle, so long as we do not return to exactly the same component option as part of the cycle. This facility is key to removing the use of "init functions" and manual component lifecycles, since we no longer need to rely on manually defined lifecycle points in a component's instantiation process - the framework schedules all points in the lifecycle automatically as required by the dependency structure of the component tree's options.
- "IoCSS expression" aka "Luke Skywalker Options" described in http://issues.fluidproject.org/browse/FLUID-4873 - this is a complementary feature to our existing context resolution as seen in our contextualised EL expressions and demands blocks, where a context name resolved UP the tree as seen in the diagrams seen in Demand Resolution, we now have the ability to write "selectors", modelled on the HTML CSS syntax, which allow us to specify the matching of one or more components DOWN a component tree. Right now, we distinguish the two types of "selectors" since downward selectors (IoCSS) contain whitespace, whereas the downward selectors don't. The main use of these selectors right now is in "Luke Skywalker Blocks" named "distributeOptions" which allow component options material to be broadcast arbitrarily up and down the component tree. This is crucial to creating fictions that "one component is many components" or that "many components are one component" necessary to creating stable APIs to users and users of integrators etc. that are unaffected by the real layout and refactoring of component trees under the covers etc.
Useful test case demonstrating how "distributeOptions" works together smoothly with dynamic grades etc: https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/framework-tests/core/js/FluidIoCTests.js#L2506-L2565 (begins with text /* FLUID-5014 Case 1 - IoCSS: one source value gets passed down to several subcomponents */ ) - dynamic components described in http://issues.fluidproject.org/browse/FLUID-5022 - this system will eventually be used to abolish the "Fluid Renderer" from the visible API of Infusion, leaving behind only direct uses of the IoC configuration and its grades. Right now this system is used as a replacement for the few places in user code where a call to "fluid.initDependent" is still necessary where component definitions can't be known in advance.
- in general, the movement is towards the disuse of APIs and direct function calls into the framework - whilst many of these utilities will still continue to exist, to Fluid 2.0 and beyond we plan to withdraw them as part of the publically supported API of Infusion, including calls such as "initLittleComponent", "initView", "initSubcomponents", "initDependents", "initDependent", the use of manual lifecycle points etc.