Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Fluid Infusion Framework is built on a number of important concepts. This page outlines some of the fundamental design goals of Infusion, providing terminology to help clarify these goals. Descriptions elsewhere in the documentation may also make use of particular terms in certain ways, and this page collects together some of the conceptual and background knowledge you might need to help you interpret these descriptions.

...

Events in Infusion are model-oriented, and aren't specific to the DOM. Events have a very plain implementation in Infusion —  an event here is really just another kind of function call. Any function signature can be an event signature, any function can be an event listener, and an event's fire method is a plain function handle that can be handed around just like any other function. There is no special kind of "Event Object" that gets handed around to event listeners, and anyone can easily define a new event by simply calling fluid.makeEventFirer(). In practice, users should use the events which are created automatically by the framework as part of the initialisation of every Evented Component. Just by writing the event name in a component's options structure, an event type is automatically created. No code required.

...

Historically, the desire to be able to treat logic as data has strong roots, for example in the LISP community. However, where all application code is on a common footing, designs become tangled and hard to interpret. By providing domain-specific forms for carefully selected parts of an application's functionality, typically at the fluid: Controller level, the complexity of code operating on this data can be reduced and transparency increased. It is a productive middle ground, between all application code becoming a candidate to be data (as in LISP), and none of it (as in Java).

...

This somewhat vague-seeming description is an attempt to codify a way of thinking that can really only be internalised by repeated (and sometimes painful!) experience. Those unfamiliar with the benefits should read around some of the links above, and also experiment with the relationships between some framework components and their subcomponents, particularly the Decorators such as the pairing of Inline Edit and Undo.

Markup agnosticism

Markup agnosticism is ubiquitous throughout Infusion. We don't bake in assumptions about the nature and structure of a user interface's markup, recognizing that components need to be customized and adapted for different context.

...