Olivier Scherrer

Olivier is a Front End Developer at Lab49 New York, a strategy, design and technology consulting firm that creates advanced solutions for the world’s leading investment banks, asset managers and exchanges. He has a strong experience in developing real-time HTML5 applications. He's the author of Emily and Olives, two JavaScript frameworks that allow to easily create powerful web applications on top of node.js, with high UI performance and low memory footprint.

[podefr]

The wonders of emily.js: closest/closestGreater/closestLower

Emily.js has a great bunch of modules to allow you build scalable and fast applications, but it also has some hidden gems that happen to be very useful, solving common problems that we usually overlook and work around with an ad-hoc solution.

Today’s hidden gem is closest/closestGreater/closestLower from Tools.

Let's say that you have an array of items such as:

var items = [0, 10, 15, 20, 50];

And that you want to get the item that's the closest to the number 18, which would be 20 in our case:

tools.closest(18, items); // 3, as items[3] === 20;

If you want to find the closest to 17.5, as it's exactly between 15 and 20, closest will return the last item in the array that matches, which is 20 in our case.

tools.closest(17.5, items); // 3, as items[3] === 20 tools.closest(35, items); // 4, as items[4] === 50

If you're interested in getting the closest item that is greater, you can use closestGreater:

tools.closestGreater(1, items); // 1, as items[1] === 10

If there's an exact match, it's returned:

tools.closestGreater(0, items); // 0, as items[0] === 0 is an exact match.

Finally, you can get the closest item that is lower, using closestLower:

tools.closestLower(9, items); // 0, as items[0] === 0; tools.closestLower(10, items); // 1, as items[1] === 10;

[podefr]

The wonders of emily.js: getNestedProperty and setNestedProperty

Emily.js (https://github.com/flams/emily) has a great bunch of modules to allow you build scalable and fast applications, but it also has some hidden gems that happen to be very useful, solving common problems that we usually overlook and work around with an ad-hoc solution.

Today's hidden gems are Tools.getNestedProperty and Tools.setNestedProperty.

Let's say that we have an object with the following structure:

var foo = { bar: { baz: "value" } };

And we want to test baz. If we aren't sure if foo even has a bar object, we usually do something like:

if (foo.bar && foo.bar.baz == "value") { ... }

This becomes even more complex as the property that we want to access is nested deeper into the structure. But with getNestedProperty from emily.Tools, we have a nicer way to access it:

var Tools = require("emily").Tools; // getNestedProperty will return the value corresponding to a path, defined via a simple string if (Tools.getNestedProperty(foo, "bar.baz") == "value") { ... }

If bar weren't set, or if we try accessing another property, we'll just get undefined in return

typeof Tools.getNestedProperty(foo, "qux.baz") == "undefined"; // true

Also, if no path is given, the value is directly returned

Tools.getNestedProperty(foo) === foo; // true

Even better, if we now wanted to set a property that is deeply nested in the structure, but we don't want to go through the incremental creation of nested objects:

// We want foo.qux.baz to equal "value" foo.qux = foo.qux || {}; foo.qux.baz = "value";

We can use Tools.setNestedProperty to simplify the previous:

Tools.setNestedProperty(foo, "qux.baz", "value"); foo.qux.baz; // "value";

Also, if the object is actually an array:

var foo = []; Tools.setNestedProperty(foo, "100.qux.baz", "value"); foo[100].qux.baz; // "value";

These tools were added to Emily.js to help Olives.js' data-binding, so you can declare an object's nested property to bind with a function or the property of a DOM element.

[podefr]

The auto-instantiating JavaScript constructor is an anti-pattern

The 'new' keyword in JavaScript is used for creating an object out of a constructor function. JavaScript allows us to override the return of the constructor call by our own data, of any type!

function MyConstructor() { if (!(this instanceof MyConstructor)) { return new MyConstructor() } this.myMethod = function () { ... } }

Which allows us to call myConstructor by doing either

var myObject = MyConstructor();

or

var myObject = new MyConstructor();

This is completely error proof as using new is now obsolete. But a pattern that 'magically' does things without being explicit to the developer that uses it is often misleading. In that case, it doesn't tell us whether the object that is returned is a new instance or not, or if it's stateless.

If calling MyConstructor without new can damage the application, then we can simply throw an error instead of returning a new MyConstructor.

function MyConstructor() { if (!(this instanceof MyConstructor)) { throw new Error("MyConstructor needs to be called with the new keyword"); } this.myMethod = function () { ... } }

And if the capital in the constructor's name indicates that it's a constructor that returns a new object, then it can also indicate that new is required. It's a well known convention.

[podefr]

Don't use JavaScript prototypes just for reducing the memory footprint

Prototypes in JavaScript are a way for implementing inheritance, and inheritance is a pattern for code reuse. One of the effects of code reuse is a lower memory footprint, but using prototypes for reducing the memory footprint doesn't guarantee that the code is reusable. Opting for the prototypal pattern for the sake of memory footprint is a premature optimisation.

Indeed, attaching the methods of an object to its prototype prevents these methods from using the variables declared in the scope of the closure created by the object. Example of the prototypal pattern:

function Person() { // variables in this scope can only be accessed by functions defined in this scope. var name = 'John Doe'; } Person.prototype.setName = function (newName) { // 'name' defined in Person can't be used here. We only have access to the properties of the new object. this.name = newName; } Person.prototype.getName() { return this.name; }

And to use this object, we would do:

var person = new Person(); person.name; // undefined person.name = "Emily"; person.getName(); // Emily

While this is fine and will work as expected, the name information is not hidden. We have polluted the public API with data that shouldn't be accessed directly by other parts of the program. At that point, a convention is to use the '_' character for prefixing these 'private' properties. But if it's available it's always tempting to use it, especially for testing.

Let's create a new object which prototype will be an instance of Person, and both Person and Musician use the prototypal pattern:

function Musician() { } Musician.prototype.getInstrument = function () { return this.name; }; Musician.prototype.setInstrument = function (name) { this.name = name; }; Musician.prototype = new Person(); var musician = new Musician(); musician.setName("Young"); musician.getInstrument(); // "Young"

We now have a pattern where we need to use the prototype for inheritance, which is a design choice, instead of just for reducing the memory footprint. But as we also inherit from the parent's properties, we end up with a conflict on the "name" property where the Musician's one will shadow the Person's one. This design is actually broken because of a performance choice that happened too early, and this is called a premature optimisation.

Here's the same code but using the Closure pattern, which hides the data in a closure:

function Person() { var name = 'John Doe'; this.setName = function (newName) { name = newName; }; this.getName = function () { return name; }; } function Musician() { var name = 'guitar'; this.setInstrument = function (newName) { name = newName; }; this.getInstrument = function () { return name; }; }

Here's how we are going to use Musician:

Musician.prototype = new Person(); var musician = new Musician(); musician.setName('emily'); musician.getInstrument(); // guitar

we can see in this example that the methods are defined in the same scope as the 'name' variable. Name is hidden and can only be accessed through the use of the accessors, so we can change the internals of Person without risking conflicts with the objects that inherit from it.

The rule of thumbs is to always use prototype for single inheritance, not for reducing the memory footprint. At the end of the project, if the memory footprint is too high and needs to be reduced, and there are no other gains than this one (such as optimising images, removing zombie views, fixing memory leaks) and the gain has been evaluated via profiling tools, then it's wise to move some methods to the prototype.

You can find here a quick benchmark showing the impact on memory for both approaches: https://github.com/podefr/benchmarks/tree/master/proto-vs-closure-memory

[podefr]

Missing feature of the day: grouping DOM nodes

Let's say that you’re developing a JS Framework that has the concept of widgets. A widget is a JavaScript Object with a representation in the DOM. As you have one reference on the JS Object somewhere in your application, you’ll want to have one reference to its DOM structure, and unfortunately the only way is to wrap the template into one parent DOM element. For example, one of your widgets has the following template:

Text

List items

When converting this to dom nodes (how you do it doesn't matter here) you may have a list of dom elements, one p tag, and one ul tag, or have a parent dom element wrapping them. Let’s call these two items a group. But when this group gets appended to the dom, you lose the notion of group, as they become two nodes among the others. To illustrate this, let’s imagine that after being attached (how you do it doesn't matter here) we have the following structure:

Text

List items

Another widget here

As the notion of group is lost, there is no way now to distinguish them from the dom nodes of another widget. We can’t take them out and append them somewhere else. This problem is solved by wrapping them into a parent dom element, which creates the notion of groups. Usually a div is chosen. But the drawback here is that we have added an unnecessary dom element that could have been avoided. And unnecessary dom elements are one major cause of performance loss. One way of solving this issue would have been with using a document fragment. A documentFragment looks like a dom element though it can't have a representation in the actual dom. Unfortunately, once appended to the dom, it loses its children. // this is our dom element that doesn't exist in the DOM var domFrag = document.createDocumentFragment(); // We add it actual dom elements, they're part of our widget domFrag.appendChild(domElement1); domFrag.appendChild(domElement2); // It has two children domFrag.childNodes.length == 2; // true // We append our non-dom element somewhere into the DOM destinationDom.appendChild(domFrag); // Our documentFragment still exists, but has no more children // Of course, it doesn't exist in the DOM, though its child now do. domFrag.childNodes.length == 0; // true Another way of doing it would have been to have a grouping method in the DOM. // A real dom element without tag var domGroup = document.createDocumentGroup(); // Let's call its innerHTML, it's fast and cross browser. domGroup.innerHTML = "

Text

list items

"; // That's two items domGroup.childNodes.length == 2; // true // They get appended to destinationDom, no extra HTML tag added. destinationDom.appendChild(domGroup); // They're still part of the domGroup. domGroup.childNodes.length == 2; // true // So I can move them around otherDestinationDom.appendChild(domGroup) The domGroup would not have a representation in the dom, so its children could be direct children of the destinationDom, but can still be moved around by appending the group somewhere else. If ever a childNode gets appended somewhere else, it would simply leave the group. You may also have noticed that a documentFragment doesn't have an innerHTML property, which is a shame as it's a cool way for creating dom nodes out of strings, and it's fast because it's using the browser's rendering engine. Fortunately, the domGroup would have this feature, which would become the number one tool for defining a widget's view: var widget = { this.element: document.createDocumentGroup(), this.render: function (template) { if (template instanceof HTMLElement) { this.element.appendChild(template); } else if (typeof template == "string") { this.element.innerHTML = template; } else { throw new Error('template must be either a string a set of dom elements'); } }, this.place: function (destinationDom) { destinationDom.appendChild(this.element); } }; How cool would that be? Update 13/07/2013: Shadow DOM will solve this problem and add other cool features: http://www.w3.org/TR/shadow-dom/

[podefr]

Migrating from Emily 1.2.0 to 1.3.1

[Last week I explained how to migrate from Olives 1.2.0 to 1.3.0](http://podefr.tumblr.com/post/39606341462/migrating-from-olives-1-2-0-to-1-3-0). Emily has seen a few breaking changes too between 1.2.0 and 1.3.1: * Modules are anonymous * Promise is fixed * CouchDBStore has been completely removed ##Modules are anonymous [Olives modules are now anonymous, just like Emily's. Read this to know what the implications are.](http://podefr.tumblr.com/post/39606341462/migrating-from-olives-1-2-0-to-1-3-0) ##Promise is fixed Until 1.3.0, Emily's Promises where an interpretation of Promise/A, but were done wrong. After [Domenic's gist on promise](https://gist.github.com/3889970) I realized that I had to fix them. Emily 1.3.0 made Promise compliant with promise/A, and since 1.3.1 they're now also compliant with [Promise/A+](https://github.com/promises-aplus). The API has changed, resolve is now called fulfill, and chaining promises is now working as expected: promise.then(function (result) { var newResult = doSomethingWithResult(result); return newResult; }).then(function (newResult) { ... }); ##CouchDBStore has been completely removed Although CouchDBStore was removed from Emily since 1.2.0, the server part was still embedded in Emily's handler. This is now fixed an part of [CouchDB-Emily-Tools](https://github.com/flams/CouchDB-emily-tools). To use CouchDB-Emily-Tools, you simply need to add its handler to Emily's server: var emily = require("emily"), tools = require("couchdb-emily-tools"); emily.handlers.set("CouchDB", tools.handler); tools.requirejs(["CouchDBStore", "Transport"], function (CouchDBStore, Transport) { var cdb = new CouchDBStore, transport = new Transport(emily.handlers); cdb.setTransport(transport); cdb.sync("mydatabase", "mydocument") .then(function () { console.log(cdb.toJSON()); }, function (error) { console.log(error); }); });

[podefr]

Migrating from Olives 1.2.0 to 1.3.0

Olives 1.3.0 introduces two breaking changes that you must be aware of before upgrading: * Modules are now anonymous * Some of them have been renamed These changes lead us to a new way of using Olives in your project: * EOWYN: Embed Only What You Need. ##Anonymous modules Until 1.2.0, Olives modules were named and prefixed with Olives/: define("Olives/ModuleName", function ModuleName() { ... }); Modules had to be named so they could be loaded into the test runner (jsTestDriver) before the specs and the specs are able to require them (with requirejs). Then they had to be prefixed with Olives/ to create a namespace and avoid collision with other libraries. The counterpart is that it's ugly and repeats the file name, à la Java. As I didn't like it much I preferred adding a pre-compilation step before running the tests. I was then able to remove the names in the modules definitions, keeping my project DRY. Olives modules are now anonymous by the commonJS definition. ##Renamed modules For the names to be more explicit and for Olives plugins being easier to spot, the following modules have been renamed. * Model-plugin.js is now called Bind.plugin.js * Event-plugin.js is now called Event.plugin.js * UI-plugin.js is now called Place.plugin.js * Transport.js is now called SocketIOTransport.js ##EOWYN: Embed Only What You Need Theses changes allow you to better integrate Olives within your project. Given that you already use require.js and its optimizer (or any equivalent), you can simply download Olives's parts that you actually need and paste them into one of your application's directory. Make your require.js configuration point to them and you'll be able to develop and debug your app with the unminified version of Olives. Finally, when minifying and packing your application, Olives will be seamlessly embedded without any the extra weight. Of course, you can still download and use the built Olives for rapid prototyping, just like it used to work with the previous versions of Olives, but with the new names. Checkout Olives' github for more information: https://github.com/flams/olives

[podefr]

Securing CouchDB in 3 steps

Freshly installed, CouchDB offers little to no security. There's even a name for that temporary state: its called the "Admin Party", as every user is considered to be an admin. While it might seem dangerous, it's actually a nice thing as it lets you fine tune the level of security you want to obtain. Say you're in learning mode and you just want to figure out what CouchDB is and how it works. You're creating databases and documents and fetching them through design documents. At this time there's no need to secure anything, and anyway, CouchDB is bound to your local address so you're the only one who can mess around with it. But start using it in production, with an application that manipulates sensible information, and you'll have to go deeper into securing it. And that's what i'm going to describe, in 3 steps. 1. Identifying the user who issues the request 2. Limiting a user's read/write access to a database 3. Limiting a user's write access to his own documents ###1. Identifying the user who issues the request CouchDB stores its users in the _users database. A user document looks like this: { "_id": "org.couchdb.user:couchdb", "_rev": "1-8995e8ff247dae75048ab2dc800136d7", "name": "couchuser", "password": null, "roles": [ ], "type": "user" } The _id is the user's name prefixed with "org.couchdb.user". ``_rev`` is the document's revision. ``name`` is the name of the user, the one that the user will remember, along with his password. Roles is a feature that we'll develop when speaking about ``_security`` documents. It allows to create some sort of groups for the users. Finally, type can only be ``user``. While ``roles`` and ``type`` should be defined by the application during the account creation phase, ``name`` and ``password`` are chosen by the user. They are his credentials. [More information on the authentication database in the official wiki](http://wiki.apache.org/couchdb/Security_Features_Overview#Authentication_database) So, how does one authenticate himself? Basic authentication This authentication mode is using the name:password@url style. For a couch user ``couchuser`` whose password is ``couchpass``, the request url would be: http://couchuser:couchpass@localhost:5984/db/document Querying CouchDB with the user's credentials will create a "user context" object that will be passed around to control functions, such as the validation functions we are going to talk about. Cookie authentication The second way of authenticating a user is by issuing a POST request on _session. The request must embed the credentials: curl -vX POST http://localhost:5984/_session -H 'application/x-www-form-urlencoded' \ -d 'name=couchuser&password=couchpass' The response's header will have a Set-Cookie field that can now be re-used to authenticate the user for 10 minutes, depending on your configure files. HTTP/1.1 200 OK < Set-Cookie: \ AuthSession=Y291Y2hkYjo1MDQ2NUI3MjrL7w8A3NhUpW6XkVvVVJ25epeGsw; \ Version=1; Path=/; HttpOnly You're going to need to be able to extract the AuthSession from the header before passing it to further requests. Here's an example of a request embedding AuthSession: curl [your request here] --cookie \ AuthSession=Y291Y2hkYjo1MDQ2NUI3MjrL7w8A3NhUpW6XkVvVVJ25epeGsw [More on authentication is available here.](http://guide.couchdb.org/editions/1/en/security.html#security) Now that the user is authenticated, we can control which databases he has access to. ###2. Limiting a user's read/write access to a database Database-wise, there are two types of users, admins and readers. Readers can create, read and write document except for design documents. Database admins can also modify design documents and _security documents. They can do some other stuff but it's not the purpose of this article. The _security document will simply specify what type of database user a CouchDB user is: // This example comes from the CouchDB guide { "admins" : { "names" : ["joe", "phil"], "roles" : ["boss"] }, "readers" : { "names" : ["dave"], "roles" : ["producer", "consumer"] } } Notice the "roles" fields. Instead of adding every user in the ``names`` array of the ``_security`` document, you could instead specify which roles are ``admins`` or ``readers``, and assign the adequate role to the user. As soon as a ``_security`` document is added to a database, any user not listed in is not granted any access. [need to double check on that] [Authorization documents in the official wiki are explained here.](http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization) We can now prevent users from wandering around in our application. But if a user's granted access to a database, how can we secure write access to documents that he doesn't own? ###3. Limiting a user's write access to his own documents Design documents can have a validation function that is called everytime a document is altered. Here's an example of a function that checks if the user who tries to modify a document is its owner. "validate_doc_update": "function (newDoc, oldDoc, userCtx) { if (newDoc.author != userCtx.name) { throw({ forbidden: 'Only' + userCtx.name + ' may edit this document' }); } }" Throw defines the error that is returned to the application. Other helper functions are available too: - required(field) : check if a field is set in a submitted document - unchanged(field) : prevent changes in a field - user_is(role) : check if user has given role UserCtx has other properties: - roles : the roles that are assigned to the user - db : the name of the database And a last argument is passed to the validation function, the database's security document. [More on validation functions.](http://wiki.apache.org/couchdb/Document_Update_Validation) To go further, we could imagine adding a proxy, between CouchDB and the application, that would filter out dangerous requests. [Querying the database through https should also be considered.](http://wiki.apache.org/couchdb/How_to_enable_SSL) In a future article, I will explain how to secure CouchDB when used by an OlivesJS/EmilyJS application.

[podefr]

Locally test your npm modules without publishing them to npmjs.org

There could be several situations where you want to locally deploy an npm module of your own before publishing it to npmjs.org. Say you've just created one and want to see how it deploys, or you're fixing bugs and you want to test the module in integration before publishing a new version, or you just want to keep your npm private. To create a local npm, change directory to where its package.json is. cd /path/to/package.json Then run the pack command: npm pack This will create, in the same directory, a tarball named after the name of the project + the version specified in the package.json. This is exactly what is published to npmjs.org! You can now see what's inside tar -tf packagename-version.tgz Or you can install it in your project to test it in integration. cd path/to/your/project/ npm install ../path/to/your/npm/packagename-version.tgz As you can see, 'npm install' can either be used to fetch an npm on the official repository, or to install a local one. Note that each time you'll run npm install, the previous files will be overridden by the new ones, regardless of the version number, which is pretty convenient! Hope this helps!

[vweyl-blog-deactivated20171004]

THE TOY COMPANY SCENARIO

Jane Doe is working at a toy company that just bought a license for a major motion picture to use the characters in connection with the toys they produce.

Usually making such a “buy” decision means you already have a good idea what you’re going to do with this...

[bredele-blog]

HTML5 and bindable datalist

HTML5 datalist* allows to autocomplete input elements with static content (option element).

<input list="cars"/> <datalist id="cars">   <option value="BMW"/>   <option value="Ford"/>   <option value="Volvo"/> </datalist>

Thanks to Olives Framework, you can bind datalist options to a store and set them as you wish.

If you are interested, I put an example into my github.

*Until now, only Firefox supports this feature.

[bredele-blog]

Hi,

If you’re familiar with Nodejs you’ve surely read some stuff about how to create a blog with this technology and others such as socket.io, mongoDB or couchDB.

I have and even though it was quite simple, it was still too much for me. Why make easy things difficult? It’s a question to which I...

[podefr]

Olives 1.1.5 supports SVG views

Since version 1.1.5 Olives is officially supporting SVG. SVG and HTML are very similar and can be manipulated almost the same way. It's all about creating xml tags, setting there attributes and styling them. The great news is that Olives was born to support SVG and only a few modifications were required to support them. In Olives, views are almost fully passive. They have no logic attached to them, let aside the data- attributes that describes the plugin calls. Considering that HTMLElement and SVGElement are almost similar, we should be able to treat SVG views just like we treat the HTML ones. As an example, I've create an [SVG+Olives charting demo](http://podefr.github.com/Olives-SVG/index.html). Let's see how the grid of the demo is built:  We first create an SVG group that will group the horizontal lines: If you're familiar with Olives, you'll recognize the data- attributes that specify which plugin to use to manipulate the SVG. data-gridy will call the foreach method of the 'gridy' plugin on the Element, when bind will be called on the line method. The plugin is configured in the Grid UI and it binds the SVG with the gridY data store. grid.plugins.add("gridy", new ModelPlugin(gridY)); The combination of the SVG and Olives will generate as many lines as specified in gridY, with y1 and y2 being replaced by the store's values, as declared by data-gridy="bind: y1; bind: y2". Once the grid is generated, we can render the chart on top of it.  The chart is a polyline: To add points to a polyline, we have to add them to the points="" attribute. These points have a special formatting and can't be simply extracted from an array of points. So we need to create a drawLine function that will handle this formatting. drawLine will then be added to the Model-plugin. points is a simple array with many points: [ 43, 65, 87, 83, 79, 101, 102, 95 ] chart.plugins.add("line", new ModelPlugin(model, { drawLine: function (points) { var newPoints = []; // We populate the new array points.forEach(function (val, idx) { // 20px separate each point // the Y axis is "inverted" so subtract the value to 200 newPoints.push([idx*20, 200-val]); }); // It also has "terminating points" newPoints.unshift([0, 200]); newPoints.push([newPoints[newPoints.length-1][0], 200]); // Finally, we join all the points (x1,y1 x2,y2 x3,y3…) // And set the points attribute this.setAttribute("points", newPoints.join(" ")); } })); Any kind of chart can be rendered using this technique, bar charts, pie charts, whatever. And we can even go further by connecting our models to a node.js server to have real-time charts!

[podefr]

Understanding Olives' MV* model

[Olives](https://github.com/flams/olives) is a JavaScript MVC-like framework for building web applications. There are already loads of MVC frameworks out there (more than 30 featured in [todomvc.com](http://addyosmani.github.com/todomvc/) including labs!) and almost each of them interprets the MVC model in a different manner. To better understand how to develop web applications using Olives, I need to explain its own interpretation first. Olives' MV* was carefuly designed to address 3 major points: - Maintanable application - Extensible application - User-centred API Of course there are others, but these 3 certainly had the most impact on Olives' design. Let's create an extremely simple UI example taken from [Olives' dev environment](https://github.com/flams/dev-env) to see what it looks like  When I click on "en" I'd like "Hello Olives!" to be displayed, but when I click on "fr" I want "Bonjour Olives" instead. View =========== In Olives, views are pure HTML, they're completely passive:

Default Greeting Olives! Choose your greeting : en | fr

[located in index.html](https://github.com/flams/dev-env/blob/master/index.html) You'll notice the data- attributes though, they're the only link to the logic. I see multiple benefits to this approach: - Easy to add behavior to existing html - Easy to update, change or evolve even by a non programmer - Easy to style, no pre-processing needed - Easy to find, the view is in an .html files. - No new technology to learn, like a specific templating tool Model =========== The model is an observable data store provided by the framework. Olives' simplest Store can store data in an Array or an Object, and notify on changes. Of course the Model has no knowledge of both View and Model. Example of an Olives model: // Initializing the Store with an object that has a greeting key. var model = new Store({ greeting: "Hello" }); // updating the model... model.set("greeting", "Bonjour"); // ... will also notify observers model.watch("updated", function ( key, value ) { console.log(key, value); // "greeting" "Bonjour" }); But it can also be sub-typed for persistence, like Olive's LocalStore which stores the data in localStorage, following Liskov principle. Olives' _controller_ uses the simple Store by default, and it can be overridden by any subtype of Store. This is what happens in our simple demo, which is the reason why no model is explicitly defined. OObject =========== And then comes the OObject. The OObject is a kind of Controller but with more responsibilities. It's actually a skeleton of the part of a user interface, it's the place that concentrates the whole logic. Let's see it in action. // OObject creation var ui = new OObject; // The behaviors to add to the view can be implemented in plugins ui.plugins.addAll({ // This is a plugin that links the view to the model. // Reachable through data-model "model": new ModelPlugin(ui.model), // This is a plugin that captures user inputs and //transmits them to the OObject (ui) "event": new EventPlugin(ui) }); // Specify the view of the UI ui.alive(document.querySelector("section")); // The function that is called when clicking on "en" or "fr" ui.changeLanguage = function (event, node) { // .... } [located in index.html](https://github.com/flams/dev-env/blob/master/index.html) The OObject binds the view to the model through the use of plugins. Olives has a built-in plugin called ModelPlugin, which implements double-way binding: when the model is updated, the view gets updated, and vice-versa. It also has a plugin called EventPlugin which binds the view to methods of the ui, like changeLanguage. And of course, you can imagine creating your own plugins to extend Olives capabilities. Why not adding mustaches on pictures using a face recognition plugin? Or translating coordinates to localized city names? Application examples ================ The previous example is quite limited. There are two other applications using Olives that serve as example: [TodoMVC](https://github.com/addyosmani/todomvc/tree/master/labs/architecture-examples/olives) This is a more complete application that is divided between 3 UIs that share data. [Suggestions](https://github.com/podefr/suggestions) (Under development as of today) Similar to a todo list but with more features, such as routing, real-time model etc. Comparing Olives' MV* to MVC ======================= When looking at the files tree, we see that an Olives application isn't split between several model/controller/view files as we usually have, but in small UIs instead. Each UI is specifically designed for a simple task, like adding a todo, displaying todos, or counting them. And this makes it way easier to design, develop and maintain an application. While this may not be obvious for a small application with few contributors over a small amount of time, it becomes dramatically more important with bigger projects. As a project grows in size, its number of files increases, diluting the knowledge of the architecture. As years pass by, developers forget where to put code and just happen to place it where it works. Sometimes duplicating code, data or coupling things that shouldn't be. The cost to avoid this, through processes, also increases as the project ages. I have seen this too often. On the other hand, Olives MV* has a 1:1 correspondence between the UI and its source code. You could almost see the files tree as you look at the UI. Divide the UI into multiple views, and each view has a single js file. Because of the way the OObject works, it's really hard to mix things up and associate some business logic to the wrong view, giving you even more hints on where to place your code. It's also possible to create generic UIs that can be duplicated throughout the application. The result is that you have a code that is easy to maintain and to extend! Less plumbing ============= Last but not least, as the example shows, there's almost no plumbing. Scanning through the given code, one can seen that every line has a meaning to the developer and not to the framework. There's no specific Olives way of structuring code, declaring classes, doing inheritance or such, it's just plain JavaScript, and Olives is an API. That's what I call a user-centered API, but I'll expand my thoughts in another post. Links ===== * [TodoMVC](http://addyosmani.github.com/todomvc/) * [Suggestions](https://github.com/podefr) * [Olives+Emily dev environment](https://github.com/flams/dev-env)

[podefr]

A BMW for wheelchair users

I worked on this project in 2007, when I was studying automotive design. I found these pictures buried deep into my hard drive and wanted to give them a second life.

The goal was to invent a car that would specifically be designed for wheelchair users without it being perceived as such by other drivers. It had to allow their users to easily get in and out, in a safe and elegant manner.

[podefr]

An innovative way to replace AJAX and JSONP using node.js and socket.io

I was so happy the first time I used socket.io, seeing how fast, reliable and easy to use it is, that when I started doing XHRs I felt that something was wrong. Current State of the Art implies using AJAX calls coupled with JSONP for getting data from a 3rd party server. To new applications we're also adding WebSockets that allow to push data from the server to the client. Three different techniques for carrying data, can't we unify them?

Actually, it turns out that we can. Let's imagine something like this: data is fetched by the node.js server. By data I mean any data, whether it comes from a database, a web service, the file system, actually anything that node.js can have access to. Each data source is accessed by what would be called a request handler. And when the data is available on the node.js server, it can be accessed from within the application and be streamed to the client using socket.io.

It would resemble something like this:

How would it work from the client side?

A component, let's call it Transport, would be responsible to query the requests handlers. For instance, verifying a browserID assertion would look like:

Transport.request("BrowserID", assertion, callback);

Fetching data from CouchDB would look like:

Transport.request("CouchDB", { path: "/db/_all_docs" }, callback);

And opening a keep-alive socket that would trigger the callback for every new chunk:

Transport.listen("CouchDB", { path: "/db/_changes" }, callback);

And the exact same syntax would work on the server side with a Transport directly connected to the requests handlers.

How to trick socket.io to transport the requests params and push the result back to the client?

Think of it like JsonP. You load a script on a different website which pads the result with a function name that you've previously defined. When you get this result, the callback is executed.

So what I do is, I send the requests params to the server and I ask it to reply on a previously defined channel (a unique one). The server executes the request through the handler, and streams the result back to the client. If transport.request is called, the channel is closed right away, otherwise a function responsible for closing it is returned.

The solution has 5 major benefits

One unique transport

Multi-purpose transport that can stream binary data too

Based on well known technologies

Easy to use

No cross-domain issues

Want to see it in action?

The solution was successfully implemented in Olives JS Framework, which Transport module can be found here, and requests handlers are explained here.

There's a simple application currently being developed that also uses this Transport module and another use case

Warning

A discussion is going on on socket.io's google groups. I'm exposing a database to the browser's application to showcase this solution but this has security issues. I'm looking for a way to secure this and will post about it, until then, just be aware of the implications.

[podefr]

Using CouchDB in a real-time web application

CouchDB offers three distinct APIs for querying documents. It also comes up with an API to track changes happening in a database. I've written 3 articles to explain how to use these APIs in real-time web applications, using the _changes API that is available through a keep-alive socket. They describe the flow of requests needed to fetch the documents, keep them up-to-date with the database, and when available, update the database when changes happened on the client side: * [Document API in a real-time application](https://github.com/flams/emily/wiki/CouchDB-document-in-a-real-time-application) * [Bulk Document API in a real-time application](https://github.com/flams/emily/wiki/CouchDB-bulk-document-in-a-real-time-application) * [View API in real-time a application](https://github.com/flams/emily/wiki/CouchDB-view-in-a-real-time-application) Also note that these articles reflect how [Emily CouchDBStore](https://github.com/flams/emily/wiki/CouchDBStore) works, in combination with [Transport](https://github.com/flams/emily/wiki/Transport)