Framework merge: FLUID-4055 branch for GRADES

Justin Obara obara.justin at gmail.com
Tue Mar 8 13:18:40 UTC 2011


Hey Antranig, 

This looks really nice, and I can't wait to start using it. Looking forward to learning more about it. In advance of the dev meeting and documentation, here are my first two questions. 1) Since the grading is specified in the defaults, does that mean that an integrator will be able to change the grading, and wouldn't this potentially lead to issues if the expected grade doesn't match the supplied one? 2) What is a case where you wouldn't want to use "autoinit"? Is this just for backwards compatability? What would happen if you didn't use "autoinit" and supplied an incompatible creator function?

Sorry, that was more than two questions. 

Thanks
Justin

On 2011-03-08, at 5:31 AM, Antranig Basman wrote:

> 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".
> 
> Thanks,
> Antranig.
> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work




More information about the fluid-work mailing list