[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX2: Namespace Processing and NSUtils helper class
On a related topic: I like what Ray is saying because it lays the foundation for a missing higher level abstraction to SAX. What we and just about everyone else using SAX have developed is an in-house HandlerBase dispatcher class that acts as a giant switch, doling out events based on element names (a common pattern in many different types of processes). Now with namespaces, we effectively have a two-layer! switch that will be continually developed independently in the XML community! To address this, I propose adding a higher level utility provided as part of SAX2 named ElementDispatcherBase. For those who have philosophical differences with this approach, I am proposing that we compliment the current monolithic handler feature of SAX. The interfaces required would be along the lines of: public interface SAX2ElementHandler { public void startElement(Attribute[] attrs) throws SAXException; public void endElement() throws SAXException; } public interface SAX2DefaultElementHandler { public void startElement(String nameSpace, String elementName, Attribute[] attrs) throws SAXException; public void endElement(String nameSpace, String elementName) throws SAXException; } public interface SAX2ElementDispatcher extends SAX2DocumentHandler { /** * Default element handler, effectively the SAX status quo */ public void addDefaultElementHandler(SAX2DefaultElementHandler hndlr); /** * Handle element in all namespaces */ public void addElementHandler(String elementName, SAX2ElementHandler hndlr); /** * Handle element in this namespace only */ public void addElementHandler(String nameSpace, String elementName, SAX2ElementHandler hndlr); public void removeDefaultElementHandler(SAX2DefaultElementHandler hndlr); public void removeElementHandler(String elementName, SAX2ElementHandler hndlr); public void removeElementHandler(String nameSpace, String elementName, SAX2ElementHandlerNS hndlr); /* remove by name only? */ } The normal use of the interfaces should be straightforward. There maybe some concern over elements that are closely related and have almost identical processing that is differentiated by name. The standard Java technique of using inner classes to register unique, one-liner, mini-handlers would work well in most of those cases; or the default handler could be invoked -- the equivalent of today's big switch (or hopefully, home-grown dispatcher :). Note that handlers are removed by name as well as object-identity, allowing for the handling multiple differently identified elements by the same handler [if you removed by object-identity only, and you had registered for multiple elements, removal would probably not do the right thing]. Regards, Les Hill Senior Architect Excelergy ======================================================= Excelergy is hiring Java/C++ XML developers, all levels send resume (and mention me :) to jobs@e... ======================================================= Ray Waldin writes: >For example: > ><element1 xmlns="uri1" xmlns:p2="uri2"> > <ns2:element2 foo="bar" xmlns:p3="uri3" p3:whiz="bang"/> ></element1> > >would produce the following stream of events: > > startDocument(); > startNamespace( prefix=null, uri="uri1" ); > startNamespace( prefix="p2", uri="uri2" ); > startElement( name="element1", attrList=null ); > startNamespace( prefix="p3", uri="uri3" ); > startElement( name="p2:element2", attrList={ foo="bar", p3:whiz="bang" }); > endElement( name="p2:element2" ) > endNamespace( prefix="p3" ); > endElement( name="element1" ); > endNamespace( prefix="p2" ); > endNamespace( prefix="p1" ); > endDocument(); > >Simple management of these namespaces can be provided for in some helper class like the >NSUtils example, and can even be handled automatically for the most part in a new >HandlerBase2 class, but this decision of how (or whether) to handle namespaces could be >left to the application author. Anyone else feel this way? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|