From: Bob H. <ha...@st...> - 2006-08-28 00:30:56
|
Thanks, Toby. Yes, I'd like you and Andrew to look this over and take it on. I've done my part now, I think, to separate the concept of "cml" from "xml" so that we can adapt this in the future. If you see additional ways to streamline that, feel free. As of now: XmlReader takes all XML streams, whether from a file reader or from DOM. This class is responsible for (1) identifying the specific strain of XML to be handled, and (2) pass the responsibility on to the correct format-specific XML reader extension. There are parallel entry points and handler methods for reader and DOM. Each format-specific XML reader then assigns its own handler to manage the parsing of elements. XmlReader.JmolXmlHandler extends DefaultHandler is the generic interface to both reader and DOM element parsing. XmlOdysseyReader extends XmlReader. That one is simple; no need to expand on it at this time. XmlOdysseyReader.OdysseyHandler extends XmlReader.JmolXmlHandler and is generic XmlCmlReader extends XmlReader handles all CML processing XmlCmlReader.CmlHandler extends XmlReader.JmolXmlHandler and is generic XmlMolproReader extends XmlCmlReader. If you feel like expanding on that, feel free. XmlMolproReader.MolprolHandler extends XmlCmlReader.CmlHandler and adds Molpro-specific XML tag processing I'm about to upload this now. XmlCmlReader is where I'd like Andrew to take charge. Please take a look at the implementation of the DOM business and adapt as necessary. Bob Toby White wrote: >Briefly: > >peter murray-rust wrote: > > > >>* Bob will refactor the XML reader and then hand it over to us to >>develop in parallel and return it to Jmol HEAD when appropriate >> >> > >The current state of the XML reader in Jmol is probably mostly >due to me at the moment - I edited it quite heavily about a >year ago (see commit 4250) in order to allow Jmol to retrieve >information from CML embedded in the JS DOM tree of Jmol's parent >XHTML document. A brief look at current SVN suggests not much has >changed since. > >Which is to say - >a) if any refactoring help is necessary, do feel free to grab me. > >b) Some of the code in there is necessary specifically >for reading CML from the JS DOM tree, which may explain some >of the (apparently) odder design choices. In any case, since the >Jmol testsuite currently only knows how to deal with normal >file/string input, the CML-from-JS-DOM functionality isn't >covered by the testsuite - so please don't break it! I'm more >than happy to provide testcases for anyone working on it. > >Toby > > > |