If you do not have an exact repository ID, you can search for items in the repository through a RepositoryView. Item descriptors and RepositoryViews often have a one-to-one relationship and often have the same name. You can find out what views are available through the viewNames property of the Repository component. This is useful if you need to build a system to navigate and view the entire contents of a repository. The IDs for items in different item types might not overlap. There might be no view that can return all items in the repository, but if there is, it is the default view. If you need to use the default view, you can use the view named by the defaultViewName property. Alternatively, you can create properties for your own services that allow you to explicitly name the view your code is interested in using. After you have a name, you can retrieve that view through the RepositoryView getView(String pName) method. From this returned object you can build and execute a query.

The RepositoryView can also implement atg.repository.RepositoryViewContainer if the repository needs to express a hierarchy of RepositoryViews. For example, a document management system might have a root view for all “documents.” From that you might have sub-document types such as white papers, promo blurbs, images, and so on. Further, the sub-view images might also have a refinement for specific image types like JPEG and GIF. You can see what attributes are available for building queries by accessing the itemDescriptor property of the RepositoryView. This describes all the property information about all the items that can be returned by this view.

Sets of repository items can be gathered by queries, which you can build with the atg.repository.QueryBuilder interface. This QueryBuilder object can be retrieved from the view’s queryBuilder property. After a query is built, each RepositoryView implementation translates the internalized data structure into its native query language, for example SQL, and return an array of repository items that match the supplied query criteria. This is the mechanism by which the targeting engine understands how to translate the rule syntax into the appropriate method calls of the QueryBuilder.

After a query is built from the QueryBuilder, it is executed via the various executeQuery methods defined in the RepositoryView interface, such as:

RepositoryItem[] executeQuery(Query pQuery)

These overloaded executeQuery methods allow range queries and sorting criteria to be added to the execution of the query. The methods return one of the following:

loading table of contents...