This class is geared to ease indexing of datamanager2 driven documents.

The user invoking the indexing must have full read permissions to the object, otherwise the NAP or Metadata objects can probably not be loaded successfully.

Basic indexing operation

This class uses a number of conventions, see below, to merge an existing, datamanager2 driven document into an indexing capable document. It requires the callee to instantiate the datamanager2, as this class would have no idea where to take the schema database from.

Additional information is taken out of the Metadata record and the NAP record, both of which have to be available to the indexer.

The RI (the GUID) from the base class is left untouched.

Indexing field defaults:

Unless you specify anything else explicitly in the schema, the class will merge all text based fields together to form the content field of the index record, to allow for easy searching of the document. This will not include any metadata like keywords or summaries.

If the schema contains a field abstract, it will also be used as abstract field for the indexing process. In the same way, fields named title or author will be used for the index document's title or author respectively. The contents of abstract, title and author will also be appended to the content field at the end of the object construction, easing searching over this fields.

If no abstract field is present, the first 200 characters of the content area are used instead.

Not all types can be indexed, check the various types in question about their indexing capabilities. In general, if the system should index any non-text field, it will use the CSV representation for implicit conversion.

Metadata processing is done by the base class.

Document title:

There is no NAP interaction anymore to determine the document title. Therefore, you should either have an auto-indexed title field, or an assortment of other fields manually assigned to index to the title field.

Configurability using the Datamanager schema:

You can decorate datamanager fields with various directives influencing the indexing. See the Datamanager's schema documentation for details. Basically, you can choose from the following indexing methods using the key 'index_method' for each field:

• The default auto mode will use the above guidelines to determine the indexing destination automatically, adding data to the content, abstract, title and author fields respectively.
• You can specify abstract, content, title or author to indicate that the field should be used for the indicated document fields. The content selector may be specified more then once, indicating that the content of the relevant fields should be merged.
• Any date field can be indexed into its own, range-filterable field using the date method. In this case, two document fields will be created actually. One containing the filterable timestamp named directly after the schema field, and a second one, having the _TS postfix which is set as noindex containing the plain timestamp.
• Finally, you can explicitly index a field as a separate document field using one of the five field types keyword, unindexed, unstored or text. You can further control if the content of these fields is also added to the main content field. This is useful if you want to have fields searchable both by explicit field specification and the default field for simpler searches. This is controlled by setting the bolean key 'index_merge_with_content' in the field, which defaults to true.
• noindex will prevent indexing of this field.

The documents type is "midcom_datamanager2".

Be aware that this class is designed to work on datamanager2 instances, not formmanagers, controllers or storage backends. It is also only targeted for the actual database storage backend, so the nullstorage backend will not work.