Instantiating objects from XML

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Instantiating objects from XML

Bernhard Kohlhaas-7
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


pax
Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

pax
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


Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

Osvaldo Aufiero-4
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

Bernhard Kohlhaas-7
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


Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

Bernhard Kohlhaas-7
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


pax
Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

pax
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


Reply | Threaded
Open this post in threaded view
|

Re: Instantiating objects from XML

Bernhard Kohlhaas-7
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