Database Reference
In-Depth Information
Figure 16-6. Document trigger SAX pipeline
Having to implement
ContentHandler
and
LexicalHandler
brings some complexity
to document triggers, so for convenience eXist offers the abstract class
org.exist.collections.triggers.FilteringTrigger
to reduce this. It is recom‐
mended that you always extend
FilteringTrigger
and never directly implement
Doc
umentTrigger
in your own triggers.
FilteringTrigger
provides default
implementations of both
ContentHandler
and
LexicalHandler
by simply forwarding
the SAX events to either validation or storage. If you are only interested in working
with the
before
and
after
document events, by extending
FilteringTrigger
you need
not ever worry about the SAX events. Conversely, if you are interested in the SAX
events for the purpose of modifying the document, additional validation, or some
other reason, by extending
FilteringTrigger
you can just override those SAX meth‐
ods of interest, while the remainder will be handled correctly.
If you choose to override the SAX event methods in
Filtering
Trigger
and you still want the event to be passed on to the data‐
base for validation or storage, then you must remember to call the
equivalent method on the
super
class. If you do not call the
method on the
super
class, your trigger is actually discarding those
events and they will never reach the database!
When dealing with SAX events in a document trigger you must recognize that the
trigger is called
twice
, once during each of eXist's two phases of storing a document:
Validation
As the entire document is being parsed, the generated SAX events are sent to
your trigger, which is responsible for swallowing or forwarding them (with or
Search WWH ::
Custom Search