[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Storing application state as XML
We went through the same process as you: having used MFC serlialization, XML sounded like it had various advantages. We adopted XML, but use an event-driven parser instead of the DOM. This has the benefits of speed + code size. Being event-driven tends to force you towards a one-pass process when reading the application state in - but that's generally a good fit for serializing application state. We simply stopped callng MFC's open/save CArchive stuff, and called our own routines. For input (which must be parsed), we use expat (from James Clark) built in a DLL with a small C++ wrapper to make life easier. The wrapper class represents an "add-in" to any class to make it XML-parsing capable. The wrapper also permits one XML-parsing class to pass responsibility to another class (ie I maintain a stack of handlers). This facilitates (eg) my <person> element handler to pass control to a <address> element handler whenever it spots an address. By and large, one class deals with one element type, but that's not a hard and fast rule. For output, we implemeted a simple output stream that formats element names, formats various types of attributes, converts '<' to literals, converts from ANSI to utf8, etc. Typically, a class name equates to an element, a class data member equates to an attribute. We haven't (yet) used element content at all. Nothing religious - it just never seemed appropriate. When opening a file, we tolerate quite a lot (eg someone could add attributes/elements that we'll ignore). To conserve file space, we normally write files in "compact" mode, where only attributes that differ from the default setting (ie the constructor initialised setting) get saved. This saves oodles of disk space. A "verbose" mode is also available where everythig gets saved. There are alternatives to expat, but expat offers everything we need at present. An alternate C++ wrapper class can be found at http://www.oofile.com.au/ I'd be glad to go into details of this stuff (including sharing the code). I suspect it would make a nice little article for somewhere like www.codeguru.com, but (like most folk) I can never find the time. Steve Kearon FineLine Software -----Original Message----- From: Ketil Z Malde <ketil@i...> To: XML-Dev Mailing list <xml-dev@i...> Date: 17 June 1999 12:06 Subject: Storing application state as XML > >Hi, > >I must admit I don't have the time to follow this list as diligently >as I'd like, so it is possible that my questions have been answered >already. I'll submit them nevertheless. :-) > >We have a rather complex application which stores its state using the >standard MFC serialize stuff (well, actually a somewhat hacked >version, but that's beside the point). Now, this limits our freedom >in (or at least severely complicates) redesigning internal class >structure while maintaining backwards file compatibility, and we've >been pondering an XML format instead. > >There are of course other advantages, like accessing the information >from other applications, or generating HTML and whatnot. > >The question is whether this, in general, is a good idea, and whether >people have done this, and if so, to what degree of success, and by >what methods. > >I can see two ways of doing this: > >1) Use a DOM-based document, which can be passed around, much the way >a CArchive class is, and modifying the Serialize() to fill in the >relevant nodes in the document tree > > or > >2) Encapsulating the document (DOM or otherwise) in a separate class, >which traverses the application's classes and picks whatever >information is relevant in whatever sequence it desires. > >The advantage of model 1 is a structure quite similar to what already >exists, most of the code base could be left alone, I think. > >On the other hand, if our existing classes are well designed, all the >relevant information should be accessible through the public: >interfaces, and it should be easier to build the document in a >flexible way. E.g. the placement of various information might not be >obvious from the class' perspective. > >So, before we jump the gun, I'd like to hear from people who have done >this, and are willing to share their experiences, or otherwise >contribute suggestions and ideas. > >Thanks for listening, > >-kzm >-- 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 (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe 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
|