Understanding Field Paths

Posted by Eitan Suez Fri, 17 Nov 2006 23:21:00 GMT

I admit it's now been a while since I wrote this code. So as I give you the information on Field Paths, I'll also be giving myself a refresher.. :-)

The idea is simple but essential. The JMatter codebase has this notion of a field path. It's basically a way of serializing a field object as a string.

Many situations call for such a feature. The main one I can think of at the moment is regarding one of JMatter's features:
the ability to define and save ad-hoc queries.

In JMatter, one can construct a query visually right there in the application and save it for later user. Let's look at an example:

Let's fire up the Contact Manager demo application. You can browse contacts. In my app, I've created a single person contact who lives in the city of Austin.

Next, I right-click "Find" on "Person Contacts" and define a query: I'm looking for all people who live in Austin. I can navigate the ComboTree widget to the right field: Person->Contact->Address->City In this case, I specified "city starts with austin" when in fact "city is austin" might have been a better choice.

Anyhow, one of the features of JMatter is the ability to name and save this query. Indeed queries in JMatter are like other JMatter objects: they can be persisted, listed, and queried (as in "show me all queries containing the word "Austin" in their name).

So somehow JMatter needs to be able to save the query. If you look at the database schema, you will see tables such as "queryspecifications" and "compositequery" which concern themselves with this task.

If we peek at queryspecifications we can see that the query has indeed been persisted. Fields are serialized as field paths and restored from these field paths.

The fieldpath that was created for our query is:

com.u2d.contactmgr.PersonContact#contact.address.city

Let's take another example. Let's try to find users who belong to the "Default" role.

Figure 2 shows that I've defined and saved my query. The corresponding field path is:

com.u2d.app.User#role|com.u2d.app.Role#name

We note two things about this:

1. JMatter query specifications allow users to traverse associations;
2. The way these associations are denoted in field paths is via a vertical bar character.

Being able to define query specifications and to execute them and finally to persist them is very important and fundamental. It can be used as a building block for building a generic mechanism for constructing reqports. Indeed, this is one of my goals for JMatter: to build into the application the ability for users to define reports: to associate queries with a specification of the report: what columns to display, in what order, how to sort the results, etc..

Paths appear to be something not so unique to fields but more general to Members. Commands may be specified also using a path-like notation, for example: com.u2d.type.composite.Person#Edit can represent the Edit command on Person's. In the latest subversion commits, it does.

Finally, field paths don't have to be something that is hidden behind the scenes of an implementation. We can use them actively as a simple means of identifying paths for relating metadata.

So for example, in subversion I can now specify the default search field for a type as a field path. If you recall the tip of the week from July 7 entitled Associations made easy I describe how association editors allow you to search in-place for objects of a certain type for the purpose of associating one to another object. The screenshot in that blog entry illustrates how this works.

At the time, we used to have to write code like this to specified the default "search-by" field:

  static
  {
     ComplexType type = ComplexType.forClass(Speaker.class);
     type.setDefaultSearchField(type.field("name").field("first"));
  }

Now you do it like this:

  public static String defaultSearchPath = "name.first";

Technically the value that this field takes is a relative field path.

So now you know about field paths. I've recently been thinking about the design for authorization. JMatter has had authorization-related code built-in for a while but the implementation is not complete. I'm realizing that essentially what I'm doing there is building a JMatter application where the domain in question happens to contain some meta-types. We're specifying restrictions on Commands and restrictions on Fields. I hope to have a fairly usable implementation soon, with a predefined default authorization policy, and the ability for administrators to define new roles and their authorization policies visually directly in JMatter. Much of that has to do with empowering meta-information as true JMatter objects in JMatter. I'll be writing more about that in a future blog entry.

/ eitan