Naked Objects - Some ways in which Naked Objects could be extended

Naked Objects
By Richard Pawson and Robert Matthews

Extending Naked Objects

Some ways in which Naked Objects could be extended

The website is also the forum through which we will manage the ongoing extension of the framework. Naked Objects is fully open source. That means that you can copy and use it freely, and have access to the source code if you wish to extend it. The core of the framework has been written entirely by Robert Matthews, although with input and suggestions from a number of interested developers. Some of those have already started to write their own extensions, such as Dave Slaughter's EJB Object Store. We expect that with the launch of this book, a substantial development community will grow around the framework. We need your help if Naked Objects is to realize its full potential. On the website you will be able to find more details of extensions that are currently being developed, planned or just considered. In brief though, there follows a list of some of the principal directions in which we see that extension taking place.

New value objects and extensions

Many of the NakedValue types could be provided with additional behaviours both for use in adding business functionality and/or to be made available to the user via a suitable viewing mechanism. For example, a Date value object should allow date arithmetic, and a Money value object should support currency conversion.

There is also a need for many new types of generic NakedValue including a form of TextString that can be limited to a fixed number of characters (to fit existing database schemas), and another type that could support rich text formatting using XML.

Additional Views

The initial viewing mechanism is extensible and allows for new views to be added to it. New views could be written for many of the existing value objects (as well as for new ones) to better display them and to assist in the entry of data. One example is for a simple pop-up calendar for date values allowing a user to select a date with a single click.

Naked objects can be displayed in a number of ways, e.g. all business objects can be viewed as an icon or as a form. Other views can easily be added so, for example, some type of summary view could be provided that takes up less screen space. In addition, the table view, as an alternative to the list view, needs to be improved. Views specific to generic supertypes and interfaces are also possible.

To date we have done very little with graphics. There is huge scope here. Numerical type value objects could be viewable in chart form, for both input and output (in much the same way that modern spreadsheets allow you to draw the graph and then compute the numbers from it - a feature that shows remarkable insight into how sales projections are done!) Maps, schematics, networks and other spatial layouts should all be possible. The case study on Norsk Hydro shows one example of how such capabilities could be added, without violating the core philosophy of Naked Objects (that the object-oriented user interface should be derived 100% automatically from the business object definitions).

Related to the graphical views is the need for an image viewer along with an image object type.

Additional viewing mechanisms

The graphical drag and drop user interface is just one of many possible viewing mechanisms. Other mechanisms could be written to replace this particular interface. The benefit that the framework offers is that a specific viewing mechanism can be used to suit a user's current requirement, e.g. if the system needs to be accessed from a browser over a slow modem link then an HTML viewing mechanism could be employed instead of the current graphical interface. Different viewers can all be used at the same time to view the same objects providing they are being run on different clients i.e. within different JVMs.

New object stores

Naked Objects is an object-oriented system and is least complicated when used with some form of object based persistence mechanism. We would like to see simple object persistence mechanisms being used to store objects for small and medium sized projects as well as interfaces to the current OO databases.

However, a good proportion of the applications that Naked Objects will be used for will be based on existing databases and these need to be accommodated. Alongside the generic SQL and EJB based object stores that are available at the moment, other object stores are needed to support specific or demanding applications and to handle proprietary systems.

Infrastructural services

As already mentioned we have not implemented any security mechanism other than the About objects. This needs to be explored and a suitable authorization and authentication interface needs to be built into the framework.

Re-usable patterns for business objects.

Just reading through the five case studies in this book you will see that there are a lot of common patterns, even common business object classes: Customer, Case, Communication and so forth. The idea of a library of business object classes is not new - there are several public as well as proprietary libraries available. We have not yet evaluated any of these libraries to see if they could be used, or adapted, to form a set of standard naked business object patterns, but that would be a useful exercise. Our main concern is the extent to which the modellers have pursued the idea of behavioural completeness. We may, in parallel, start making our own collection of re-usable naked object patterns.

Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.