I have set up my REST service and it works fine. This is the response that I get from the service is shown in the figure:
How can I parse this type of request in my WPF application?
The response you have there is seemingly an XML structure that contains publisher information. As for parsing it you have a number of options however all of these require/prefer you to have the schema for the resulting XML.
Use the Visual Studio XSD tool to create schema classes in your project. Once you have these you can then deserialise the XML into an object. You can then use the object within your WPF application.
Use XmlDocument to load the XML then use xPath queries to extract the data you need.
Use XDocument (linq to XML) to load the XML then use LINQ style queries to extract the data you need.
Personally, I would use option 1 - It does require a schema (the other options don't technically need one) but it does give you objects which IMHO are much easier to maintain and use than xpath/linq queries.
It is also worth mentioning that depending on how the service reference was added to the client (and how the service exposes itself) you may already have this XML class bound into the client service reference. As an example you service reference in the client may allow you to do this:
PublisherInfo pi = myServiceClient.GetPublisherInfo();
In which case all the conversion from XML to PublisherInfo is handled for you. I am guessing that the sample XML above was obtain by calling the service in a browser, therefore the conversion to PublisherInfo obviously doesn't happen as this would occur within the client code.
Well, there are a number of ways. You could use XmlReader, load it into an XmlDocument, and more.
The former of those options exposes a constructor that accepts an input stream and an XmlReaderSettings instance.
But how is this response returned? If you showed us some code, or provided a little more information then you might find we have different approaches that are more appropriate.
Why do you need to parse it, why don't you use the classes generated by Visual Studio when you add the reference of your service to the WPF project?
If you really want to parse it, use the Xml libraries mentioned in the other answers
Related
I am trying develop a website which provide user interface to generate XML file. The user interface will ask for data required in various XML elements. The generate XML should follow DTD specifications.
So here is what I did.
I converted DTD to XSD.
I created C# class using xsd.exe tool.
Now my question is how can I generate dynamic input boxes on the webpage that will ask for required element data from the C# class I created.
I need some way to know the required and optional elements and their data type and attribute and all from the C# class I created.
i hope you get what i am asking, thanks for looking.
Keep in mind that most of the required/optional semantics from the xsd are lost in the classes generated with xsd.exe. You basically have 2 (+1 edited later ) options:
Use reflection over your generated types to render UI elements for each property. You'll have to manually manage/define databindings
Drop the xsd.exe classes and generate your UI elements by traversing the xsd itself. That way you get way more info about optional/nullable elements, cardinality etc. Construct your resulting xml by hand (use XDocument) from your UI inputs.
The hybrid approach: Reflect over generated classes for structure (easier traversal logic. no need to handle external includes etc). Go to the xsd for the additional info (You'll need to somehow figure out where in the xsd to find your needed definitions that map to the current property)
Either way you choose this will not be a trivial task and you'll need a lot of work to make it happen. And if we're going in the realm of XSD choice elements etc. you'll soon figure out that no straight forward UI can cover all the possible scenarios
I'm new to REST and this sounds like it should be pretty simple. In a .NET app, I can create a reference to a WCF service and the contracts for all the available types will be generated for me.
Now I'm trying to consume a REST service in a Windows Phone 7 app. While I can make my call and get back the proper response, is there a simple way to create the classes that each object would be deserialized to?
I'm using RestSharp to manage my calls. In some examples I've seen, user's have created their own classes, and generated the xml manually. I would like to avoid this if at all possible.
many thanks!
Assuming your response is XML, you can save the xml into a file, then call xsd.exe on it to generate a schema. Call xsd.exe on the schema and it will generate a c# class file you can seriazlize and deserialize to from the xml. Here's the documeantion on how XSD.exe works:
http://msdn.microsoft.com/en-us/library/x6c1kb0s(v=VS.100).aspx
You have to generate the classes that your response data will map to (or use a dynamic deserialization scheme if you're on .NET 4) since REST does not include a schema definition system the way SOAP does. In RestSharp, there's a T4 helper to make generating the C# classes easier. It gets you about 80% of the way there. If you need any help with it, post to the RestSharp Google Group.
Is there a pattern, Xml structure, architecture technique we can use to create simple data holder class code that we can deserialise to/from and do that at runtime?
We're in the early design stage of a .Net project and one of our goals is to make the resulting system extensible through configuration without needing a developer. We need to support new sources of data, typcially delivered as Xml messages. Currently we convert/deserialise the messages into simple classes and then use an already existing language which can manipulate those classes as we need.
That works well when you have a developer to map the Xml to simple class, create the class and then write the deserialisation, but it's not extensible for for an administrator. Our target user audience is high end DBA and/or network admin - people who can handle Xml but may not know C#.
You don't have to write any classes or deserialization routines. If you have a schema, you can use the XSD.exe tool from Visual Studio to automatically make Classes, and use built in .NET XML Serialization/Deserialization.
Now how to have that happen without a recompile each time...
It's not ideal, but this should work:
Assume your DBA can write a schema for the XML.
You could write a tool that takes the schema, runs it through XSD, Add's some wrapper code on top of it, and creates a dll which can be used from within your application.
This could be a manual process (ie the admins email you the schema) or you can distribute the tool as part of your application.
Also, you can infer a schema from an existing XML document.
Perhaps DataTable? Or just use an xml DOM (XmlDocument or XDocument) as data-storage? Neither is ideal, of course - but there is little point creating a type at runtime just for this if your real code will ever see it. What purpose would the extra class type serve? Among other issues you'd have to use lots of reflection just to talk to it.
The other option is a custom property-bag and IXmlSerializable, but that is effort.
Our system stores XML strings in a database. I've recently had to change the Properties on a Class, and now when an XML string gets deserialized it will throw an exception. What is the best way to handle this change? Look for the Node in the application code using XPATH or LINQ, or change the xml string in sql database (ie do a mass update)?.
You might want to look at writing a custom XML deserializer (i.e. implementing IXmlSerializable, see here) to handle changes in your XML. If you've invested a lot of time into crafting your XML serialization attributes, you may want to look at another approach.
Consider batch-upgrading your XML, or deprecating (instead of removing) properties inside of your classes and mapping older behavior to newer behavior.
Longer term, you will want to come up with a strategy for dealing with this in the future, since you will most likely be continue to make changes to your schema/object definitions as you add/change the functionality of your system.
if you serialize the objects to the database you could try the approach I outlined here to load the old versions into a new version then when you save the new version will be saved. Not sure if having different versions of your class will be appropriate though...
Basically you create a factory to produce your objects from the xml. everytime you change your object you create a new factory and a new object class, which is given a version of the old class in its constructor and it creates itself from the old class. The new factory tries to create a new object from the xml, if it can, happy days, if it can't then it creates a new object and tells the next oldest factory to create a next oldest object from the xml. These factories can then be chained together so that you can always load a newest version of the objects from whatever data is in the db.
This assumes that its possible to always create a valid v2 object from a v1 object.
It's a good practice to store a version along your XML strings. Either at the database level or at the class level so that your code knows which version of the class it has to deserialize.
You might also look at XSLT. It allows you to transform one version of XML into another.
In that case the logic to go from one version to another is not handle by code but by the XSLT. You can even store the XSLT into the database which makes it reusable by other programs.
I have XML files in a directory that I wish to get over to a webservice on a server that will validate them and return a true/false as to whether they are valid in construct and values etc.
Reason for server side processing is that the validation rules may change from time to time and need to adjust in one place as opposed to all client machines.
What would be the best mechanism to do this?
At the moment am wondering if passing the XMLDocument object from the client to the webservice as a parameter may be the way to go?
Am using .net 3 for this in C#
You might consider using something like a WCF service and streaming the xml up using the GZipStream. I am doing something similar to this and it is working pretty well.
Wouldn't a normal string be enough? It's overkill to serialize / deserialize an entire XDoc instance in my opinion. Of course, you can also zip the entire thing to reduce the size of the requests.
Depending on your validation rules, it might be more sensible to encapsulate them in something like an XML schema hosted on a public URL.
That way, clients can validate against the schema in one line of code, rather than having to connect to a web service.