The Bless Relationships API

InfoGrid supports types on both nodes and edges, aka MeshObjects and Relationships. They are called EntityTypes and RelationshipsTypes, respectively.

Assume we have two related MeshObjects, each blessed with a (hypothetical) type Person. Like this:

MeshObject obj1 = ...;
MeshObject obj2 = ...;
obj1.bless( PERSON );
obj2.bless( PERSON );
obj1.relate( obj2 );

Now if we want to express that the second Person is the daughter of the first Person, we cannot do this:

obj1.blessRelationship( PERSON_PARENT_PERSON, obj2 );

because we don’t know, from this API, whether obj1 or obj2 is the daughter or the parent.

Instead, in InfoGrid, we have to explicitly specify the direction, and we do this by specifying the “end” of the relationship type instead of the relationship type for the bless operation, like this:

obj1.blessRelationship( PERSON_PARENT_PERSON.getSource(), obj2 );

Hopefully, the documentation of the parent relationship type in the model indicates the semantics of the source and the destination of each relationship type. These “ends” are called RoleTypes, by the way.

One nice side effect of this approach to the API is that it becomes quite straightforward to extend it if InfoGrid ever decided to support ternary or N-ary relationship types: Just pick a RoleType beyond a source or destination RoleType.

If you bless relationships from the HttpShell — the simplest way of manipulating the graph from a web application — you thus need to specify the identifier of the RoleType, not of the RelationshipType. By convention, the source RoleType of a RelationshipType with identifier ID is ID-S, and ID-D for the destination.

Error Messages, Parameters and Other Resources In InfoGrid

InfoGrid internally configures all parameters and messages via resource files. This makes internationalization much easier, and gives application developers a way of changing internal parameters if so desired. InfoGrid includes an override mechanism allows developers to use different values than InfoGrid’s default values without having to change InfoGrid’s property files.

Let’s take an example. Class org.infogrid.httpd.HttpServer implements a very simple HTTP server that’s been quite useful for automated testing, for example. Its default listening port should not be hard-coded, but instead is configured via a resource. In the code, it looks as follows:

private static final ResourceHelper theResourceHelper
        = ResourceHelper.getInstance( HttpServer.class );

protected static final int DEFAULT_ACCEPT_PORT
        = theResourceHelper.getResourceIntegerOrDefault(
                "DefaultAcceptPort",
                8081 );

Class org.infogrid.util.ResourceHelper is basically a wrapper around the Java resource facilities, but with some additional facilities, such as the ability to parse integers and use defaults as can be seen from this code fragment. When this code runs, InfoGrid looks for an override first (more about this below), then for a property file called org/infogrid/httpd/HttpServer.properties. In that file, it looks for a line that looks like this:

DefaultAcceptPort=1234

If found, DEFAULT_ACCEPT_PORT will be assigned that value. If not found (as in the current InfoGrid version, as the line is commented out), it will use the default specified in the code, here 8081.

If a developer wishes to override the property in that file, they could of course change that property file, but that would effectively create an InfoGrid branch, which is undesirable. Instead, an override mechanism can be used:

The ResourceHelper can be initialized with an “application resource bundle”, which essentially is just another property file specific to the application. Resources specified in that file override all others. An application developer could specify, in that file:

org.infogrid.httpd.HttpServer!DefaultAcceptPort=80

and DEFAULT_ACCEPT_PORT will become 80. It is necessary to qualify the name of the resource with the fully-qualified name of the ResourceHelper so no naming collisions occur across modules or developers, hence the prefix separated by the !.

The application resource bundle for an application can be set manually, by invoking ResourceHelper.setApplicationResourceBundle( ResourceBundle ) in the application’s startup code, or, preferably when using the InfoGrid Module Framework, in the application’s module advertisement as a parameter like this:

<parameter name="org.infogrid.util.ResourceHelper.ApplicationResourceBundle"
        value="com/example/ExampleApp" />

This identifies file com/example/ExampleApp.properties as the application resource file.