All Packages from org.enhydra.xml.dom.* to org.enhydra.xml.xmlc.*

Home >> All >> org >> enhydra >> xml

•	org.enhydra.xml.dom.* (8)	•	org.enhydra.xml.io.* (20)	•	org.enhydra.xml.lazydom.* (28)
•	org.enhydra.xml.xmlc.* (158)

Package Samples:

• org.enhydra.xml.dom
• org.enhydra.xml.io
• org.enhydra.xml.lazydom.html
• org.enhydra.xml.lazydom
• org.enhydra.xml.xmlc
• 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

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 ...
• LazyDocument: A DOM Document that supports lazy instantiation of a template DOM. Nodes in the instance DOM are created as accessed. This can be either by traversing the tree or by direct access to a node by id number. Instantiation of nodes in the middle of the virtual tree is support. Thus a node can exist without a parent being expanded. This is used by XMLC, were the dynamic nodes tend to be towards the leaves of the tree. Instances contain a reference to a DOM that is a shared template for the document. Each node in the template is assigned an integer node id that be used to index tables to directly look ...
• LazyHTMLDocument: Implements an HTML document. Provides access to the top level element in the document, its body and title. Several methods create new nodes of all basic types (comment, text, element, etc.). These methods create new nodes but do not place them in the document tree. The nodes may be placed in the document tree using Node.appendChild(org.w3c.dom.Node) > Node.appendChild(org.w3c.dom.Node) 55 or Node.insertBefore(org.w3c.dom.Node, org.w3c.dom.Node) > Node.insertBefore(org.w3c.dom.Node, org.w3c.dom.Node) 55 , or they may be placed in some other document tree. Note: <FRAMESET> documents are not ...
• LazyNode: Interface use to define Lazy DOM methods that apply to every node. In addition to these methods, each node must: Supply a getTemplateXXX for the specific node type. There are two basic interfaces for implementing LazyDOM nodes: LazyNode and LazyParent, with LazyParent extended LazyNode. They have the following properties: Only LazyParent nodes can contain other nodes. Only LazyParent nodes can exist with out their parent being expanded. All children of a LazyParent are expanded if one of the children is expanded. If a LazyNode that is not a LazyParent is expanded, its siblings are expanded. If ...
• 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.
• MkEncodingsTable: Generate a file contain character encodings by parsing the IANA Charset Registry, obtained from: ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets This is a development-time tool, with special hacks to make up for various java encoding names not in the table. The resulting file has the format: name bits mime-name alias1 alias2 ... Where bits is 7, 8 or 16 and mime-name can be "null" if there is none defined. This file will be converted to XML in a future release.
• 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.
• DOMTraversal: Class that traverse a DOM tree or subtree, calling handler methods for each node. It is up to the handler methods to make a decision on processing child and element nodes by explictly calling the methods to continue the traversal. This is gives the handler more control and actually kept the code simpler for both this class and the client. While DOM traversal is straight-forward, traversing the LazyDOM while avoiding expansion made things tricker. This class, and the derived class for the LazyDOM, handles these special cases.
• LazyHTMLElement: Implements an HTML-specific element, an org.w3c.dom.Element that will only appear inside HTML documents. This element extends org.apache.xerces.dom.ElementImpl by adding methods for directly manipulating HTML-specific attributes. All HTML elements gain access to the id , title , lang , dir and class attributes. Other elements add their own specific attributes.
• 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.
• DOMAccess: Method to support accessing the LazyDOM without expanding it. This works both with standard DOMs and LazyDOMs, supporting the development of code that works with either DOM. Most methods come in two flavors, static ones that take the instance document as an argument, an instance methods that use a document contained in an instance of this object. Great care should be used if the return nodes are to be modified, as read-only template nodes maybe returned. These methods also operate on any W3C DOM.
• XMLEntityResolver: A flexable entity resolver for use with parsing XML files. This implements: XCatalog support. Resolving entities from class loaders. Resolving standard URL entities. A debug output stream, useful for debugging resolution problems. A list of class loaders maybe associated with this object. If so an attempt will be made to resolve file: URLs from the class path.
• 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.
• DOMParser: XML parser that parsers to a DOM. This implements the JAXP DOM parser interface plus the following additional features: Control over the Document class that is created. This easily supports building a DTD-specific DOM. Simplified error handling. Finding the initial document via the entity resolver.
• PreFormattedText: Interface that nodes of a document must implement if they have formatted text. Formatted text can be available on: Text nodes - Formatted text is a string with entity references already expanded. Element nodes - Formatted text is the opening tag, with entity references in attribute-values expanded.
• LazyAttrNoNS: Implementation of the DOM Attr that supports lazy instantiation of a template DOM. This version does not support namespaaces. It is used by HTML, where non-standard attributes containing `:' are occasionally invented. If this was derived from AttrNSImpl, it would do validation on the name and generate an error.
• 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.

Home | Contact Us | Privacy Policy | Terms of Service