#olivesjs

[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)

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.