XML setting - I can do this better?

[jodleren]

Hi

As you might now, I am new to all this, therefore I ask - there must
be a better way than this?

I have created an XML file for holding settings. Saving data to it
looks as follows. But is is big, and there probably is a better way to
check items etc:

My XML

<root>
<ComPort>COM5</ComPort>
<HostAdr>99</HostAdr>
</root>


XmlDocument doc = new XmlDocument();
string s =
Path.GetFileNameWithoutExtension(Application.ExecutablePath) + ".xml";
if (File.Exists(s))
{
doc.Load(s);
}
if (ReadSettings(ref doc, "HostAdr", "N/A") == "N/
A") *****
{
XmlElement root;
if (doc.DocumentElement.Name == "root")
{
root = doc.DocumentElement;
}
else
{
root = doc.CreateElement("root");
doc.AppendChild(root);
}
XmlElement elem =
doc.CreateElement("HostAdr");
root.AppendChild(elem);
XmlText text =
doc.CreateTextNode(v.ToString());

doc.DocumentElement.LastChild.AppendChild(text);
}
else
{
for (int i = 0; i <
doc.DocumentElement.ChildNodes.Count; i++)
{
if
(doc.DocumentElement.ChildNodes.Item(i).Name == "HostAdr")
{

doc.DocumentElement.ChildNodes.Item(i).InnerText = v.ToString();
break;
}
}
}
doc.Save(s);

**** this is :

private string ReadSettings(ref XmlDocument doc, string item,
string defaultvalue)
{
try
{
for (int i = 0; i <
doc.DocumentElement.ChildNodes.Count; i++)
{
if (doc.DocumentElement.ChildNodes.Item(i).Name ==
item)
{
return
doc.DocumentElement.ChildNodes.Item(i).InnerText;
}
}
}
catch
{
}
return defaultvalue;
}

 

[Registered User]

Hi

As you might now, I am new to all this, therefore I ask - there must
be a better way than this?

I have created an XML file for holding settings. Saving data to it
looks as follows. But is is big, and there probably is a better way to
check items etc:

I would create a plain old C# object to hold the settings and use XML
serialization for persistence. See Introducing XML Serialization

http://msdn.microsoft.com/en-us/library/182eeyhh(v=VS.85).aspx

regards
A.G.

 

[Arne Vajhøj]

As you might now, I am new to all this, therefore I ask - there must
be a better way than this?

I have created an XML file for holding settings. Saving data to it
looks as follows. But is is big, and there probably is a better way to
check items etc:

My XML

<root>
<ComPort>COM5</ComPort>
<HostAdr>99</HostAdr>
</root>

Yes - it can be done a lot simpler using XPath:

XmlDocument doc = new XmlDocument();
string s =

Path.GetFileNameWithoutExtension(Application.ExecutablePath) + ".xml";

doc.Load(s);

string comport = doc.SelectSingleNode("//root/ComPort/text()").Value;
int hostaddr =
int.Parse(doc.SelectSingleNode("//root/HostAdr/text()").Value);

Have you considered using the built in app setting functionality?

Arne

 

[Arne Vajhøj]

I would create a plain old C# object to hold the settings and use XML
serialization for persistence. See Introducing XML Serialization

http://msdn.microsoft.com/en-us/library/182eeyhh(v=VS.85).aspx

If the file is to always be written by program then XML
serialization is a good option.

If it is to be manually edited, then I would not recommend
XML serialization.

Arne

 

[Arne Vajhøj]

As you might now, I am new to all this, therefore I ask - there must
be a better way than this?

I have created an XML file for holding settings. Saving data to it
looks as follows. But is is big, and there probably is a better way to
check items etc: [...]

As A.G. says, it is possible to use .NET's own serialization APIs to
create XML from your data. In my experience it can get a bit frustrating
if and when you start needing to deal with special scenarios;
customization isn't as well-documented as it could be and it can
sometimes be difficult to figure out the magic incantation. But it can
be done and for simple data it works well.

The key question is whether the setting will be written by a program
or edited manually.

Programs can live fine with how XML serialization works by default.

• First, you might want to look at the XML API in System.Xml.Linq. It's
specifically designed to work well with LINQ, supporting enumeration,
filtering, and composition of enumerated objects directly. But those
features also make it a nice API to work with generally, even if you
aren't specifically using LINQ.

XPath is usually bot shorter code and it standard based.

Unless one get paid per character in the source code, then
I can not see any reason to prefer LINQ to XML over XPath
for selecting data.

Surprisingly XDocument can be a lot better than XmlDocument for
creating XML documents.

If you do decide you need to do your serialization manually (and that's
not unheard of…more than once I've thrown up my hands in frustration
trying to get .NET's serialization APIs to do exactly what I want ),
I hope the two comments above will help you see how to write the code in
a cleaner, more concise way.

The most obvious solution to me would be to use the
app settings support built in to .NET.

Arne

 

[Arne Vajhøj]

If you are trying to replicate the convoluted implementation the OP
showed, I can imagine XPath could be more concise.

????

I find it a bit difficult to connect your ">>>" comments and ">"
comments!

Arne

 

[Arne Vajhøj]

Probably because you didn't bother to read my original reply as a single
unit, instead picking out the parts you felt you could disagree with out
of context.

So when you write "First, you might want to look at the XML API in
System.Xml.Linq" you don't really mean it which should be clear from
the context.

The context being the parts not being quoted:

#As A.G. says, it is possible to use .NET's own serialization APIs to
#create XML from your data. In my experience it can get a bit
#frustrating if and when you start needing to deal with special
#scenarios; customization isn't as well-documented as it could be and
#it can sometimes be difficult to figure out the magic incantation.
#But it can be done and for simple data it works well.

#Second, I would not mix serialization with deserialization. That is,
#when writing XML (creating the XML document, whether writing straight
#to a file or creating an in-memory model as your code does), there's
#no reason to read XML, and vice a versa. Your code should serialize
#by just generating the XML with no consideration of what was ever
#generated previously. And should deserialize (i.e. recreate the
#in-memory objects) by simply reading the XML that's there.

#If you do decide you need to do your serialization manually (and
#that's not unheard of…more than once I've thrown up my hands in
#frustration trying to get .NET's serialization APIs to do exactly what
#I want ), I hope the two comments above will help you see how to
#write the code in a cleaner, more concise way.

Exactly what from above clarified that you did not suggest
LINQ to XML?

Arne