|
Copyright © 2000, 2009, Oracle and/or its affiliates. All rights reserved. | ||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See
Description
Interface Summary | |
---|---|
ContentListKeys | Common context keys which can be used across CMPagedResult and IPagedList result collection types. |
ICMPagedResult<T> | An ICMPagedResult represents a collection of query results in a page-based structure. |
IFilterablePagedList<T> | An IPagedList which can be filtered. |
IObjectFilter | Interface which allows custom filtering to use the entire object state, for specified Java types. |
IObjectSorter | Interface which allows custom sorting to use the entire object state, for specified Java types. |
IPagedList<T> | An IPagedList represents a collection of query results. |
IPagedListIterator<T> | A bi-directional iterator for traversing query results in a read-only manner. |
IPropertyFilter | Interface which allows custom property filtering, for specified Java property container types and specified JavaBean properties. |
IPropertyProvider | Interface to expose one or more 'extended' properties, for specified Java property container types. |
IPropertySorter | Interface which allows custom property sorting, for specified Java property container classes and specified JavaBean properties. |
IPropertyTypeFilter | Interface which allows custom property type filtering, for specified Java property container types. |
IPropertyTypeSorter | Interface which allows custom property type sorting, for specified Java property container types. |
ISortableFilterablePagedList<T> | An IPagedList which can be both sorted and filtered. |
ISortablePagedList<T> | An IPagedList which can be sorted. |
Class Summary | |
---|---|
CMPagedResultFactory<T> | supports creating an ICMPagedResult |
FilterCriteria | query filter criteria. |
PagedListFactory<T> | supports creating a ISortableFilterablePagedList |
SortCriteria | query sort criteria |
This package and sub-packages work together to provide query result collection support for WebLogic Portal Content Management.
This includes the ability to iterate over results, check the size of the results, apply sorting and filtering on both the initial query and query results, determine which properties can be sorted and filtered, extend/override sorting and filtering capabilities, and various other operations.
Both collection types support sorting and filtering, and this can be done either during the initial query, or applied to the query results. Sorting and filtering can also be used in conjunction. The collection types currently support single-criteria sorting and filtering.
Continuing the previous example, the Node 'name' property, which has property type String, can be sorted, since String implements Comparable.
By comparison, the Node 'objectClass' property, which has property type ObjectClass, does not have automatic sorting capability, since ObjectClass does not implement Comparable. Note that this support can be added by adding a custom IPropertyTypeSorter.
By comparison, the Node 'objectClass' property, which has property type ObjectClass, does not have automatic filtering capability. Note that this support can be added by adding a custom IPropertyTypeFilter.
Some filter methods do not make sense for given property types. If a property is a string, then the GREATER_THAN filter method does not make sense. Additionally, filter and sort values are repository specific. For example, filtering on date properties within the WLP Repository requires that the value be passed in as the number of seconds since 1/1/1970. Consult your repository and or SPI documentation for more information.
Initial sorting and filtering is done by specifying the SortCriteria and/or FilterCriteria in the ContentContext before calling the query method. Use the ContextKeys listed in com.bea.content.paging.ContentListKeys to specify the criteria.
Resorting and refiltering a query result collection is done by calling the PagedList and/or CMPagedResult reSort and reFilter methods.
For example, you could do something like this:
ContentContext contentContext= new ContentContext(request); // initial sorting ascending by node name ListscList= new ArrayList (); scList.add( new SortCriteria( SortOrder.ASCENDING, "name" ) ); contentContext.setParameter( ContentListKeys.SORT_CRITERIA_KEY, scList ); ISortablePagedList pagedList= nodeManager.getNodes( contentContext, PathHelper.SEPARATOR + repositoryName); // use pagedList... // resort descending by last modified date pagedList.reSort( SortOrder.DESCENDING, "modifiedDate", null );
You can also use custom sorters and filterers to override the sorting/filtering behavior.
Therefore, if you are expecting to retrieve a large number of query results of a type, such as com.bea.content.Node, then custom sorting and filtering may not be a good option. If you are expecting to issue a narrow query, and retrieve a small number of query results of a type, then custom sorting and filtering may work well.
IPropertyProvider
: This interface allows additional properties to be exposed for a given type, such as adding a 'objectClassName' property for com.bea.content.Node. The extended properties can be used when sorting and filtering. The property provider code can access the entire object, for example, com.bea.content.Node.IPropertyTypeSorter
/IPropertyTypeFilter
: These interfaces allow sorting/filtering support to be added/overridden for individual property types, such as String. The sorting/filtering code has access to only the property value.IPropertySorter
/IPropertyFilter
: These interfaces allow sorting/filtering support to be added/overridden for individual properties, such as the com.bea.content.Node 'name' property. The sorting/filtering code has access to only the property value.IObjectSorter
/IObjectFilter
: These interfaces allow sorting/filtering to be added for entire objects, rather than individual properties. The sorting/filtering code can access the entire object, for example, com.bea.content.Node.
This is done by implementing the Set
The implementation of the getSupportedTypes() method defines which container types you want the custom
support to be applied to. You can either provide a Set of specific container types, such as
com.bea.content.ObjectClass and com.bea.content.Node, or return null, in which case the support will
be added across all container types.
In general, the set of available custom sort/filter implementations are considered together
when sorting/filtering is performed. For example, one IPropertyTypeFilter implementation
might provide the ability to filter Calendar property types, but only implement the
EQUALS and NOT_EQUALS filter methods. Another implementation might provide the GREATER_THAN
and LESS_THAN filter methods for Calendar property types. All four filter methods would be
available for filtering a Calendar property.
The precedence rules are ordered as follows:
For example, the com.bea.content.Node 'name' property of property type String has
standard sorting support, since it is a String, which is Comparable. One could provide
an IPropertyTypeSorter to redefine all String property type sorting to ignore case. In
addition, an IPropertySorter could be provided to sort the 'name' property of Node. If both
were provided, then sorting on the Node 'name' property would use the IPropertySorter
implementation, since it is highest on the precedence order. If another String property
existed on Node, then the IPropertyTypeSorter implementation would be used.
In general, a list of implementations of a given type (such as IPropertySorter) are placed in
the ContentContext with a given context key, and the system will scan through this list as needed
when sorting and filtering, to find the implementations which apply.
For example:
Custom Sorting and Filtering Precedence Rules:
Precedence rules control the order in which custom sorting and filtering implementations are
used, and to allow anything to be overridden. Precedence rules generally only apply when
sorting on properties (as compared to object sorters, which sort on objects).
Using Custom Sorting and Filtering
Once you have implemented a custom sorting or filtering interface, you need to register the
implementation so that you can use it when sorting and filtering. This is done by creating
an instance of the implementation class, and placing it in the ContentContext with a specific key.
// register a property sorter that can sort the Node 'name' property
// ignoring case
ContentContext context= new ContentContext(request);
IPropertySorter customPropSorter= new NodeCustomNamePropertySorter();
List
Overview
Package
Class
Tree
Deprecated
Index
Help
Copyright © 2000, 2009, Oracle and/or its affiliates. All rights reserved.
PREV PACKAGE
NEXT PACKAGE
FRAMES
NO FRAMES
Copyright © 2000, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.