Comment savoir quand utiliser un analyseur XML et quand utiliser ActiveResource?

Question

J'ai essayé d'utiliser ActiveResource pour analyser un service Web qui ressemblait plus à un document HTML et j'ai continué à recevoir une erreur 404.

Ai-je besoin d'utiliser un analyseur XML pour cette tâche au lieu d'ActiveResource? Je suppose que ActiveResource n'est utile que si vous consommez des données d'une autre application Rails et que les données XML sont facilement traduisibles en un modèle Rails. Par exemple, si le service Web est un document XML plus étendu, comme un document HTML ou un flux RSS, vous voulez utiliser un analyseur syntaxique comme hpricot ou nokogiri. Est-ce correct?

Comment savoir quand utiliser un analyseur XML et quand utiliser ActiveResource?

Answer 1

Mise à jour: ActiveResource n'est pas non plus un analyseur XML. C'est un consommateur REST vous permettant d'interagir avec une ressource distante similaire à celle d'un modèle ActiveRecord. Il utilise un analyseur XML sous le capot (je suppose en passant par l'affichage XmlMini I d'ActiveSupport ci-dessous).

ActiveResource a des exigences strictes concernant la structure du contenu XML et fonctionne mieux lorsqu'il interagit avec l'API REST d'une autre application Rails. Il n'est pas prévu de faire un scrap d'écran générique d'une page HTML. Pour cela, utilisez directement Nokogiri. ActiveSupport n'est pas un analyseur XML, il s'agit d'une collection diverse de méthodes et de classes Ruby utiles. Cependant, il offre un wrapper autour de nombreux analyseurs syntaxiques XML différents, vous offrant ainsi une interface cohérente.

Vous pouvez voir quel analyseur XML est utilisé et passer à un autre analyseur XML. Essayez ceci dans script/console. Cependant, cela utilisera toujours l'analyseur XML dans Nokogiri qui suppose un balisage strict et valide. La plupart des pages HTML ne répondent pas à cette exigence stricte et il est donc préférable d'utiliser l'analyseur HTML de Nokogiri directement au lieu de passer par ActiveSupport.

doc = Nokogiri::HTML(...) 

Answer 2

J'ai écrit XmlMini parce que je voulais répondre à la même question. XmlMini ne fait pas vraiment beaucoup, et cela lui permet de rester concentré. Mais si vous avez un problème que YAML ou JSON n'est pas qualifié pour gérer, XmlMini ne fera pas le travail non plus. Par exemple, si vous avez besoin de valider la structure du XML avec lequel vous traitez, XmlMini n'est pas l'outil. La validation à la main est affreuse. De même, si vous manipulez des données qui réutilisent la sémantique d'éléments et d'attributs standard ailleurs, comme des extraits de UBL, OpenDoc ou Atom, vous devriez vraiment obtenir de meilleurs outils pour les espaces de noms. Ryanb mentionne Nokogiri, et je ne peux pas penser à quelque chose de plus merveilleux pour ces choses. Il a toute la puissance de libxml, avec plus d'élégance que presque n'importe quelle bibliothèque de Ruby. Je ne parle pas seulement de l'analyse XML, mais des meilleurs projets de _why.

Mais il y a des choses pour lesquelles même Nokogiri n'est pas conçu. Si vous avez vraiment, absolument, absolument besoin de tuer chaque équerre dans la pièce à la vitesse du cou de rupture, vous devez sortir SAX. Mais si vous avez tellement besoin de vitesse, ne le faites pas dans Ruby. Faites-le en expat ou libxml avec du pur C. Ou ne le faites pas du tout.