Developer Introduction to the Infusion Framework - Concluding Remarks

Edit on GitHub

We've come to the end of our introduction to the core concepts of the Infusion framework. There are many topics we haven't covered, but with these foundational concepts, we hope you go on to further explore Infusion.

We'll summarize what we've done below, then suggest some next steps.

Note: If you have feedback about this tutorial, we'd be glad to hear it via our Matrix channels, mailing lists or the Infusion issue tracker.

Summing Up

  • We implement our programs by designing components that work together to provide the needed functionality. Components are Javascript objects adhering to certain syntax conventions that are created using the fluid.defaults function. While components have defaults, any of these defaults can be overriden at the time a specific instance of the component is created.
  • Components use invokers to expose functionality "publicly", provide a consistent API for collaboration with other components or use by other code, and enable function overriding when deriving new components from existing ones.
  • All components support events and inversion of control; these allow our programs to be built up of loosely coupled parts, and to manage sequencing through components observing and responding to their own events or the events of other components.
  • Components that need to track mutable data, state or content should be model components; model components can coordinate and synchronize their data with other model components, fire events when their models are changed, and take other actions to store and respond to state changes. Model components can use model listeners to respond to changes in model state.
  • Components that need to interact with the web page DOM to display content or interact with users are view components; view components are bound to specific DOM nodes when created and support the DOM Binder convention to avoid tying an implementation too tightly to specific markup.
  • Components can include subcomponents, and use model relaying to keep state synchronized between different components in larger designs. Many kinds of model relays are possible aside from two-way synchronization.
  • As program designs evolve, Infusion's configuration-oriented components make it easier to restructure a design by splitting out functionality into multiple components and wiring them together through IoC references.
  • When it becomes clear two components have similar behaviour, Infusion's design helps in refactoring to share functionality by overriding invokers and creating base grades.
  • Infusion has strong supports for multimodal implementations that allow programs to adapt themselves to new contexts for input and presentation.
  • We can use transformations as part of model relays to express more complex coordination of data between different parts of a program.

Where to Go Next?