From: Phlip <phlip2005@...>
Date: 2009-03-18T03:52:37+09:00
Subject: Re: [ANN] hpricot 0.7

Firstly, major props, and keep up the good work...

_why wrote:

> You have to question a benchmark that is entirely based on two XML
> documents. What about HTML fix ups? What about various platforms
> and CPUs? Why not treat Hpricot fairly and use it properly in the
> benchmarks? It reeks of something.

Here's what I use N for:

//form[
    ./descendant::fieldset[
       ./descendant::legend and
       ./descendant::li[
          ./descendant::label and
          ./descendant::input ]
    ]
  ]

I generate that from some N::HTML::Builder code, form{ fieldset { etc } }, which 
turns into a DOM containing <form><fieldset> etc </fieldset></form>. The goal is 
an assertion like this:

     assert_xhtml do
       h2 'Sales'
       select! :size => SaleController::LIST_SIZE do
         option names[1]
         option names[0]
       end
     end

The point is to match an example HTML to a target HTML. I first tried it by 
walking that object model myself, recursing thru all DOM children to find the 
ones that match. However, as the recursion got more complex, I was "adding 
epicycles" to the code.

I backed off and rewrote, by first converting all the example HTML into one 
jiy-normous XPath, shown above. I have to do it like this because the example 
HTML could contain _anything_, and I need the query to run fast and absolutely 
stable. My assert_xhtml should not fail if the target code has the correct HTML 
subset - or vice versa. I can't do that anywhere except LibXML, and I need to 
keep that easy to install.

And, in the grand scheme of things, I don't think _you_ have room to complain 
about your libraries' adoption rates!

-- 
   Phlip