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