The rollup of Protolus (an MV* Framework) which imposes layout and structural standards


The combined Protolus environment. Protolus is a view controller framework which does not couple views to data objects, but instead sees each view as an atomic unit which should be able to fetch it's own data, which may be a composite of many data objects. I believe this model is more representative of how we actually work on the web rather than being a naive object to template mapping, or at the other end of the spectrum: a reimplementation of Swing in js.

get protolus:

npm install protolus

make your project directory:

mkdir myProject
cd myProject

now initialize a new protolus project:

curl | sh

now run your app:

node application.js

Protolus expects a certain directory structure:

_ Panels/
__ index.panel.tpl
__ default.wrapper.tpl
__ ...
_ Controllers/
__ index.wrapper.js
__ ...
_ routes.conf
_ MyAwesomeDataObject.js
_ main
__ main.css
__ main.js
__ package.json (which includes a 'resources' array which references main.(js/css))

The App/routes.conf file has a series of sections which correspond to various groups and their routes.

articles/*/# = "articles?name=*&page=*"

articles/upload = "upload?type=article"

shows a couple of routes, one which only applies to a POST action, the other applying to all.

Panels make up the view component of Protolus, and are just a random piece of HTML however large in size you want it to be. Each Panel uses a set of macros to enable logic and subrendering, and before rendering it looks for a matching controller.

For example, if I had a panel 'signup/payment' I would put it at:


and I would put that controller at


We also adds a macro to the mix for resource management: The require macro takes a comma separated list of node_modules to ship over to the client, and dependencies are resolved as you'd expect. This is built for inclusion in the head of the generated document and types are automatically served from endpoints like:


The controller is a simple js script who's job is to fetch & stuff any data that the panel will need into the template, which is exposed to the object as 'renderer' and to respond to any incoming input.

renderer.set('data', myVar);

additionally you often have to wait for an asynchronous task to complete which you can do like:


and you have 'application' available to you which provides:



application.setSession(key, value);

for managing session variables



application.setCookie(key, value);

for managing cookies




for managing incoming variables

and as a rollup for all these


which prefers get, then post, then session, then cookies

and last to pull your current session id:


Protolus.Data is also exposed as 'Data', so you can interact with the object layer, if you are using it.

Datasources are registered by creating an entry in the configuration

"DB:myDataSourceName" : {
    "mode" : "msql",
    "host" : "localhost",
    "user" : "dbuser",
    "password" : "P455W0RD",
    "database" : "mysqldbname"

Check out the docs to build your ORM, DAL or any number of minimally meaningful acronyms!

Formerly resources lived in their own directory, now Protolus is piggybacking the npm format which means, not only does publishing the module serve double duty, but it also makes it easy to serve existing browser-compatible npm modules. Check the documentation.

var Protolus = require('protolus');

var application = Protolus.PanelServer();

This also gives you access to the protolus libraries at:

and any templates you create will have both 'renderer' and 'application' (an instance of Protolus.Application.Connection) exposed for use.

You can also include the data module:

var Protolus = require('protolus').with('data');

This exposes Protolus.Data

Tests use mocha/should to execute the tests from root


If you find any rough edges, please submit a bug!


-Abbey Hawk Sparrow