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:
- A symposium's venue was modeled using a simple abstract base class
with three subclasses (Hotel, Campus, and ConferenceCenter)
- 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.8: 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).