>
> I can appreciate the hierarchical nature of XML, but for configuration it
> is quite frequently an overkill.
>
How keen are you on LINQ to XML? Thanks to XElement I find creating,
saving, loading and reading XML quite convenient these days and often use
an XML fragment as a hepped-up INI file. I like being able to do this:
var elem = new XElement("root", new XAttribute("id", 123), new
XElement("active", true));
And to pull values back out there are casts to help, and casting to a
nullable works in case the node doesn't exist, thereby reducing code
clutter.
int id = (int)elem.Attribute("id");
bool active = (bool)elem.Element("active");
Guid? uid = (Guid?)elem.Attribute("uid");
Greg
>
>
>
> On 10 April 2014 17:26, Stephen Price <[email protected]> wrote:
>
>> Ooops. I seem to have stumbled into the wrong room. This is the
>> ozMedicalComplications list, right?
>>
>> ;)
>>
>>
>> On Thu, Apr 10, 2014 at 2:28 PM, Greg Keogh <[email protected]> wrote:
>>
>>> If there is one technology that drives me nuts every time I have to work
>>>> with it, it's XML, XPATH and associated crapping XML Namespaces.
>>>> Why does everything have to be so bloody painful.
>>>>
>>>
>>> XML isn't as painful as most other current technologies, it's like a
>>> paper cut with lemon juice spilt on it. Whereas trying to overcome security
>>> barriers is like having a kidney stone, or trying to get a fresh checkout
>>> of your solution to build is like a migraine, or trying to write a html5
>>> app is like a spinal prolapse.
>>>
>>> Linq to XML avoids XPATH, but whenever I have to got back to the old XML
>>> model I have to lookup the XPATH syntax and how to add a namespace.
>>> Albihari's C# nutshell book has a couple of pages of "reminders" on old XML
>>> tricks which save a lot of time.
>>>
>>> Greg K
>>>
>>
>>
>
