61–70 of 77 posts
But as far as the OP, this seems like a case of worrying about the code instead of the data structure. This would be easier to address before the lines are transformed into HTML. Which I assume is not how they are stored.
"This is a perfectly reasonable solution, but it's a whopping 11 lines of code. Further, it feels like we're using the wrong tool for the job: why are we using Ruby iterators and conditionals to get at DOM nodes?" Is it really that bad to have 11 lines in Ruby? Initially I didn't get the wrong tool part but after reading it all that did make more sense. I haven't used XPath more than a few times and they were pretty…
If you think 11 lines of code is a lot, you're overly focused on concision at the expense of readability. I've never (read: never) worked on any Ruby code, yet I find the posted example more readable than the supposedly more valuable xpath.
At the very least, they're the same. If you're writing code in Ruby, 11 lines is nothing. If you're writing code in Ruby and xpath is used nowhere else in the project, that single line of super-compact xpath might as well be 1000 lines of Ruby -- it doesn't matter.
If you're trying to compact 11 lines of code you're probably doing it wrong.
Earlier quoted context omitted.
I think you are thinking of "//", which acts like the space (ie: any number of children).
No, that's just a difference in default axis. I mean that `/` is a separator between traversal expressions, much like whitespace in CSS selectors.
> it's a whopping 11 lines of code. If you think 11 lines of code is a lot, you're overly focused on concision at the expense of readability. I've never (read: never) worked on any Ruby code, yet I find the posted example more readable than the supposedly more valuable xpath. At the very least, they're the same. If you're writing code in Ruby, 11 lines is nothing. If you're writing code in Ruby and xpath is used nowh…
Then there was XSLT, which was a pretty sweet way to turn a data format into a variety of "print" or "display" formats. Definitely been replaced by bigger and better things but it's a pretty awesome technology that does one thing really well.
XML gets a bad rap because of how much prettier JSON is, but there are a lot of cool tools associated with it. XPath is pretty awesome, I had to write a XPath parser/executor once (for a class) and it made me appreciate the value and simplicity. Then there was XSLT, which was a pretty sweet way to turn a data format into a variety of "print" or "display" formats. Definitely been replaced by bigger and better things b…
> But it gets more interesting if the lyrics are stored as an HTML fragment. Is there any reason to store the HTML version with s and s instead of a plain text and converting it to HTML with simple rules à la markdown? (single line break = , double line break = )
Well, at a minimum, it saves the processing time required to format the text, which lessens the server cost of each page hit. It's a small optimization, but when the vast majority of the users are just coming to the site to read text, I'd imagine it would save a lot of CPU time.
Earlier quoted context omitted.
Whereas xpath... does not. Which is a severe understatement considering the equivalent to the CSS selector you wrote up (or to `.foo`) in xpath 1 is something along the lines of: [contains(concat(' ', normalize-space(@class), ' '), ' foo ')] the normalize-space can be dropped IIF you're certain all spaces are normalized, the spaces around the needle not. xpath 2 does quite a bit better through `tokenize`: //*[tokeniz…
Over in .NET land we appear to be stuck on XPath 1.0 forever. A project I used to work on used it extensively, but I now use the HtmlAgilityPack (badly formatted HTML) or XDocument (XHTML strict or XML) where I have the choice.
I don't think it's a bad idea, most of the improvements in XPath 2 are the new standard functions which depending on your XPath implementation may be available as extensions (e.g. tokenize comes from exslt, an xpath 1.0 library) but along with that it brings significantly higher complexity and I think the spec has gone from "difficult to read" to "meaningless word-salad".
I really like XPath, but I can't say I was impressed by XPath 2, it loses much of xpath's simplicity with little to show for the added complexity.
XML gets a bad rap because of how much prettier JSON is, but there are a lot of cool tools associated with it. XPath is pretty awesome, I had to write a XPath parser/executor once (for a class) and it made me appreciate the value and simplicity. Then there was XSLT, which was a pretty sweet way to turn a data format into a variety of "print" or "display" formats. Definitely been replaced by bigger and better things b…
Programming in XML is never a good idea. It isn't in XSLT, it isn't in Spring, it isn't in Maven. Anything that's XML and has elements or attributes with names like "if", "else" or "while", something went horribly, horribly wrong somewhere. It's horribly verbose, you can't reasonably debug it, and there's virtually no engineering best practices, which results in near-impossible maintenance tasks.
Any modern programming language with a good, consice, XML parsing library is a more effective tool to transform XML into something else than XSLT.
Don't code in XML.