| Home >> All >> org >> enhydra >> xml >> [ xmlc Javadoc ] |
• org.enhydra.xml.xmlc: Javadoc index of package org.enhydra.xml.xmlc.
Package Samples:
• org.enhydra.xml.xmlc.codegen
• org.enhydra.xml.xmlc.commands.options
• org.enhydra.xml.xmlc.commands
• org.enhydra.xml.xmlc.commands.xmlc
• org.enhydra.xml.xmlc.compiler
• org.enhydra.xml.xmlc.dom.generic
• org.enhydra.xml.xmlc.dom
• org.enhydra.xml.xmlc.dom.lazydom
• org.enhydra.xml.xmlc.dom.xerces
• org.enhydra.xml.xmlc.html.parsers.swing
• org.enhydra.xml.xmlc.html.parsers
• org.enhydra.xml.xmlc.html.parsers.tidy
• org.enhydra.xml.xmlc.html
• org.enhydra.xml.xmlc.metadata
• org.enhydra.xml.xmlc.misc
• org.enhydra.xml.xmlc.parsers.xerces
• org.enhydra.xml.xmlc.parsers
• org.enhydra.xml.xmlc.servlet
Classes:
• XMLCContext: Class to facility the use of XMLC in a HTTP servlet. This object contains a XMLC factory to create instances of XMLC document classes and methods to output documents. An instance of this object is associated with the ServletContext object for an application (one per WebApp). The object is created on first use by ( getContext 55 . It provides a factory for creating XMLC document class with optional automatic reloading of out of date classes or recompilation and reloading of classes out-of-date relative to a source file. Also provided are methods to output a XMLC document as a HTTP response, with ...
• XMLCDomFactory: Interface for a factory class that can create DocumentType and Document objects. It also provides document-type specific functions. This is used in implementing subclassed DOMs. Classes implementing this must: Provide a constructor that takes no arguments. Be thread-safe (reentrant is preferred). When a DTD-specific DOM is created, an class implementing this interface must be supplied to XMLC. This would normally be created by extending the XMLCDomDefaultFactory class. This class is designed to be build using a DOMImplementation object. However, since the DOM doesn't specify how DOMImplementation ...
• DOMBuilderGenerator: Class to generate code to build the document tree using only the W3C DOM interface. The document building code is generated in several functions to avoid the JVM limit on maximum method size. Since it is not possible to determine the amount of bytecode generate, a metic is defined called create-cost . A unit of create-cost is approximately the cost to create a node and append it to it's parent. The limit on create-cost is determined experimentally. The following methods can be overridden to provide DOM implementation-specific code generation: genNodeCreate - Generates code to create a node.
• BuildMethodMappings: Class to calculate which elements are to have build methods created for them based on trying to optimize the amount of code (create-cost) in each build methods without overflowing the maximum create-cost. The advantage of this object determining where build methods are created in a seperate traversal from creating the build methods is that the determination is best down from the bottom up, which creating the methods is done top-down. The seperation also keeps the code cleaner and easier to understand. The cost is building an intermediate table.
• DocTypeBuilder: Class for building a DOM DocumentType. Used by XMLC parsers to build a document DOM. Since the DOM level 1 does not address storing all of the information from the DOCTYPE and DTDs required by XMLC, routine are provided to add this information. Only a subset of the information is actually saved. The internal subset is needed to reproduce the DOCTYPE declaration in the compiled document. The attribute declarations from the external subset are needed to build the table of ID attributes used to generate access methods.
• SSIParsedStream: Implements the reading and parsing of an SSI stream. When a SSI directive is encountered, a new instance of this class is created and pushed on a stack. To simplified the implementation, the entire file is read into a buffer. A previous version attempted to buffer less, but this ended up being a bit tricky due to the need to scan while reading and still maintain the block read() method.
• XMLCLogger: Abstract interface for XMLC logging. Implementations of this class allows the XMLC runtime to be integrate with different logging facilities. Three levels of logging are currently used by the XMLC runtime: info logging - Log the occurance of normal events. error logging - Log the occurance of errors. debug logging - Log information useful for debugging the runtime problems.
• Option: Definition of an option. The general or specific options are classes derived from this class. A general class is parameterizes at instantiation and is able to create parse multiple options. A specific class only parses one option. The Option classes should be immutable; a generic client data object is pass to the parse methods to recieve the configuration.
• PreFormatter: Create pre-formatted text for inclusion in template DOM. Save's overhead of formatting the text. This adds character entity references for CharacterData nodes and formats the entire opening tag, with attributes, for elements. The default encoding is used to determine if this is an 7, 8, or 16 bit encoding, and substituting character references as needed.
• SwingParser: Interface to the Swing HTML parser. This attempts to correct problem with using the SWING HTML 3.2 parser to parse HTML 4.0 constructs and well as general bugginess in the Swing parser. The known Swing problems are: Swing 1.1 didn't allow LINK elements in the header. Confusion around end forms (see processEndTagMisMatch),
• TidyErrorHandler: Class for intercepting Tidy error output and doing custom error handing. This is a PrintWrite that overrides all public methods to do our own handling. It parses output looking for errors an warnings and passes them to the XMLC error handler. This is hack, hopefully Tidy.parse will get real error callbacks. It will break if tidy is ever localized.
• ParserAdaptor: Wrapper around the Swing HTML parser that attempts to correct for various problems in different versions of the Swing. This code is tightly bound to the Swing code. This corrects the following problems Swing 1.1: LINK elements were not allowed in the HEAD.
• VarNames: Generate tmp variable names for use in initialization. Keeps a table of tmp variable names used in initialize of nodes. Since nodes are recursive, but the initialization code is an inline block of code, we use this to recycle as many variables as possible, but not clobber ones that are currently in use.
• XMLCDomFactoryCache: Class that provides a cache of XMLCDomFactory objects. Since these classes are simple, they are normally reentrant. This cache provides a mechanism to maintain only one instance of each class. Currently, instances are never freed from this cache. Also creates factories for use at compile-time.
• DocBuilder: Class for building a Document DOM. Used by XMLC XML parsers to build a DOM as well as collect other information about the document. The document builder functions assume they are being called in the order the document is parsed. They keep a current node where new child nodes are appended.
• LazyDOMDocBuilderGenerator: Class to generate code to build the document tree for the Lazy DOM. This creates a static template DOM that is used to instantiate individual nodes. The static template is initialized by a set of methods to get around the method size limitation of doing this as an array initializer.
• HTMLCyberStudioTagSet: Abobe CyberStudio proprietary tags. CyberStudio makes up a bunch of tags it expects to be ignored on display. It uses these for metadata and its all rather tacky. This returns lists of HTMLTagDef and HTMLAttrDef objects. It is not part of the DOM. Objects are immutable and a singleton.
• MetaData: Root element of XMLC metadata. The child elements of this class represent the major sections of the XMLC metadata. Only one instance of a section element object can exist. All sections are created on first reference if they don't exist to make it easy to use them to get defaults.
• XMLCParser: Interface for a class that specifies how to parse an XML file and provide information needed to compile that file into a XMLC object. The object must have a constructor that takes no arguments. The instance of the object will only be use to parse a single document.
• LineNumberMap: Table that keeps a map of character offsets and line count in an input stream to file name and line numbers in source files. This is used to handle mapping of indexes or line numbers in a stream generted by including files to those in the original files.
• DocBuilder: Class for building a Document DOM. Used by XMLC parsers to build a document DOM. The document builder functions assume they are being called in the order the document is parsed. They keep a current node where new child nodes are appended.
• SSIReader: A reader that implements Server-Side Includes (SSI). This used the syntax defined by Apache mod_include, however it only implements the `include' directive. This input stream automatically closes on reaching EOF.
• URLMapping: Specifies the literal replacement of URLs in element attributes. When used in the <domEdits> section, it applies globally to elements. When use in a element or sub-document, it applies only to that context.
• HTMLDocBuilder: Class used by HTML parser to build a DOM. The document builder functions assume they are being called in the order the document is parsed. They keep a current node where new child nodes are appended.
| Home | Contact Us | Privacy Policy | Terms of Service |