...
An analogy from another environment, Java, is a POJO or "Plain Old Java Object". The J could just as easily be substituted for "JavaScript" in this case.Anchor
that-ism
Fluid, like jQuery, does not encumber its users with yet another attempt at creating an object-oriented "class" system for inheritance in JavaScript. These are all doomed to failure—if they were indeed ever a good idea in the first place. JavaScript is a language in which functions are King, and Fluid does not attempt to dethrone them. Instead, Infusion uses an excellent idea from Douglas Crockford, probably the foremost current authority on JavaScript. In his splendid book, JavaScript, The Good Parts, he puts forward an object assembly technique which we dub "that-ism", after its use of the name that by analogy with the hopelessly broken JavaScript language feature, this. that-ism is explained in some detail on our framework page How to Define a Unit, and also on the blog posting About this and that.
We sometimes call the resulting objects "units", or more simply, "thats," since everything is an object in JavaScript, calling them "objects" would not be very informative. They are simple combinations of pure data and pure functions, with no unstable reliance on prototypal inheritance or any attempt to create formal "types." Methods on a that are just plain old functions, bound directly to their object instance using a closure. As a result, methods can easily be rebound and passed around without changing their meanings. In particular, zero-arg function members can be registered as pure event handlers, without having their meaning broken—try doing that with members from a "class system" based on this-ism!
Note that that s are not suitable for use as Model Objects. Since they have an internal binding to their own that member hidden in their closure, their meaning will be destroyed by an attempt to copy them with fluid.copy().
...
EL Paths
In some parts of the framework, we refer to "EL expressions". This is a somewhat historical phrase that perhaps sounds like it says more than it is trying to. All we mean by EL expressions are dot-separated paths built of names—for example if you had defined an object zar with a member boo which has a member baz, you could access the nested Javascript property by writing the expression zar.boo.baz. Now, as a string, this expression becomes an EL expression—that is, the string "zar.boo.baz" is an EL expression which designates the same piece of data. This is useful because it abstracts references to pieces of data from the actual data itself. It is possible to replace one object tree with another, but still to maintain a stable reference to the same subproperty baz, whoever it happens to be today. This is particularly important in web applications where data claiming to be "your data" can suddenly arrive from anywhere (a JSON feed, some persistence, a particularly aggressive version management system, etc). However it got here, you know it is your data because it is at the right path.
...
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).
...
IoC is a crucial mechanism of avoiding tight binding between framework components in Infusion. Whilst we do not yet have a full formal IoC container in the framework, most of the essential mechanisms are already there as part of Fluid's Subcomponent system. The subcomponents for a top-level component can be expressed in a fluid:declarative structure, where a tight binding is avoided between component and subcomponent implementations. This enables a more flexible design, including the ability to swap out the implementation of one subcomponent for another. We accomplish this loose-coupling through the use of #EL to hold the name of the subcomponent to be instantiated, rather than requiring the user to instantiate the subcomponent themselves directly in code.
...
Markup agnosticism reflects the same basic stance that leads to #IoC, #Declarative Configuration and fluid:Model Transparency: effective organisation of dependencies. In practice, users of a framework want to be able to use their own markup and customize the look and feel of existing components. Virtually every other client-side framework ships their widgets as "black boxes:" markup is baked into code and is invisible to the user. This makes it very difficult to customize the widget without cracking open the code and forking it.
...