The template engine is based on the concept of views. In practice, every digital collection uses several common views which, in dmBridge, each have their own page template. The following sections discuss the views in more detail.
Favorites view is a subset of results view that displays a user's favorites. Because it inherits from results view, it has the same display options (e.g. list, grid, tile). It adds checkboxes and a "Remove From Favorites" button.
The dmBridge favorites are stored in the same cookie as the default CONTENTdm® favorites, so changes made to the favorites in dmBridge will show up in the default CONTENTdm® templates, and vice versa.
Favorites view only displays those objects to which the user has access from the current template set. If two template sets (A and B) exist, and neither has access to any of the collections accessible by the other, neither will render any favorites that the other will. But the favorites are still present in the user's cookie at all times.
Object view is used in single-object context. Typically, it is accessed by clicking on a link from an object in results view. Object view supports both compound and non-compound objects. When using the HTML templates in this view, keep in mind that either view_simple.html.php or view_compound.html.php may be loaded depending on whether or not the object is compound.
Every object viewer in dmBridge is its own class, in its own file on disk. A number of object viewers are provided (in the dm/objects/helpers/viewers folder) that are capable of handling some common file types. Which viewer is used for which file type depends on the associations defined in the Object View section of the Control Panel.
Due to the way the CONTENTdm® PHP API returns information about files, object viewers in dmBridge are associated with filename extensions. In the Control Panel, you can associate a particular object viewer class with a particular filename extension on a global, per-template-set, or per-collection basis. Be aware that some file formats may have more than one extension (e.g. .tif vs. .tiff), so you'll need to define the association once for each.
Every object viewer class must implement the
idmViewerDelegate interface. This requires writing just one method -
getHTMLTag() - which should return an HTML tag. Take a look at dm/objects/helpers/viewers/dmGenericImageViewer.class.php for an example.
Adding your own custom object viewer is as simple as writing your own class in the pattern of the existing ones and defining the associations in the Control Panel.
You have two choices as to where to save your custom viewer:
Object-results view is used to display compound object search results. Results are displayed in a two-column HTML table, one object per row, with the page title in the left column and the full text of the page in the right column. Only pages that match the search query are displayed; matching terms are enclosed in an HTML <span> element with class
dmHighlightedTerm. This view is only available for searchable compound objects.
Results view is used in contexts where a number of objects are displayed alongside each other. It can be populated by any group of objects, such as search results, browse results, or a user's favorites. (Favorites are handled by Favorites view, a subset of results view.)
There are two results view templates inside any template set folder: object/results.html.php and object/results_faceted.html.php. When dmBridge has facets to display, it will load the latter.
To change the number of results per page, supply the
rpp parameter in the URI query string; for example,
?rpp=10." This works in all output formats. The default is currently hard-coded at 20 and cannot be changed.
Results view provides several possible views within itself, each of which are just different ways of displaying objects. An easy way of rendering links to each of these views is using the
ResultsDraw::viewLinks() method. The user can always get any view by supplying the view parameter in the URI query string, e.g.
?view=tile. Of course, they first have to know that they are able to do that, and there is no reason you need to tell them; but it's not currently possible to disable those views entirely.
Grid view displays results in an HTML table, with one result per row. Columns are customizable and configurable in the Control Panel on a per-collection (not per-template-set) basis. Grid view is the default view within results view.
List view is like an inverted grid view, with metadata fields displayed vertically per-object instead of horizontally. List view can be accessed within results view by supplying the
?view=list parameter in the URI.
Tile view, like grid view, displays results in an HTML table. However, in tile view, each object has its own table cell. The number of columns is configurable in the Control Panel on a per-collection (not per-template set) basis. Tile view can be accessed within results view by supplying the
?view=tile parameter in the URI.
Search view is used to display the advanced search form(s) (not search results, which are handled by Results view). This view is not strictly necessary for all digital collections - you could write your own search interface, or use Custom Queries and Results (CQR) - but is provided anyway due to the complexity of the forms.
As you may already know, CONTENTdm® provides four different search forms on its Advanced Search page, allowing the user to search "across all fields;" "selected fields;" "by proximity;" or "by date." dmBridge merges the first two of these forms together, offering a total of three different search forms, which can be added to the advanced search template (search/index.html.php) using the
dateSearch() methods of the