Regardless of which grade of component you use, the basic structure will be the same. We'll use the simplest grade, a little component, to illustrate what this structure is. In future pages explaining other grades, you'll see the same principles.
The definition of a component involves two things:
A component's grade and any default options are registered with the framework using a call to
fluid.defaults, which has two parameters: the component name and an object containing the defaults. The parent grades for the component are specified in an array in the defaults called
gradeNames. For a little component, specify the grade as
Integrators can override your defaults when they instantiate the component, to customize its appearance or behaviour. The Framework will take care of merging the integrator's values with your defaults.
We'll go through some examples of options, to give you an idea of what they're all about.
Suppose you're creating a currency converter. You might wish to specify a default conversion rate:
The Infusion Inline Edit component uses a tooltip and defines (among other things) defaults for the delay before the tooltip appears, the text to display - even whether or not to enable it at all:
The Infusion Progress component uses jQuery animations to show and hide a progress bar. The defaults include objects that are passed to jQuery to configure the animations:
(We'll get into what these arguments are soon.)
Creator functions can be defined in one of two ways
The IoC - Inversion of Control system can automatically generate a component creator function for you. This is accomplished by added a special grade to the
gradeNames property: "autoInit":
Note that in Infusion 2.0, "autoInit" will become the default for all components and will not need to be specified.
The standard means of adding public API functions to a component is to express them as Invokers. An invoker is a declarative record added into a components defaults, under the section
You will note that the function
So what would our currency converter example look like, create using IoC:
You'll notice that in this case we have been able to avoid binding to the entire component instance in our public function, and so our standalone public function
tutorials.currencyConverterAuto.convert is indeed of more general utility than just for building a component method. This has happened because its responsibilities are particularly well-defined - you should always take the opportunity to restrict the binding behaviour of your public functions in this way whenever it is appropriate.
Creator functions follow a few basic steps:
thatby calling the appropriate Framework component initialization function
Here's what that would look like for a little component:
What would this look like for our currency converter example?