Nitrogen 2.x is the result of hundreds of hours of development over the past years, and offers many improvements over Nitrogen 1.0. Here are the highlights. Behind the scenes, the codebase is simpler, cleaner, and better documented, and offers a great runway for future versions of Nitrogen.
Happy Hacking!
Nitrogen 2.x includes great new elements, deployment methods, and improvements to old elements and actions:
Significantly improved support for jQuery Mobile, including mobile-specific elements, allowing you to make adding mobile versions of your application much easier.
The #api{}
element allows you to expose a
Javascript API that will trigger a postback when called. You
can pass parameters to the function, and then pattern match on
the parameters in Erlang. See the API
demo.
The #upload{}
element now fires an event when an
upload has started, and includes the node() on which the
upload is stored, allowing you to handle uploads in an
application running on multiple Nitrogen servers. See the File Upload Demo. As of version 2.1.0,
The #upload
element now support multiple file uploads,
progress bars, and even a drag and drop interface.
The #grid{}
element provides a Nitrogen interface
to the 960 Grid System.
The #template{}
element now caches the parsed
template, eliminating unnecessary disk hits.
The #restful_form{}
element allows you to easily
build RESTful forms, allowing for a simpler interface to build
forms that will safely degrade if the client does not support
Javascript.
The #wizard
element allows you to easily build
step-by-step multi-page wizards.
Existing elements, including #droppable{}
,
#sortblock{}
, and #upload{}
, now
allow you to set delegates to go back to a module other than
the current page module.
A new #update{}
action allows you to wire
conditional, client-side update commands, or to broadcast
updates across a comet pool, if desired. This action is also
used behind the scenes by APIs such as
wf:update/2
.
The #event{}
action now allows you to specify an
optional keycode
attribute on keydown, keyup, and
keypressed events.
Commands such as wf:update/2
and
wf:wire/N
now understand jQuery selectors as a
way of targeting elements. For example, to apply a
#fade{}
action to multiple elements, you can do
something like this: wf:wire("##myelementid > .image",
#fade{})
to fade all elements tagged with the 'image'
class underneath the Nitrogen element 'myelementid'. See the
jQuery Paths Demo and read
the Nitrogen Paths docs for more
information.
The previous version of Nitrogen constructed nested elements
by giving the DOM element an ID of the form
page_element1_element2_elementN. Nitrogen 2.x instead
uses CSS classes to refer to elements, so elements have the
form 'wfid_elementname'. This makes for smaller pages, and
allows you to more manipulate Nitrogen elements with pure
Javascript in a predictable way. Additionally, it allowed for
the creation of a new API commands, wf:replace/N
,
which replaces an element with a new block of elements.
Nitrogen 2.3 introduces a dependency-free testing framework for validating your pages, postbacks, actions, and elements all work as expected. Create test cases that are instantiated server-side, execute something client-side (such as button presses), and validate the result server-side. View the documentation then check out the actual tests used by NitrogenProject.com.
Easily add custom elements, actions, and more to your Nitrogen apps with Nitrogen's plugin system. You can Create your own plugin, then add your plugin to our List of Nitrogen Plugins.
Nitrogen now contains functionality called Comet Pools that
implement much of the plumbing around a multi-user
application. A Comet Pool links together the Comet processes
in an application, and can either be 'local' (for the current
session only) or 'global' (for all sessions). Using the
wf:send/2
command, you can broadcast a message to
all processes in the pool. Additionally, messages are sent
when processes join (and optionally leave) the pool.
See the chatroom demo.
Core Nitrogen behavior has been broken out into well-defined,
pluggable behavior modules called Handlers. Handlers allow you
to easily substitute your own logic for things like session,
security, routing, and others. Simply create a module that
implements one of the existing behaviours, and register it
with a call to nitrogen:handler/2
before calling
nitrogen:run/0
.
Nitrogen now receives all requests through SimpleBridge, a layer that unifies the interface to various Erlang HTTP servers. The list currently includes Mochiweb, Yaws, Cowboy, Webmachine, and Inets. SimpleBridge is capable of adding websocket support even to servers that don't support websockets.
This makes the Nitrogen codebase cleaner, and allows you to run Nitrogen under an existing server in a more OTP-compliant way. In contrast, Nitrogen 1.x tried to exert much more control over the VM and the HTTP server.
Along with this improvement came the ability to run Nitrogen pages under any path, removing the requirement to prefix all Nitrogen paths with "web", e.g. "http://hostname/web".
Using Rebar (an Erlang build and packaging tool by Dave Smith), Nitrogen now supports a cleaner, completely self-contained project structure. There are 'make' commands to build Nitrogen projects that run under Mochiweb, Yaws, Webmachine, Cowboy, or Inets.
You can deploy Nitrogen in one of three simple ways:
The bin/nitrogen
script in the project allows you
to bring a node up and down in either background or console
mode. The bin/dev
script allows you to quickly
generate a page, element, or action, and recompile code on a
headless server.
Additionally, this support is used to provide binary packages for popular OSes1. See the downloads page.
As you may have already noticed, Nitrogen Documentation is now much more complete, and the website has been overhauled to be more clear and more helpful.