-
Notifications
You must be signed in to change notification settings - Fork 55
KeyConcepts
FOAM is a meta-programming system, in that it is a program that generates and/or manipulates other programs. In the case of languages like Java, it does this through code-generation, but for Javascript, it does this mainly by dynamically creating prototypes as maps of functions.
Examples of meta-programming include Lisp-macros, C++ Templates, Unix's M4 or other macroprocessors, the OMG's Model-Driven-Architecture (MDA), or just about any type of code-generator. JavaScript is actually the world's most popular meta-programming language. In JavaScript, there is no distinction between compile-time and run-time, and the language has no syntax for creating classes, so instead, your program builds its own classes at run-time (which is a form of meta-programming). All OO Javascript programs are therefore meta-programs, ie. programs which generate programs. However, despite having excellent support for meta-programming, this feature is rarely utilized in JavaScript, beyond the run-time creation of simple classes.
FOAM is model-oriented, in that it "models" programming entities (classes, prototypes, objects, etc.). Models are higher-level abstract definitions which can be converted to lower level languages like Javascript or Java. FOAM is a textbook Model Driven Development (MDD) system.
Like UNIX, Foam is feature-oriented. This means that reusable feature-components are used to add functionality to any underlying data-source (Model). In Unix, this is accomplished by composing feature-commands like "sort", "grep", and "more" to underlying data sources like "cat", "ls", and "ps" my means of the UNIX "pipe". Feature-orientation offers exponentially better productivity (in a mathematical, not figurative or marketing sense) than methods which require common features to be re-implemented for each data-source. UNIX however only provides feature-orientation for text/command-line programs. Foam extends this to GUI's and the Web.
FOAM is written in itself. The Model is itself Modelled. This enables the framework to be very compact, as it essentially generates most of itself.
Whenever possible, FOAM employ a declarative, data-driven approach. This means that a lot of an application’s definition will be in the form of declarative data, rather than as code. This allows for a higher level of productivity, a lower barrier to entry, ease of tooling, and an increased ability to customize the interface to different input methods and display form-factors. This also preserves our design investment across technologies, both present and future, as we can always redo the underlying data interpreter or compiler to target new libraries, new languages, new versions of languages, new platforms, etc., without modifying our original high-order models.
At the heart of FOAM is a rich data-model which describes objects. Unlike the regular anemic OO class description which merely describes an instance variables type and name, our data model will include a rich set of attributes for each class and property. Information like display name, size or value constraints, help text, sql type, display hints, permissions, desired visibility and mutability, comparator selection, etc. This rich data-model is used by pluggable "features" which are used to provide extended functionality to all modelled entities.
When your code is data, your code-base becomes a data-base.
FOAM is a Model-View-Controller framework. This means that it decomposes user-interface code into three distinct layers:
- Model: layer responsible for representing the data
- View: layer responsible for presenting the data to the user
- Controller: layer responsible for mediating or adapting between the Model and View
FOAM's (Javascript) UI creation model is based on View component composition rather than on the direct use of HTML and DOM. View components may themselves be implemented using HTML and DOM, but once this is done, most end-users will work with these pre-made components rather than with HTML directly (in most cases). This is similar to how GUI libraries work: basic GUI components use graphics primitives to draw things like Buttons and Labels, but then GUI developers may create whole applications without ever use the underlying graphics primitives themselves.
FOAM's approach has a number of advantages:
-
Consistent L&F. If developers reuse a standard library of View components for things like Buttons, Labels, Menus, Detail and Table Views, etc., rather than marking these up as HTML for each use, then they're going to get a more consistent L&F because all implementations of the same concept will actually be using the same markup and styling, by default.
-
Encapsulation. All DOM (or Canvas, or whatever) manipulation is hidden inside a View (encapsulated). The View itself only exposes public properties, events, and methods, not the underlying implementation. Directly manipulating another component's DOM would be akin to directly manipulating another objects's vtable or the frame-buffer pixels owned by a GUI control. The lack of encapsulation leads to fragile, bug-prone, and inflexible systems.
-
Technology Independence. HTML UI's are, by definition, limited to HTML, but by encapsulating the HTML and DOM events behind standard FOAM components, the client of a View component is isolated from the underlying implementation technology. Therefore, View components are free to choose other implementation mechanisms. For example, a view component could be implemented using Canvas, WebGL, SVG, or as a hybrid native control. FOAM unifies the composition, event, animation, storage, and configuration aspects of all of these technologies, giving component developers the freedom to select the best underlying technology for their particular component, and giving component clients the freedom to mix-and-match components of various types without even knowing or caring about what underlying technology was used.
In order for View components to actually be components, they must be completely self-contained. If they were to rely on external CSS, then they would no longer be so. For this reason, HTML-based View components must also include their default CSS within their Model. Views must not conflict with any other View, including other instances of their own type. However, designers or developers, should still have the option of restyling View components if they wish, but by default, no external CSS should be required.