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.

Let’s see how the grid of the demo is built:

We first create an SVG group that will group the horizontal lines:

<g class="grid">
    <g data-gridy="foreach">
        <line x1="0" y1 x2="600" y2 data-gridy="bind: y1; bind: y2" />
    </g>
</g>

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:

<g class="chart">
    <polyline points="" data-line="bind: drawLine, line" />
</g>

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!

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 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
• Extendable 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 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:

<section>
  <span data-model="bind: innerHTML, greeting">Default Greeting</span>
   Olives!<br />
  Choose your greeting : 
   <a href="#" data-event="listen: click, changeLanguage">en</a> 
   | <a href="#" data-event="listen: click, changeLanguage">fr</a>
</section>

located in 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

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 This is a more complete application that is divided between 3 UIs that share data.

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
• Suggestions
• Olives+Emily dev environment