Two important categories of consumers include filters, which * process events and pass them on to other consumers, and terminus * (or terminal) stages, which don't pass events on. Filters are not * necessarily derived from the {@link EventFilter} class, although that * class can substantially simplify their construction by automating the * most common activities. * *
Event consumers which follow certain conventions for the signatures * of their constructors can be automatically assembled into pipelines * by the {@link PipelineFactory} class. * * @author David Brownell * @version $Date: 2002/09/30 15:08:52 $ */ public interface EventConsumer { /** Most stages process these core SAX callbacks. */ public ContentHandler getContentHandler (); /** Few stages will use unparsed entities. */ public DTDHandler getDTDHandler (); /** * This method works like the SAX2 XMLReader method of the same name, * and is used to retrieve the optional lexical and declaration handlers * in a pipeline. * * @param id This is a URI identifying the type of property desired. * @return The value of that property, if it is defined. * * @exception SAXNotRecognizedException Thrown if the particular * pipeline stage does not understand the specified identifier. */ public Object getProperty (String id) throws SAXNotRecognizedException; /** * This method provides a filter stage with a handler that abstracts * presentation of warnings and both recoverable and fatal errors. * Most pipeline stages should share a single policy and mechanism * for such reports, since application components require consistency * in such activities. Accordingly, typical responses to this method * invocation involve saving the handler for use; filters will pass * it on to any other consumers they use. * * @param handler encapsulates error handling policy for this stage */ public void setErrorHandler (ErrorHandler handler); }