Re: [OT] Thurday afternoon rant

Could you serialize an ExpandoObject? Davy Davy, "So you want to keep data which is local, only ever going to be local, only needed locally, never accessed remotely, not WANTED to be made available outside our building, which can only WEAKEN our security by being off site, hosted offsite." BOFH:

Re: [OT] Thurday afternoon rant

There's also the xsd and XML serialisation so you can deal with clr objects entities. But just use json On Tuesday, April 29, 2014, Greg Keogh wrote: > That piece of code looks so freaking ugly Greg. new XElement("dasdass",new >> XElement( ... )) .. w t f >> > > Hi CIT,

Re: [OT] Thurday afternoon rant

> > That piece of code looks so freaking ugly Greg. new XElement("dasdass",new > XElement( ... )) .. w t f > Hi CIT, that was an ancient post, where have you been, in the bunker writing top secret code for the new fighters? I know you can't answer, or you'll have to kill us. That fu

Re: [OT] Thurday afternoon rant

That piece of code looks so freaking ugly Greg. new XElement("dasdass",new XElement( ... )) .. w t f Why? Why can't we just have a nice clean way of dealing with XML like LINQ or even like Powershell? I agree with Preet. XML is a pain in the **. C'mon Microsoft. You build so man

Re: [OT] Thurday afternoon rant

I forgot to mention how much I also like functional creation of XML. This makes an element with all files in my temp folder that are older than 14 days in descending size: var elem = new XElement("temp", new XElement("files", from f in new DirectoryInfo(Path.GetTempPath()).EnumerateFiles() let

Re: [OT] Thurday afternoon rant

Xml is never the best solution, sometimes it's the only solution though, frequently it's the easiest as well. .02c Davy Davy, "So you want to keep data which is local, only ever going to be local, only needed locally, never accessed remotely, not WANTED to be made available outside our building

Re: [OT] Thurday afternoon rant

> > 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.

Re: [OT] Thurday afternoon rant

Sometimes I feel that good old .ini files with an API to read/write is much more readable and parseable than the XML, at least for configuration. I can appreciate the hierarchical nature of XML, but for configuration it is quite frequently an overkill. On 10 April 2014 17:26, Stephen Price wrote

Re: [OT] Thurday afternoon rant

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 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 Namespac

Re: [OT] Thurday afternoon rant

> > 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 spi

Re: [OT] Thurday afternoon rant

Hey Preet I hate the xml api in .net. I started using json.net to parse xml into a dynamic object. dynamic purchaseOrder = JObject.Parse(JsonConvert.SerializeXmlNode(xDoc.DocumentElement)); dynamic delAddress = purchaseOrder.ShipTo.Detail.DeliveryAddress; var meh = purchaseOrder.BuyerOrderNo; O

[OT] Thurday afternoon rant

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. ARG Oh that an regex :-) -- regards, Preet, Overlooking my bedroom/office wall.