Databases Reference
In-Depth Information
When building custom search screens, the overhead of specifying the filter templates is
not significant—you simply need to specify the
FilterUIHint
attribute for any instance of
the
DynamicFilter
(or the
UnleashedFilter
) control that needs it. The custom page
template encapsulates the presentation logic for a particular entity, and having filter
templates specified there explicitly is not a problem. However, when building search pages
dynamically, you must specify the
FilterUIHintAttribute
directly in the entity model.
Figure 13.1 shows a Product list page, which has a typical selection of built-in filter
templates. With only Boolean, Enumeration, and ForeignKey filters supported out of the
box, this means having to use the
FilterUIHintAttribute
a lot
, not only increasing the
amount of code you have to write and maintain, but also forcing you to hardcode the
presentation logic in the business layer of the application.
FIGURE 13.1
Product list page with default filter lookup algorithm.
Luckily, Dynamic Data allows replacing the filter lookup algorithm, and it can be
brought up to par with the field templates. The
MetaModel
class defines a property
called
FilterFactory
that stores an object responsible for locating and instantiating
the filter templates. However, it is the
MetaTable
class, with the help of the
GetFilteredColumns
method, that determines whether a particular
MetaColumn
is consid-
ered filterable, before the filter factory gets involved. In this section, you learn how to
extend the built-in
FilterFactory
,
MetaModel
, and
MetaTable
classes to implement a fall-
back-based algorithm for filter templates that closely mimics the default algorithm used
for field templates.
Extending the FilterFactory Class
FilterFactory
is a simple class defined in the
System.Web.DynamicData
namespace. In
addition to its constructor, it defines only two public methods—
CreateFilterControl
and
GetFilterVirtualPath
:
