Framework merge: FLUID-4055 branch for GRADES

Antranig Basman antranig.basman at
Tue Mar 8 10:31:15 UTC 2011

I have just now merged in my branch labelled "FLUID-4055" into trunk - this was forked off before the 
Infusion 1.3.1 release to comprise a number of changes to the framework (both to the core as well as IoC and 
the Renderer) that it was decided best not to disturb the release process with. Some of this implementation 
is even considerably older, taken from the FLUID-3681 SVN branch which was created during the halcyon days 
of Fluid Engage, in fact predating the IoC implementation itself.
A few of these changes are quite fundamental, and whilst they should not break existing code, do create new 
recommendations for the creation of new code. The most important is the introduction of a basic new 
framework facility for what has come to be called "grades". One way to think of grades is that they fulfil 
some of the roles that "types" would fill in our framework - if we had any - which we don't. A more accurate 
and basic way to think about grades is that a "grade" is a name for a particular block of material which is 
supplied to fluid.defaults, which should be merged in BEFORE (that is - with LOWER priority than) the 
creator-specific block of defaults registered for a particular component. This is in fact the complete sum 
total of effects for "grades" - they have no particular runtime effect on the behaviour of a component - but 
they do enable a lot of construction-time effects to occur more reliably and readably.

There will be a full set of documentation forthcoming for grades for the 1.4 release, but for now here is a 
short sample of grade-enabled code taken from the test cases:

         fluid.defaults("fluid.tests.paychequeComponent", {
             gradeNames: ["fluid.viewComponent", "autoInit"],
             selectors: {
                 child: ".flc-renderUtils-test"
             components: {
                 renderChild: {
                     type: "fluid.tests.paychequeRenderer",
                     container: "{paychequeComponent}.dom.child"

This demonstrates a few new effects - firstly, the with the "autoInit" grade, the component's actual creator 
function need not be written at all - it will be automatically inferred from the graded material. Secondly, 
a new directive "container" is available inside the subcomponent block for "renderChild" - this used to 
require a specific demands block to resolve but may now more readably be written inline.

As another change, a few kinds of material that were available within IoC configuration blocks have been 
renamed (the old forms are still retained for backwards compatibility) -
fluid.COMPONENT_OPTIONS is now written as the context EL path {options}
@1, @2, @3 ... etc as argument references are now written as context EL paths {arguments}.1, {arguments}.2 etc.

A number of new other facilities, for example, the use of a new kind of component called an "instantiator" 
to allow IoC-derived configuration to be applied at times later than the overall construction time of the 
tree, have been provided, which need not disturb basic users of the framework. More discussion and 
documentation to come. A list (not complete) of the JIRAs which have been addressed in this branch as well 
as the headline issue is:

FLUID-4055: Deferred instantiation of IoC material using "instantiator"
FLUID-3681: Implementation of "grades"
FLUID-4039: Implement "resolvers" allows generalised "direct models" ("queries") - provides "trundlers"
FLUID-4106: IoC enabled decorators now usable with the Fluid renderer
FLUID-4129: Correction to allow generalised application of "noexpand" mergePolicy
FLUID-4130: Additional "merge paths" for component options can be specified from arbitrary IoC locations
FLUID-3905: Delinting has been applied for Fluid.js, FluidRenderer.js, FluidParser.js using new jslint impl
FLUID-4034: Fix to original implementation of "conditional expander" managing conditional within repetition

These changes are being merged in "slightly early" to make sure we get as much time as possible to assess 
their impact before the 1.4 release. The test cases seem to be working but please be on the lookout for any 
odd behaviour that looks like it may have been caused by these changes. More discussion at the dev meeting 
on Wednesday. The naming and API for these changes is not final, and there are a few more changes related to 
this work that are expected before the final 1.4 release, most notably "event injection and boiling".


More information about the fluid-work mailing list