Niggle: Servlet Development Made Easy


Download:

Latest Version of Niggle (1.1 pre14)
(If you are starting with Niggle, get this one.)

Last Niggle 1.0.x release (1.06)

Forum example (requires Niggle 1.1)



Read More:

Niggle Design Goals

History and current status

Generated Javadoc

Configuring XML-based Metadata

Subclassing ServletInteraction

Template Engines used by Niggle



Other Links:

Niggle Project Page on Sourceforge

Subscribe to Niggle mailing lists

Niggle is a java class library that makes it extremely easy to develop robust, maintainable web applications. This means the kind of app that is very typical of the e-commerce space, where the application logic runs on the server and the web browser is used to provide the end-user interface; the server-side code will typically interface with an external database to store and retrieve the application's data. The Niggle framework is designed to alleviate the repetitive, tedious details typical of those kinds of applications

For people who are used to writing directly to lower-level API's like JDBC and the standard servlet API, Niggle-based servlets will seem astonishingly terse. For example, the mini-rolodex example that is included in the base Niggle distribution is implemented in about 140 lines of java code. The forum example, a separate download, implements a message board app -- with tree view of discussions, storage/retrieval of messages in a database, signup/login/session-tracking -- in about 600 lines of java code. By allowing you to achieve much more while writing (and subsequently maintaining) far fewer lines of code, Niggle makes you, the application programmer, far more productive.

The reason you can do so much more with less code is that, with Niggle, you declare the "messy stuff" externally. The presentation details are kept in HTML page templates and the details of data persistence in an XML-based schema. Once you set up these external files, the error-prone, repetitive code that is typical of many web apps is no longer needed. Things like reading and validating data from an HTML form, or retrieving data from a database and displaying it in an HTML page, are handled transparently by the framework. Just to give you a flavor of this, here is what Niggle-based code that processes an order form and displays an acknowledgement page looks like:

      
  public void execProcessOrder() throws IOException {
    Record order = getNewRecord("order_entry");
    fillInFields(order);
    OreoDataSource orders = getDataSource("orders");
    orders.insert(order);
    page = getPage("acknowledgement.nhtml");
    page.expose("new_order", true);
    page.expose("order", order);
  }
    

Since Niggle provides a higher-level API that abstracts away the messy details of the presentation and data layers, your application code (or what remains of it) tends to be more robust. What this means is that your code can continue to work unchanged (or almost unchanged) in the face of changing requirements. Consider the code snippet provided above. It assumes that there is an "order_entry" record in a database that contains the details of an order. Well, suppose that requirements change and this record needs to have one or more extra fields. No problem: the above code simply continues to work unchanged. You see, you specify your metadata in XML, so if you make changes to your database schema, adding one or more extra fields to a record type, then all of the validation, as well as the details of reading the data from a form or displaying it on a page, continues to occur automatically based on the modified metadata. Admittedly, you (or someone) will have to change your XML schema to include the added fields, and you (or someone) will have to tweak the page templates to take into account the extra fields to be displayed. But there will usually be no need to even recompile any of your java code. You can simply restart, and your java code will read in the changed XML shema and the right things will continue to happen. This is a very big win.

Since Niggle is written in pure Java and leverages standard Java API's, Niggle-based code is highly portable. Server-side apps written on top of Niggle will run practically anywhere -- specifically, any platform that supports Java 1.2 (or higher) and the Sun Servlet API v. 2.2 (or higher).

Here is the pitch. If you have to write web-based applications as part of your job, for the internet, a corporate intranet, corporate extranet, or whatever, you will get more done in less time if you use Niggle. I firmly believe (though I am biased) that Niggle is the most productive web application framework you can use. You will get the job done faster with Niggle than with other technologies in the same space -- be it Perl, PHP, JSP, or... you name it. Not only that, but the resulting code will be more robust and maintainable. You do not have to take this claim on faith. Simply download Niggle , unzip it, and start with the Hello, World example in the examples/helloniggle directory.

Acknowledgements

Niggle was originally developed as an in-house project at Reminders On-Line. It was the framework underneath their java servlet-based reminder service, called Medimom. ROL has been out of business since September of 2001, along with countless other dot-com startups. Still, I wish to express my appreciation to their management for having the enlightened vision to make Niggle available under a liberal open source license -- in the hopes that it is useful to other projects, but also that further enhancements and improvements will be rolled back into the code base so that we can all benefit.


Jonathan Revusky Last modified: 8 April 2002

Sourceforge Logo