# Could a core member take a moment to commit these patches? **URL:** \ **Category:** rubyonrails-core\ **Created:** [July 11, 2007, 9:44pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543 "2007-07-11T21:44:49Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Gabe\_da\_Silveira1](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@Gabe\_da\_Silveira1](https://discuss.rubyonrails.org/u/Gabe_da_Silveira1)\ **Post date:** [July 11, 2007, 9:44pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/1 "2007-07-11T21:44:49Z")
I've got a couple small patches that are quite helpful and minimally invasive that I'd love to get out of my vendor/rails so I can start work on new patches with a clean edge rails (without checking out another copy). If any core member has time to take a look at these and either commit these or give me some feedback I'd really appreciate it: [http://dev.rubyonrails.org/ticket/8683](http://dev.rubyonrails.org/ticket/8683) Koz looked at this one and asked for a test 3 weeks ago, which I provided, but I haven't heard back. This one is particularly useful for development because without it, Template Missing errors don't actually say what template was requested (broken since the addition of multiple controller view paths). [http://dev.rubyonrails.org/ticket/8173](http://dev.rubyonrails.org/ticket/8173) This one's been out there for several months with nary a comment (other than "not so tiny", which I dispute). It makes XML testing with assert\_select work. The only condition under which it would break someone's existing tests would be if they were sending content type application/xhtml+xml (which no one does because IE doesn't understand it) AND they were producing invalid XHTML (an unlikely combination to say the least). So it seems like a no-brainer to me. Jamis even blogged about a workaround ([Buckblog: assert\_xml\_select](http://weblog.jamisbuck.org/2007/1/4/assert_xml_select)), so it's surprising there's been no comment. Thanks in advance, Gabe da Silveira ---
**Author:** ![Michael\_Koziarski1](https://avatars.discourse-cdn.com/v4/letter/m/aca169/32.png) [@Michael\_Koziarski1](https://discuss.rubyonrails.org/u/Michael_Koziarski1)\ **Post date:** [July 11, 2007, 11:35pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/2 "2007-07-11T23:35:50Z")
> I've got a couple small patches that are quite helpful and minimally invasive that I'd love to get out of my vendor/rails so I can start work on new patches with a clean edge rails (without checking out another copy). If any core member has time to take a look at these and either commit these or give me some feedback I'd really appreciate it: > > [http://dev.rubyonrails.org/ticket/8683](http://dev.rubyonrails.org/ticket/8683) > > Koz looked at this one and asked for a test 3 weeks ago, which I provided, but I haven't heard back. This one is particularly useful for development because without it, Template Missing errors don't actually say what template was requested (broken since the addition of multiple controller view paths). Applied. Thanks! > [http://dev.rubyonrails.org/ticket/8173](http://dev.rubyonrails.org/ticket/8173) > > This one's been out there for several months with nary a comment (other than "not so tiny", which I dispute). It makes XML testing with assert\_select work. The only condition under which it would break someone's existing tests would be if they were sending content type application/xhtml+xml (which no one does because IE doesn't understand it) AND they were producing invalid XHTML (an unlikely combination to say the least). So it seems like a no-brainer to me. Jamis even blogged about a workaround ([Buckblog: assert\_xml\_select](http://weblog.jamisbuck.org/2007/1/4/assert_xml_select)), so it's surprising there's been no comment. assert\_select and xml is way outside my comfort zone so I'll pass on this one. Anyone else have any comments on it? If you can get three regular contributors to report on the utility of the patch, and the implementation, I'd feel more comfortable applying it. ---
**Author:** ![Gabe\_da\_Silveira1](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@Gabe\_da\_Silveira1](https://discuss.rubyonrails.org/u/Gabe_da_Silveira1)\ **Post date:** [July 12, 2007, 6:20pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/3 "2007-07-12T18:20:57Z")
> Applied. Thanks! Thank you! > \> [http://dev.rubyonrails.org/ticket/8173](http://dev.rubyonrails.org/ticket/8173) > assert\_select and xml is way outside my comfort zone so I'll pass on this one. Anyone else have any comments on it? > > If you can get three regular contributors to report on the utility of the patch, and the implementation, I'd feel more comfortable applying it. I know there's gotta be people out there bitten by this one. If your XML schema contains auto-closing HTML tags (such as \) then testing with assert\_select becomes unusable. The patch is so simple, if you're doing RESTful APIs and like the power of assert\_select, please take 5 minutes to check it out. It'll save you a lot of ugly hacks. ---
**Author:** ![Rob\_Sanheim](https://avatars.discourse-cdn.com/v4/letter/r/2acd7d/32.png) [@Rob\_Sanheim](https://discuss.rubyonrails.org/u/Rob_Sanheim)\ **Post date:** [July 12, 2007, 9:01pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/4 "2007-07-12T21:01:05Z")
I've been bitten by this before, and would love to see assert\_select made more friendly for xml. - Rob ---
**Author:** ![Michael\_Koziarski1](https://avatars.discourse-cdn.com/v4/letter/m/aca169/32.png) [@Michael\_Koziarski1](https://discuss.rubyonrails.org/u/Michael_Koziarski1)\ **Post date:** [July 12, 2007, 9:20pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/5 "2007-07-12T21:20:04Z")
How are css selectors useful when testing xml? Do you just use the element names? As for the patch, you should probably use the lookup function in mime.rb instead of regexp matching. That'll remove the false positives ---
**Author:** ![Anthony\_Bailey](https://avatars.discourse-cdn.com/v4/letter/a/a6a055/32.png) [@Anthony\_Bailey](https://discuss.rubyonrails.org/u/Anthony_Bailey)\ **Post date:** [July 12, 2007, 10:27pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/6 "2007-07-12T22:27:18Z")
Gabe da Silveira wrote: > I know there's gotta be people out there bitten by this one. Yes. The case I got bitten by is the \ element: in HTML it's self-closing, in feed XML it is not. I currently use the method from [Buckblog: assert\_xml\_select](http://weblog.jamisbuck.org/2007/1/4/assert_xml_select), which defines a separate assert method for the XML case. It looks like the original assert\_select plug-in may have had something similar in the form of assert\_select\_feed (it still features in Edge comments, but the code doesn't seem to have survived.) I don't know of any reason not to fix up the underlying response as in your patch, though. Anyone? I do think the method name seems wrong now - it's not really an html\_document you're returning. Should the fix really be applied in response\_from\_page\_or\_rjs? I note that the patch fixes css\_select too, as well as assert\_select - it currently suffers from the same set of XML problems.   --Anthony. ---
**Author:** ![Gabe\_da\_Silveira1](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@Gabe\_da\_Silveira1](https://discuss.rubyonrails.org/u/Gabe_da_Silveira1)\ **Post date:** [July 14, 2007, 5:48pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/7 "2007-07-14T17:48:53Z")
> How are css selectors useful when testing xml? Do you just use the element names? element names, attributes, child, ancestor, sibling, pseudo-classes like :empty, etc. Pretty much anything but .class and #id selectors are widely useful. Think about testing your XML with regexps (yech!) or installing a parser. assert\_select provides an amazingly powerful syntax for a non-trivial problem domain. If only web browsers supported all those selectors! > As for the patch, you should probably use the lookup function in mime.rb instead of regexp matching. That'll remove the false positives Agreed, this will be an improvement. I'm checking out mime.rb now to figure out how to do this. ---
**Author:** ![Gabe\_da\_Silveira1](https://avatars.discourse-cdn.com/v4/letter/g/ce7236/32.png) [@Gabe\_da\_Silveira1](https://discuss.rubyonrails.org/u/Gabe_da_Silveira1)\ **Post date:** [July 14, 2007, 6:49pm UTC](https://discuss.rubyonrails.org/t/could-a-core-member-take-a-moment-to-commit-these-patches/15543/8 "2007-07-14T18:49:59Z")
Okay, I've gone in and made the patch using the lookup function. However, after looking closer at the situation, I believe the original patch is better for a number of reasons which I've detailed in the patch comments. I don't believe there is any possibilty of a false positive, because the ONLY type that should be parsed as HTML is text/html. Everything else (including XHTML) should be parsed as XML. There are numerous types of XML, including user-defined XML formats, all of which use a standard mime\_type convention of application/type+xml, so there is no way to get around the use of a regexp. Meanwhile, the lookup function requires Rails-known mime types, even though the developer can specify any content-type he wants. So far it seems a few people are interested in the patch. I haven't marked it verified, is the rule for that you have to get the explicit three +1s? Should I go on rails-contrib? I would think the mailing list gets more eyes, but I'm ready to do whatever it takes to get this puppy committed.