(M) VC Framework Locomotive

For several days now, I have been selecting Node.js framework for solving several demo tasks. I went through 4 frameworks ( Locomotive , Express , Geddy , Sails ) and the cycle of my articles I decided to start with Locomotive.

Locomotive came to my attention on the recommendation of my friend, who told me: “Listen, there is an interesting new framework that implements MVC on top of Express.” - and this interested me, which subsequently led to the addition of Locomotive to the list of “experimental”.

Locomotive Architecture and General Concepts

Locomotive presents itself as: “Strictly adhering to the pattern of MVC and REST principles, which has a tendency to write well with designed applications“ - but there is little to say about “ MVC ” inside Locomotive, it seems to be there, but at the same time it’s somehow to end. This statement has developed since the “Model” part, in my opinion, should be implemented at least in some form, but in the Locomotive documentation the author referred to the article “polyglot persistence” and said that you can choose Database & ORM yourself and “screw” it yourself to the framework, this approach of the author a little frustrated since the calculation was when choosing this framework that he really implements MVC (Model2) in full. Let's get back to what is implemented there.
“View” is implemented through Express, which in turn is integrated with such templates as Jade , Ejs and many others .
“Controller” is, in principle, fully implemented, there is the base class of the controller, you can really process the Request from the client and return a Response. Inside each method is a controller action, inside each action it is possible to obtain routing parameters directly from the current context:

var SearchController = new Controller();
SearchController.find = function() {
  this.query = this.param('query');
  // execute search query...
}
module.exports = SearchController;

“Action assistants” are also available allowing you to get in just before / after performing a specific action (in Locomotive this is called “ Filters ”):

PhotosController.before('show', function(next) {
  var self = this;
  if (this.param('id')) {
     next();
  } else {
     return next(“Error”);
  }
});
PhotosController.show = function() {
  this.render();
}

In this example, we insert an “action helper” to be executed immediately before the “show” action, thereby adding a layer where we can check the identifier parameter and decide whether to continue the request or to end it. Also, you can add an “action assistant” that will be executed before any action in the controller:

PhotosController.before('*', function(next) {
  //код будет выполняться перед любым действием в PhotosController
});

Well, besides the “action assistants” in Locomotive there is support for the “content negotiations” mechanism (http://en.wikipedia.org/wiki/Content_negotiation), that is, within the action you can register several ways to display the presentation depending on the format requested by the client , briefly looks like this:

PhotosController.index = function() {
  this.respond({
    'xml': { template: 'feed' },
    'html': { template: 'index' }
  });
}

That is, the PhotosController will return the view in one of two formats, depending on what format the user requested in the headers. With this value of the Accept header, the action will automatically return the registered index template:

Accept: text/html;

Actually, around these features there are a lot of not big “goodies”, but I will not go into details, I see no reason to rewrite the documentation.

And the last thing I found interesting in Locomotive was how they expanded their Express routing . They implemented match () which allows you to create routes with a “placeholder”:

  this.match('songs/:title', { controller: 'songs', action: 'show' });

and in my opinion they added an interesting “sugar”, recording not just routes but entire resources manipulated through REST. That is, here is such a line:

  this.resources('photos');

Will make available to you such routes as:

Method:	Route:	Promapit on action:
Get	/ photos	index
Get	/ photos / new	new
Post	/ photos	create
Get	/ photos /: id	show
Get	/ photos /: id / edit	edit
Put	/ photos /: id	update
DELETE	/ photos /: id	destroy

And you can describe the behavior of these routes by the PhotosController with the corresponding actions from the “Promapit to action” column. The functionality itself is simple but sometimes useful to save time. Around all these “features” there are a lot of customizations, so there’s no need to think: “AAAAAA what to do if I only need to show and edit” - the developer also took care of this .

Testing ease of installation and configuration

“I did it, I installed and configured Locomotive + Socket.io and made all the demos I wanted,” I would like to say so, but there were a lot of problems. Locomotive installs as easily as Express:

npm install locomotive -g

and then create the project:

lcm create project

and run:

cd project && lcm server

Everything is fine, so far, if you open the browser at http: // localhost: 3000 then Locomotive will cheer you up.
But my goal was to configure Locomotive so that it could properly handle Web Socket requests and upload files.
There is no problem downloading files, because Locomotive is built on top of Express, and just as it works in Express, so it is in Locomotive.
But with Web Sockets it turned out to be a bit unpleasant situation. For some reason, the Locomotive developer considered that the creation of an Express (app) object should be closed as part of the framework, thereby cutting off any possibility to wrap Express for example in Express.io (of course, you can stupidly patch the code, but these are not our methods). Then I abandoned the idea of ​​using Express.io, although it was best suited to Locomotive since Express.io rests perfectly on Express on top of which Locomotive is written. Then I decided to directly connect Socket.io, but even here I was disappointed. Here's an example of links where people cannot solve this problem without “fuss” , and the Locomotive developer is not in a hurry to “merge pull requests” on Github. Yes, and somehow the development of the campaign does not go at all over this framework, judging by the history of commits on Github.

Finally

In conclusion, I can say that, in principle, the Locomotive add-in is not bad, but in my opinion it is not expandable at all, that is, I would not risk doing something further expandable on it, since I would have to pack a lot of the framework itself.
But if your tasks, such as making a “Landing Page”, “Business Card,” then Locomotive is very suitable for this.

Used literature:

http://locomotivejs.org/guide