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 many cool things, why not a dead-easy XML handler for C# for both reading and creating/writing? On Thu, Apr 10, 2014 at 6:37 PM, Greg Keogh g...@mira.net wrote: 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 daysOld = DateTime.Now.Subtract(f.CreationTime).TotalDays where daysOld 14.0 orderby f.Length descending select new XElement(file, new XAttribute(length, f.Length), new XAttribute(daysOld, daysOld.ToString(0.0)), f.Name))); On 10 April 2014 18:03, Greg Keogh g...@mira.net wrote: 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 step...@perthprojects.com 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 g...@mira.net 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
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 functional XML / LISPish like code isn't so bad if you format it carefully. I try to line-up the parentheses vertically to help me when it gets long (unlike my terse example). Authors of some languages tend to love writing impenetrably ugly functional code. Some languages tend to produce code that only looks impenetrably ugly! GFK
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 g...@mira.net wrote: 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 functional XML / LISPish like code isn't so bad if you format it carefully. I try to line-up the parentheses vertically to help me when it gets long (unlike my terse example). Authors of some languages tend to love writing impenetrably ugly functional code. Some languages tend to produce code that only looks impenetrably ugly! GFK
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: Simon Travaglia On Tue, Apr 29, 2014 at 3:05 PM, Michael Ridland rid...@gmail.com wrote: 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 g...@mira.net wrote: 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 functional XML / LISPish like code isn't so bad if you format it carefully. I try to line-up the parentheses vertically to help me when it gets long (unlike my terse example). Authors of some languages tend to love writing impenetrably ugly functional code. Some languages tend to produce code that only looks impenetrably ugly! GFK
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 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
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 g...@mira.net 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
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 step...@perthprojects.com 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 g...@mira.net 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
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. 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 step...@perthprojects.com 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 g...@mira.net 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
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, which can only WEAKEN our security by being off site, hosted offsite. BOFH: Simon Travaglia On Thu, Apr 10, 2014 at 10:03 AM, Greg Keogh g...@mira.net wrote: 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 step...@perthprojects.com 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 g...@mira.net 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
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 daysOld = DateTime.Now.Subtract(f.CreationTime).TotalDays where daysOld 14.0 orderby f.Length descending select new XElement(file, new XAttribute(length, f.Length), new XAttribute(daysOld, daysOld.ToString(0.0)), f.Name))); On 10 April 2014 18:03, Greg Keogh g...@mira.net wrote: 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 step...@perthprojects.com 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 g...@mira.net 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
[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.
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; Only problem is that it doesn't know if something is meant to be an array so I had to do this. if ((stockItems as JContainer).Type == JTokenType.Array) foreach (dynamic stockItem in purchaseOrder.StockList.StockItem) AddStockLine(stockItem, linesToReturn); else AddStockLine(stockItems, linesToReturn); On Thu, Apr 10, 2014 at 3:16 PM, Preet Sangha preetsan...@gmail.com 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. ARG Oh that an regex :-) -- regards, Preet, Overlooking my bedroom/office wall.
