During the initialization of a Web application, Nitro performs a scan of the src/root directory and constructs a sitemap. The Path middleware leverages this structure to intelligently split incoming request paths to the corresponding scriptName and pathInfo components.

The scriptName component is the path of the JSGI application that will handle the request. If the Render middleware is used, the template path is also derived from scriptName. The pathInfo component stores the extra postfix of the request. Let's use an example to demonstrate the concept:

Given the directory structure (sitemap):


Nitro automagically splits the request path:



scriptName: /articles
pathInfo: /12339

since /src/root/articles/12339.js does not exist.

We can use the pathInfo component to implement nice, RESTful URLs... more
I read this post on Signal vs Noise with great interest. Ryan correctly identifies the problems with local variable declaration in Erb templates and offers a clever Ruby hack as a solution:

<% message.comments.last.tap do |comment| %>
    <li><%= comment.creator %></li>
<% end %>

While .tap() introduces a scope it still smells as bad style. A more fundamental flaw lies underneath: the lack of true separation of data and presentation. Consider the following alternative using Normal Templates:

{:reduce comments}

or the equivalent shorter version: more

Normal Template

by gmosx, at 25 Jan 2010
For some time now I was using a custom version of JSON-Template. I really like the simplicity of JSON-Template and the clean separation of data, logic and design. On the other hand I hate the syntax (repeated section, argh) and the 'cursor' paradigm employed has problems in practice.

In this vein, I designed a new template engine, called Normal Template. I consider this an evolution of JSON-Template concepts that works better in practice. Here are some benefits:

  • Separate 'if' command (required in practice)
  • Replaced {} interpolation with {=..}, safer in practice, more readable
  • A subset of XPath is used to navigate the data dictionary along with a cursor model (select)
  • Abbreviations for tags (s for select, r for reduce, etc)
  • Meta templates and static includes
  • Compiles to a javascript function for extra performance
  • Improved syntax error checks and reporting

For more information, please consult the detailed docs. To wet your appetite, here is an example.. more

New Blog platform

by gmosx, at 21 Jan 2010
Old time readers of my blog know that I regularly change the platform that I use. Lately, I was using Google's Blogger, but I wasn't happy with the layout. Before that, I used a lovely, custom-made, Ruby-based CMS. But since I am fed up with Ruby (after 8 years, no less) it was difficult to maintain.

Therefore, I decided to utilise my AppengineJS and Nitro open source projects to create a new platform for my blog. This new version is implemented in JavaScript, the language of the Web, and one of the languages I dig these days (the other being Haskell). Even though I am relatively pleased with the result (and the clean code behind it), there is a lot of work to be done, when I find the time.

In the meantime, please subscribe to my feed and check this blog often for interesting content. Oh, and bug reports are always welcome ;-)

Update: This blog is not based on the blog-gae example source code. In fact, the blog-gae example is outdated and does not reflect the latest improvements in Nitro and AppengineJS. Perhaps, I will release the mini CMS behind this blog as an example if there is sufficient demand...
There are many JavaScript templating solutions, yet I couldn't find one that suited my needs. Well, json-template came pretty close, but the JavaScript source code was hard to read and extend, so I decided to implement a simplified version for use in Nitro. There are some minor differences but the spirit is the same.

Some days ago I decided to extract the template into a separate Narwhal package:

You can now use the Template without requiring the whole Nitro stack.

Nitro in Javascript

by gmosx, at 28 Feb 2009
It's no secret that I am working on a web application framework. I was bored (not to say unhappy) with my old Ruby framework, so during the past year, I designed and implemented no less than 3 different Ruby versions and 2 different JavaScript versions. This blog, for example, runs on my latest Ruby experiment.

Why I kept redesigning the framework you ask? Well, I wanted to make sure the design is as simple, as standards compliant and as transparent as possible. Some days ago I started a new revision. This time I am confident I 'll nail down a great balance between simplicity and power. I am using JavaScript, a truly excellent language with an unfortunate name. JavaScript is the obvious choice in an era where the distinction between server and client is blurred. The show stopper for JavaScript is the omission of a standard library. Thankfully, Rhino and Java come to the rescue.

I 've released some preliminary code on github. The project is still called Nitro, but apart from the name, it has nothing in common with my older effort. There is not much in the repository yet but you can expect regular updates. Of course, I will chronicle the latest developments here.

Even at this early stage, I would love to hear comments, suggestions and ideas for further improvements or better refactoring.

The engine behind this Blog

by gmosx, at 29 Oct 2008
Nitro A few of my friends where curious about the engine that powers this blog, so I decided to shed some light on this issue by writing this post.

As already revealed in the Nitro mailing list, this site runs on the experimental web application framework I am playing with for quite some time. Even though I still call it Nitro, this is really a quite different beast.

It incorporates the results of my research on web application development over the last 3 years. A few hard lessons where learned during the life cycle of the original version so I tried to fix my mistakes this time.

The original plan was to implement the new version using JavaScript or Haskell. On the way I decided it was more practical to concentrate on the high level design first and validate it with a Ruby prototype. When I am happy with the new API, and the new framework is successfully used on a few personal projects I may convert the minimal Ruby code base to JavaScript. A release of mod_v8 and/or mod_tracemonkey will most certainly be a great motivation ;-)

Nitro in print

by gmosx, at 05 Dec 2006
Some days ago, my copy of The Ruby Way, Second Edition arrived. I was extremely pleased to see the chapters on Nitro and Og. Given the fact that lack of documentation is this project's showstopper, I would suggest that every programmer interested on these technologies grabs a copy of this book right now! Moreover, you get one of the best books about the Ruby language for free. You have to thank James Britt for the Nitro/Og specific sections of the book.

To tell you the truth, there is one thing that bugs me about this book. Even though the names of the devlopers behind other Web Development Frameworks (like Rails and Wee) are mentioned, my name was nowhere to be found. Oh well…