Like any such framework, Niggle has one overarching goal: to be useful! The problem is that this has its contradictory aspects. One the one hand, for the expert user, configurability and extensibility are key. For the neophyte user, on the other hand, the most important thing is that things work out of the box. It seems senseless to me to design things in such a way that the neophyte user is presented with an intimidating array of settings and options that must be mastered just to get started. Unfortunately, a lot of open source software does leave something to be desired in this regard.
Niggle has always had a very configurable, extensible, componentized design. More recently, as I near what I will call the 1.0 final release, I have been trying to make sure that there are generally useful, out-of-the-box default settings that allow neophyte users to be productive with the framework very quickly. Ideally, this means users who are not even necessarily that experienced with server-side Java.
Any framework more or less encompasses an approach to a certain class of problem. For example, when you use Visual Basic or some similar GUI builder sort of tool, you tend to design the user interface of your program and then gradually flesh out the other details afterwards. So you could characterize those tools as being UI or presentation-centric.
Niggle's approach, on the other hand, could be characterized as data-centric. Typically, when you start off a new Niggle-based app, you will find yourself naturally sketching out your data structures in XML and then, on that basis, gradually filling in the other details such as presentation templates and the basic dispatching logic. In my view, this tends to lead to more robust, well engineered applications, as opposed to an approach that starts off at the user interface level.
Niggle is based very much on the idea of data source independence, which means that your application code is protected from any knowledge of how the system is retrieving/storing its data. This allows you to build up a prototype that uses flat-files, say, for data storage, and then later switch to an industrial-strength RDBMS like Oracle, without changing any of your application code. You simply change the external XML-configuration of your data sources. You could then switch from Oracle to another database vendor in a similarly easy fashion.
To achieve this, Niggle provides an object-oriented data API that abstract away the notion of an external data source. There are currently 2 implementations (really sub-implementations, since they share some of the same code.)
The first is in com.revusky.niggle.data.inmemory. The DataSource implementations in this package simply store all of the records in memory and log/persist to a flat text file. This implementation works quite well for applications with moderate data storage requirements. This implementation has the great virtue that it allows Niggle to work out of the box without any external RDBMS being installed and configured.
The second implementation is in com.revusky.niggle.data.jdbc. The JDBCBackedRecordSet implementation in this package represents a façade in front of an external RDBMS. It provides for a configurable level of in-memory caching of records.
In general, the Niggle Data API could be concretely implemented in various different ways. I would fully expect expert-level programmers to write custom data source implementation classes with different performance characteristics. (I would hope that they would contribute these classes back to the Niggle base, but there is no obligation.) For one thing, a very performance-conscious programmer could write a custom implementation that caches data in very smart ways for a given application domain. On the other hand, just about any arbitrary data source could be rolled up as a Niggle DataSource. For example, though I have not done it (yet) I have every reason to believe that the folders of an IMAP email server or the groups on an internet news server could be abstracted away as a Niggle MutableDataSource. At an earlier point, as proof of concept, at ROL, Paul Murphy wrote a Niggle DataSource wrapper around a JNDI data source. Thus, the potential exists to tie together disparate sources of data and treat them the same way programmatically with Niggle.
Niggle also provides a presentation API. It assumes that the end result of fulfilling an HTTP request is a com.revusky.niggle.templates.Page object. The Page interface has only one concrete implementation, FreemarkerPage, which wraps the open source Freemarker template engine. Again, there is no reason that one could not write adaptors so that Niggle could use other presentation solutions. I would be interested in this, generally. That said, there is probably less real motivation to do so than in the case of the data side, since Freemarker actually works extremely well and I anticipate that most people will simply use that. The data side presents a lot more incentive for custom wrappers since people already have their various data in an enterprise living in all kinds of different "containers ".