Martijn Faassen - Obviel: a client-side web framework

published Oct 12, 2012, last modified Nov 09, 2012

Talk during the Plone Conference 2012.

Martijn Faassen talks about Obviel, a client-side web framework, during the Plone conference 2012.

I am Martijn Faassen. I have a company called Startifact, doing freelance work. We may know me from Formulator, Five, lxml, Grok, Fanstatic and Silva. You should use Silva CMS, not Plone, so I will talk about that now instead of Javascript. Well, okay, if you insist I will talk about Javascript.

Comparison in Javascript can have unexpected, or at least unpythonic results. Javascript is like badly broken Python, which is a compliment for Javascript.

Obviel can be used to build web applications. It runs on the client side. It is best used on a page that needs to be updated all the time. It helps you exploit 'modern' browser features like CSS, the DOM and AJAX.

What does a web framework need? What do they almost all have? Templates. Sometimes they think this is all you need (php). I have not written a server side template for years, only client side. Obviel is a template implementation. Obviel first used JSON-Template, but there was no i18n support and other things could be nicer too. With Obviel Template and JSON you get rendered HTML. The template language is minimalistic and logic-less.

{variable2}

foo

{name}

Rendering into the DOM:

$(el).render(obj)

Obviel somehow finds the template belonging to an object. Each obj should have an iface property. It is just a string. Templates are associated with ifaces too. You declare a view with obviel.view.

Obviel = OBject + VIew + ELement

What changes? The server doesn't need to do the work of rendering. The clients do that for you. The templates tend to be small snippets that can be rendered individually. Obviel Template is not text-based, but DOM-based. It directly manipulates the DOM. The effect is the same.

{name}

You define evenOdd as a javascript function in the view.

Click here!

clicked is again a javascript function you define to do nice things.

@. is the current list element. Here we use the view of that element:

i18n:

This will be translated

The starship .

In the i18n we can have pluralization:

There is {amount} light! || There are {amount} lights!

obviel.i18n is gettext based. You can use Babel to extract strings. Also works for Javascript using jsgettext. It works, has features and is documented.

Routing on the client side. Browser has history, links, back button. Hard to do on a single page, but we still want to support it. There is the url fragment hack, like http://example.org/app#state. Or use the HTML5 history API to directly manipulate the URL. The application state can be a path, like app/animals or app/animals/djangopony. The path points to view and/or model.

Thesis, antitheses and synthesis. Thesis is traversal, its antithesis is routing, the synthesis is traject, hopefully the best of both worlds. We use that. Traject has a Python implementation, so you should look into it for the server as well.

Join us. See http://obviel.org

Oh, I have created a form library for Obviel, otherwise it would not be a web framework. obviel.forms. Since it is client side, a round-trip for validation is not needed. You do not post multipart/form data to the server, just JSON. This is much nicer for nested and repeated fields.

It is extensively documented, did I mention that?

Oh, we have obviel.sync under development. Goal: keep a set of client-side models in sync with a backend, like ZODB or a relational database. The idea is that the backends are pluggable: HTTP/REST, websockets, localstorage. Your model and view code do not need to know about the backend details. You mark changes in a session and commit it. You configure declaratively how the backend is used. Automatically send events when models change, so the UI can be updated.

It fits your Plone brain already. It needs more users. It works on IE8, I do not guarantee it for earlier versions of IE.