Chapter 11

Search is an indispensable part of business applications today. Database systems provide the ability to lookup information via its SQL interface. But software applications will almost never provide end users direct access to a database via SQL, and there are many good reasons for this.
Typically a fair amount of code is written by developers on top of SQL (or these days HQL or some other object-based query language) to expose search features in their applications.
JMatter integrates search capabilities directly into its user interfaces, in a deep and comprehensive fashion. The good news is that the entire implementation is independent of the domain in question, removing the need for developers to implement their own search layer.

11.1  Filtering Listings

All list views in JMatter are decorated with a simple query panel. Through this query panel, users can dynamically view a custom-filtered set of items, that match a specific criterion: users with a specific last name, contacts in a specific city, talks on a given topic, sessions given on a specific date, etc..
Users have adhoc search capabilities on every type in their domain. This feature is quite sophisticated. JMatter provides a custom widget based on a tree model that comprises an acyclic tree of the sum of valid search paths for a type, from the entity's root to leaf fields, and can traverse even associations to other fields.
Furthermore, for every atomic type, JMatter provides a set of matching inequalities and value editors.
So for example we can ask questions such as "return all contacts who live in a zip code that starts with a 7" or "find all talks given by speakers whose who live within such a matching zip code."

11.2  The Find Command

The Find command, which is inherent on any type, allows the composing of multiple simple criteria in a conjunction. Disjunction type composite queries are not yet supported.

11.3  Smart Lists

Smart lists denote the ability to save a query performed using the Find command to database. All JMatter applications include model objects provided by the framework itself. Examples include the entities User, and Role to manage authorization. With respect to Search, the Query model object is also part of your application's domain. This means that end-users can create, read, update, delete, and execute queries to their heart's content. They can even use the built-in search capabilities of JMatter to query queries.
So for example, in the MyTunes sample application, we can create our own playlists based on various criteria and name them, in a manner analogous that users have become accustomed to with other popular players.

11.4  Search in Associations

Another important feature in JMatter is the ability to search directly within the context of an association field, for the purpose of establishing a relation between two objects. Section provides a detailed example of its use.

11.5  Polymorphic queries

When modeling an application using object oriented principles, we avail ourselves to various modeling techniques such as modeling with abstract classes and interfaces. We can have an association from one entity to another which is by nature polymorphic. We saw two such examples when covering the Sympster demo application:
  1. A symposium's venue was modeled using a simple abstract base class with three subclasses (Hotel, Campus, and ConferenceCenter)
  2. Sessions were modeled with a relationship to an Event, an interface, implemented by both Talk and BOF.
The nature of these relationships carries through to queries. We can request of our persistence repository for a listing of events, which will transparently fetch both Talks and BOFs. We can narrow a polymorphic listing by type. One possible query is asking for all events of a specific type. All queries are performed object-based. This support is possible because Hibernate is object-based. JMatter takes full advantage of this.

11.6  Code Hints for Search

There is one specific class-level piece of metadata that developers typically specify to govern a default that is related to searching, as discussed in section 8.4.9: defaultSearchPath.
Here's an example:
public static String defaultSearchPath = "name";
This piece of metadata is useful to define one field that is most commonly used to search for instances of a given type. It may be name for a Person object, or title for a Presentation object.
The value is specified as a string but may actually be a field path, such as name.first.
This value in turn is used in the user interface to assist with quick searches for performing associations or defaulting the search field when performing a search operation. It's quite useful. At the moment, this feature is supported only for text-based fields where the inequality defaults to TextStarts (i.e. that we're looking for instances whose default search field value starts with the value entered by the user).