Search jQuery

jQuery Forum

andrew.te..

MVC or not MVC, the Formation Engine.

in Developing jQuery Plugins • 9 years ago

Various frameworks provide data binding facilities (Knockout, AngularJS, etc.) these days.

They are based on kind-of-MVC concept: you have some data (structure, model), view rendering that data in html and some code in between that commonly named as controllers. How successful/convenient those frameworks are subject of separate topic. For me they are too intrusive I would say. On some views/pages they make sense, on others final solution looks too ugly.

Anyway, here is an alternative idea...

Instead of separating data structure and its view we simply can create construction that is a data model and its view at the same time :)

I named that magic "construction" as Formation. Formation is essentially a collection of DOM elements organized in a tree that reproduces structure of the data (or model if you wish). Value of the formation is JSON data structure - the model per se.

Consider this example:

http://terrainformatica.com/formation/demo1.htm

Here you see collection of inputs and subsections (on the top).
On the bottom/right corner you see the Formation tree created of <section#inputs> container.

On the left you see live data of the Formation (editable textarea). Changes there reflect state of elements. In the same way changes in inputs reflect text in this textarea.

The Formation implementation does two major things:

creates formation trees and
initializes custom DOM elements (check that <input-list> in HTML source - that friends list).

Couple of words about custom elements support in formations:

When formation sees custom DOM element ( any DOM element with tag name containing '-' inside ) it tries to find its initializer in registry of jQuery plugins - that famous $.fn collection. And calls it if it was found. You can check js/jquery.list-input.js - it is normal jQuery plugin with the name matching that custom element tag name: "INPUT-LIST".

To create/get formation of some container you can call

either global [window.] formation( domel_or_$_wrapper ) function or
$(selector).formation().

You can store created formation in some variable and access DOM elements in it in quite effective manner:

var inputs = $("section#inputs").formation();
$(inputs.firstName).on("change", function() {...});

Accessing formation members directly is faster than accessing them using jQuery selectors as these are just direct references.

You can download complete sample to play with form here:
http://terrainformatica.com/formation/formation.0.1.0.zip

Future Formation plans: to implement so called repeatable formations, so if you have this markup:

<ul repeatable name="stockItems">
<li><output name="name"> <output name="price" type="currency"></li>
</ul>

and will feed it (through formation) by this data:

[ {name:"Apple", price: 1.05 },
{name:"Orange", price: 0.52 } ]

it will render two <li>s in the list.

Another ng-inspired idea is to have class switches as Formation elements, this class declaration:

<div class="{someSwitch:collapsed|expanded}" >...</div>

will cause corresponding formation to have element named "someSwitch" that can be assigned false/true or 0|1 values to change class to either <div class="collapsed"> or to <div class="expanded">...

That is it for now. My pardon if some will think that all this is complete non-sense.

Replies(6)

gregbaker

Re: MVC or not MVC, the Formation Engine.

9 years ago

This is interesting and I would like to discuss it some with you. But first, you said "... on others final solution looks too ugly," and no doubt this is quite true. Not everything fits the MVC pattern or even the MV* class of patterns. That is why there are so many other patterns that fit well with other kinds of problems. Mixing proven solution patterns to best fit each of the myriad of problems to be solved in a single application is more a norm than the exception, at least to me that is. So where an MVC solution is ugly, perhaps an MV* variate would do better or even an entirely different approach is called for.

But back to your "formation" post. I find it interesting and puzzling at the same time. It seems awkward at best for ajax data as well as persistent data, no? And for data storage on DOM elements the is already jQuery's "data" object. I may be missing something big here in your approach, but that would be my thick skull I suppose. Perhaps you could enlighten me a little more with additional examples perhaps addressing an external Json feed.

Thank you, Greg.

andrew.te..

Re: MVC or not MVC, the Formation Engine.

9 years ago

In my assumption MV* patterns are really patterns - methods that can be applied selectively in places where they really will benefit something.

As of the Formation...

It is about these three features:

It introduces concept of value for containers (sections/forms/etc.)
Access to the DOM (view) as a tree of "UI points of interests".
"Declarative" initialization of custom elements.

As of #1 - value concept for containers like forms, page fragments, etc.

Value of <input type=text> is a "terminal" string.

Value of the <form> for example is an object that contains other named terminals or sub forms/sections - so it is hierarchical *data* structure by its nature. So if you have some form/container defined as:

<form>
...
... <input name="name.first" value="A"> ...
... <input name="name.last" value="B"> ...
...
</form>

then its value will be:

var formValue = $("form").formation().value;
formValue here is an object having this structure:
{
name: {
first: "A",
last: "B"
}
};

Therefore mapping of some data (model) to view (html DOM tree) is a matter of getting/setting value of the formation's value. This approach works pretty well already when you have complex forms with many input fields that you need to fill from DB (AJAX, local storage, etc). Or get data from them to store/send to the server.

All above is about getting/setting values of forms having static structure - trivial and deterministic data-binding use case I would say. That is useful by its own but ...

... imagine now that you have single page web application (e.g. typical mobile app). Even it uses single HTML it has multiple "pages" wrapped into <section>s, each section may have tabs with lists of records, forms with input fields, etc. Consider that you've got a task to make state of this UI to be persistable. So next time, when user loads that application (opens the site), the UI will be presented in the state user left it previously.

Conceptually this can be done if to use formation assigned to root or body DOM object:

$( function() {
// restoring UI state:
formation(document.body).value = localStorage.fetch("ui-state");
window.on( "unload", function() {
// storing state of the UI
localStorage.store("ui-state", formation(document.body).value );
});
});

This task requires formation to include not only input/output elements but also other "UI points of interest" like for example identifier of current/open tab in some tabbed view. In terms of formation mechanism this also leads to the ability to say this:

formation(document.body).someSection.someTabsView.current = "fooTab";

to make fooTab active (show it) . I am working on this part of the formation engine at the moment.

About #2 - DOM (view) as a tree of "UI points of interests".

The formation is hierarchical structure of terminal DOM elements, [sub-]formations and so called "UI state switches". Its stricture is somehow close to the DOM tree it is created on but it is significantly more compact. Consider typical Bootstrap form:

<form role="form" name="foo" >

  <div class="form-group">
    <label for="email">Email address</label>
    <input type="email" class="form-control" name="email" placeholder="Enter email">
  </div>
</form>

Formation made of such <form> will look simply as:

{
email: DOMInputElement
}

So if you will need to access that input element from root formation you will do it as:

formation(document.body).foo.email.disabled = true;

That will be significantly faster than standard $-way of doing such things:

$("form[name=foo] input[name=email]").disable(true);

Lookup by selector has O(n) complexity (where n is a number of DOM elements in DOM tree) so formation can make your app more responsive. To get element from Formation is a matter of getting fields in JS objects. Again the formation is a compiled subset of original DOM tree containing only stuff that code is interested in. All decorative DOM elements are not there.

And finally about #3 - custom elements.

In my sample I am using <input-list> custom element that is in fact standard jQuery plugin.

It is just registered slightly unusually:

$.fn["INPUT-LIST"] = function() {...}

When the Formation scans the DOM in compilation phase it checks custom elements against corresponding drivers in jQuery plugin registry ( that $.fn collection ) and applies them to given elements.
So there is no explicit things like

$("INPUT-LIST").inputList() and the like in my demo. The formation does this under the hood.

Woof, that's kind of long answer

. My pardon to people who reached this point.

gregbaker

Re: MVC or not MVC, the Formation Engine.

9 years ago

Andrew, "...My pardon to people who reached this point. " not at all.. But rather, thank you for your time. The post was exactly what I needed I thing. Now I better understand. I recently saw a forms plugin (plugin I think) for Banks, applications, even tax forms and the like. This would make a great pairing as the basis of a "stateful" engine I would think. It has all the trapping for realtime validation and calculations as well as enabling unlimited undos and redos using persistent state data saved stacks. Another area might be analytical modeling where the "formations" are actually the visual representation of one or many underlying complex objects interacting in some rule-based environment, for static or even dynamic analysis. Thank you for your time

gregbaker

Re: MVC or not MVC, the Formation Engine.

9 years ago

So I had an opportunity to use your "Formation" on a small project. I used it in conjunction with "Grid Forms" by Kumail Hunaid on a small medical application. In particular, I used Formation in a "live" form (list like) of medications under a user's name. By live I mean, the form displaying the medications for review, uses an edit in-place feature to make changes, take notes, etc. (small, only ten fields per record) per each medication. The display/editable fields are a one-to-one subset from a database by field-name. A 'RESTful CRUD' like interface is used as a db link and Formations are used for the "real-time" edits. If an record is updated on the screen form, the formation automatically changes. And when a different record is modified, a new formation is built not deleting the old one as it is attached to a different record. Updates are automatic and can easily follow a command pattern to enable undo/redo edits saving formations as record states.

Your Formation seemed a perfect fit. I did have to make some changes in the CheckBox code section, though minor. Thank you.

The form generation was via John Resig's simple template, applying the initial record data returned for the user. Each record was simply a "fieldset" in the form and the formations were build with the fieldset as the base container. So an iterative formations list was generated by the natural data structure. The form's fieldset ids could be set to the unique record ids from the database - forming a one-to-one formation to db record. It works nicely.

andrew.te..

Repeatable formations

9 years ago

Yes, getting/setting values from/to complex forms by using single line of code with the formation is convenient.

I've added support of @repeatable for lists. Here is the demo:

http://terrainformatica.com/formation/demo2-repeatable.htm

First list there is declared as

<ol repeatable id="list1">
<li><output name="product" /> : <output name="price" /></li>
</ol>

And rendered by assigning array of records to that element:

var root = formation(document.body);
root.list1.value = records;

Another list uses conditionals:

<ol repeatable id="list2">
<li if='{type:"vegetable"}'><output name="product" /> : <output name="price" />, best with vodka</li>
<li><output name="product" /> : <output name="price" />, consider rum</li>
</ol>

And rendered with the same one-liner statement.

Packaged source/demos are here http://terrainformatica.com/formation/formation.0.2.0.zip

gregbaker

Re: MVC or not MVC, the Formation Engine.

9 years ago

Thanks. I'll take a look at your revisions.

Top Reply

Response title

Attachments

jQuery Forum

MVC or not MVC, the Formation Engine.

Replies(6)

Re: MVC or not MVC, the Formation Engine.

Re: MVC or not MVC, the Formation Engine.

Re: MVC or not MVC, the Formation Engine.

Re: MVC or not MVC, the Formation Engine.

Repeatable formations

Re: MVC or not MVC, the Formation Engine.

Statistics

Tags

Actions