Hello,
For a personal project of mine I am trying to load the data from an XML file to instantiate the corresponding Smalltalk object. I have read the comment to the XML DOM package and I was able to read the XML file successfully. Now I am just wondering, how to organize my Smalltalk coding to make this process rather efficient, both in the terms of being reasonably fast and avoiding lots of cut and paste coding. Just to mention a few of the questions that come to mind (coded from memory, so it might not compile): - If I have a class method #fromIXMLDOMNode: to instantiate my object I could see two ways of filling the variable "slots". The first one would be to explicitly search for them: #fromIXMLDOMNode: aNode ^self new id: (aNode selectSingleNode: 'id') text; name: (aNode selectSingleNode: 'name') text; addressFromXMLNode: (aNode selectSingleNode: 'address'); [...] yourself Another option I could is is to have some kind of class dictionary and initialize it in the class-method #initialize : MyXMLDict := LookupTable new at: 'id' put: [:o :xmlNode | o id: xmlNode text ]; at: 'address' put: [:o :xmlNode | o addressFomXMLNode: xmlNode ]; [...] yourself and then iterating over the nodes in the constructor class-method: #fromIXMLDOMNode: aNode | answer block | answer := self new. aNode childNodes do: [ :each | block := MyXMLDict at: each baseName ifAbsent: [ [:o :XMLNnode |] ]. block value: answer value: each ]. ^answer - I am also wondering, if it would be prudent to use special XML factory classes to keep the XML coding separate from the other coding in those classes. I am assuming that I am not the first to encounter those questions and that there are better solutions that I haven't even thought of. So I'd appreciate any pointers and info on how to best approach this (and perhaps even some more problems that I haven't yet encountered). Thanks so much in advance, Bernhard |
Bernhard,
I had a simular situation where I needed to process XML to instantiate objects for my applications. First, writing your own parser is possible, but as you have discovered, it can be intrusive to your domain classes. Second, it is possible that the data format can change over time. This means your code will eventually break. My initial solution was to implement methods that would serialize the domain instances to a stream in XML format. Though this worked well, it was not completely viable as a solution due to the nature of the data. I have since implemented Splash clients with a Spray server running in Dolphin on the server side via Apache and FastCGI. The framework handles the serialization nicely. I only had to implement methods on the class side ie, DomainClass class>>sprayElements... Also, additional comments were added in for server side classes so the factory processes of the framework could generate the appropriate in/out behavior for processing SOAP request. The nicest thing of all is that I was able to drop the MSXML parser... It works, but I was a bit gun shy to have it in the design and production level clients. It may not be what you are looking for, but it could provide you with some answers if you choose to write your own factory processess. Will you just be loading the XML docs from disk, or can the docs be retrieved from a web server? If the latter, have a look at the Spray Web Services Toolkit. Steve Waring has done a fantastic job on the framework and it works very well. http://www.dolphinharbor.org/dh/projects/spray/index.html My project has already seen a number of changes regarding domain classes and it was quite easy to add/remove/modify attributes for classes and regenerate WSDL. Best of all, you get interoperability as well. Best of luck, Pax |
You can use SIXX to serialize, deserialize objects in XML.
http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/ Regards, Osvaldo "Pax" <[hidden email]> escribió en el mensaje news:[hidden email]... > Bernhard, > > I had a simular situation where I needed to process XML to instantiate > objects for my applications. First, writing your own parser is > possible, but as you have discovered, it can be intrusive to your > domain classes. Second, it is possible that the data format can change > over time. This means your code will eventually break. > > My initial solution was to implement methods that would serialize the > domain instances to a stream in XML format. Though this worked well, it > was not completely viable as a solution due to the nature of the data. > > I have since implemented Splash clients with a Spray server running in > Dolphin on the server side via Apache and FastCGI. The framework > handles the serialization nicely. I only had to implement methods on > the class side ie, DomainClass class>>sprayElements... Also, additional > comments were added in for server side classes so the factory processes > of the framework could generate the appropriate in/out behavior for > processing SOAP request. The nicest thing of all is that I was able to > drop the MSXML parser... It works, but I was a bit gun shy to have it > in the design and production level clients. > > It may not be what you are looking for, but it could provide you with > some answers if you choose to write your own factory processess. Will > you just be loading the XML docs from disk, or can the docs be > retrieved from a web server? If the latter, have a look at the Spray > Web Services Toolkit. Steve Waring has done a fantastic job on the > framework and it works very well. > http://www.dolphinharbor.org/dh/projects/spray/index.html > > My project has already seen a number of changes regarding domain > classes and it was quite easy to add/remove/modify attributes for > classes and regenerate WSDL. Best of all, you get interoperability as > well. > > > Best of luck, > > Pax > |
Osvaldo Aufiero wrote:
> You can use SIXX to serialize, deserialize objects in XML. > http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/ Unfortunately the XML data I need to build my objects from is created by a 3rd party application. Therefore I assume that SIXX won't work, since it appears to require an XML stream that was created by Smalltalk, correct? Thank you nevertheless for this pointer, as I am sure that sooner or later I WILL need to save and reload my own XML streams. Bernhard |
In reply to this post by pax
Pax,
Thank you for your detailed response, > I had a simular situation where I needed to process XML to instantiate > objects for my applications. First, writing your own parser is > possible, but as you have discovered, it can be intrusive to your > domain classes. Second, it is possible that the data format can change > over time. This means your code will eventually break. At this point in time I am considering a class MyXMLObjectFactory and one subclass for each domain class that that I want to create instances out of XML code. > My initial solution was to implement methods that would serialize the > domain instances to a stream in XML format. Though this worked well, it > was not completely viable as a solution due to the nature of the data. The XML stream comes from a 3rd party application via file, so I have no contol over the format. It is a database of audio tracks and also contains also redundant information that I will need to consolidate, i.e. for each track it stores the artist name, however I only want to have one Artist object per name. > I have since implemented Splash clients with a Spray server running in > Dolphin on the server side via Apache and FastCGI. The framework > handles the serialization nicely. I only had to implement methods on > the class side ie, DomainClass class>>sprayElements... Also, additional > comments were added in for server side classes so the factory processes > of the framework could generate the appropriate in/out behavior for > processing SOAP request. The nicest thing of all is that I was able to > drop the MSXML parser... It works, but I was a bit gun shy to have it > in the design and production level clients. So was your problem more in the area of serialization or de-serialization? > It may not be what you are looking for, but it could provide you with > some answers if you choose to write your own factory processess. Will > you just be loading the XML docs from disk, or can the docs be > retrieved from a web server? If the latter, have a look at the Spray > Web Services Toolkit. Steve Waring has done a fantastic job on the > framework and it works very well. > http://www.dolphinharbor.org/dh/projects/spray/index.html My XML docs will come from disk. After a very rough peek at Spray it seems though that it requires a certain document style. Unfortunately the document that I am parsing doesn't adhere to such a standard. But I'll check out Spray nonetheless. Best Regards, Bernhard |
Bernhard
> At this point in time I am considering a class MyXMLObjectFactory and > one subclass for each domain class that that I want to create instances > out of XML code. This is a good way to do it. Your subclasses will contain the custom behavior needed to de-serialize the data from the XML file. Not to worry about the MSXML parser. Earlier versions were buggy, but the current version (4.0 I believe) is solid. Though I have limited experience with it, I encountered no problems. > So was your problem more in the area of serialization or de-serialization? My problem concerned both serialization/de-serialization. Initially, I started off with the MS XML parser and wrote custom code to handle these processes. But, the customer added a requirement which dictated that the data be Interoperable... So, i had to throw away the custom xml parsing code and implement Spray/Splash. But, my initial design with the MSXML engine and customized parsing code worked very well. One thing you might consider is to make your XML parsing behavior pluggable for runtime execution. You could load binary packages at runtime into the image. So, if the data format or attributes change in the future, you will have to integrate the changes, test and deploy a new binary package. One package for each XML parsing process that has changed. If no changes are anticipated/foreseen, just deploy a standard exe. Pax |
Pax,
>>At this point in time I am considering a class MyXMLObjectFactory and >>one subclass for each domain class that that I want to create instances >>out of XML code. > > This is a good way to do it. Your subclasses will contain the custom > behavior needed to de-serialize the data from the XML file. Not to > worry about the MSXML parser. Earlier versions were buggy, but the > current version (4.0 I believe) is solid. Though I have limited > experience with it, I encountered no problems. Thanks, it's good to know that my approach doesn't look doomed from the start. ;) > My problem concerned both serialization/de-serialization. Initially, I > started off with the MS XML parser and wrote custom code to handle > these processes. But, the customer added a requirement which dictated > that the data be Interoperable... So, i had to throw away the custom > xml parsing code and implement Spray/Splash. But, my initial design > with the MSXML engine and customized parsing code worked very well. So can you parse any XML format with Spray/Splash? At a first glance they seemed to require their own specify format. That is of course fine, if your own software generates the XML document, but less so, when a 3rd party app does it. > One thing you might consider is to make your XML parsing behavior > pluggable for runtime execution. You could load binary packages at > runtime into the image. So, if the data format or attributes change in > the future, you will have to integrate the changes, test and deploy a > new binary package. One package for each XML parsing process that has > changed. If no changes are anticipated/foreseen, just deploy a standard > exe. That is a good idea, though for the sake of simplicity, I'll defer this to later point. Or are there some design decisions to consider right now, to ensure that pluggability is easy to implement later? Are there any how-to guides or is there any sample coding to demonstrate how to create pluggable binary packages and how to load them in an app? Thank you very much for your feedback and Best Regards, Bernhard |
Free forum by Nabble | Edit this page |