Hi Andy et al, I'll give the Eclipse refactoring a try though I'm skeptical that it will manage to find and change all the properties etc - I know it has some support for that so just maybe....
In terms of what internal APIs we're using, I guess it depends on exactly what you call internal but to give you some idea (for context we are developing an XML editor, see http://www.ephox.com/product/editliveforxml/ ): * We use Xerces to extract a whole pile of information out of the schema. Given a schema we can construct a valid document "template" for it as well as determine what can be inserted where, what can be removed and a bunch of information about what the user can type into a specific node. * We use a number of DOM Level 3 methods (load/save, normalizeDocument, importNode) but being an applet we can't be entirely sure that the actual DOM level 3 APIs are available particularly easily so we tend to just use the Xerces Impl classes and methods directly. * We make heavy use of schema caching using GrammarPools and then pull them back out again both using Xerces and ourselves so that we can check the definition for specific elements. Things I'd really like to see implemented (both from Xerces and appropriate standards bodies): * Support for interrogating DTDs like we can schemas now (RELAX a bonus). * Transactional DOM. * Support for validating a section of a DOM instead of the entire DOM. Even just being able to validate the value of a particular simple typed node would be sensational. Things I'm planning to investigate in the near future: * The possibility of replacing (or preferably extending) the Xerces DOM implementation to hack in the various things we do when the DOM is changed. For instance when new nodes are added we add a tracking ID so that we can get access to them again later, we also want to update our GUI when changes are made which may either mean changing the values in fields or rerunning an XSLT over the DOM. I think this will provide a noticable speed improvement for our app as it should simplify a fair bit of how we work but more importantly it should allow third party developers to build upon our tool (in a JavaBean edition) and be able to work with a standard DOM interface while still having our application react to changes and keep things in sync properly. * The DOM event notification architecture. I'm not sure how much of this is implemented by Xerces, how well it's finalised in standards and whether or not it's useful to us anyway. * Learn more about the Xerces internals so I know more about what I can achieve. Since I've just been informed that I'm flying off to JavaOne - is there any sessions/events/accessible people I should know about that would help with this? The Xerces team is doing a fantastic job and all your efforts are very much appreciated. Regards, Adrian Sutton. -----Original Message----- From: Andy Clark [mailto:[EMAIL PROTECTED] Sent: Saturday, 19 June 2004 7:24 AM To: [EMAIL PROTECTED] Cc: Adrian Sutton Subject: Re: Changing the Xerces package Adrian Sutton wrote: > Hi all, We've developed an applet that makes heavy use of Xerces, > including it's internal APIs, and would like to avoid problems of Others have already mentioned various refactoring tools so I won't bother adding my two cents on that topic. However... I am very interested in which internal APIs you are using in Xerces. It's rare when we actually hear from people that have used the internal APIs. So I would like to learn about your experience. What worked? What didn't? What was useful? What wasn't? etc. Any information and insight you can provide would help us continue providing functionality that not only works but is what the "customer", like yourself, needs. :) -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
