Why YPath?

Because our Wiki will edit one YAML node at a time, each node needs a unique address. So just as YAML is simpler than XML, YPath is simpler than XPath, though similar.

(Incidentally, at publication time, YPath had no elected standard, only a single reference implementation. This project only uses YPath's simplest mode—the one least likely to change. The great thing about standards is there are so many to blame when your application breaks!)

Each DIV node in our UL output will store its unique YPath location in its id. When you click the node, it will transmit its location to the server. The YPath for the script node of test_hammy_squirrel might be /test_hammy_squirrel/-script, so we suspect we could write the test like this:

  def yaml_to_xhtml(source)
    @yar = YarWiki.new('WikiTestPage')
    @yar.save_page(source)
    x = Builder::XmlMarkup.new
    @yar.format_yaml x
    assert_xml x.target!
  end  #  other test cases should use this

  def test_two_level_omaps
    yaml_to_xhtml(get_omap)
    assert_xpath '/ul/li[3]/ul/li[3]/div[ @id = "/test_hammy_squirrel/script" ]'
  end

We need to put the YPath into the id attribute of each DIV defining a string. But the HTML standards want to throw us one more curveball: an id must begin with an alphabetic character, and must not contain slashes. So we must convert "/test_hammy_squirrel/script" into "node:test_hammy_-squirrel:script". Our format_yaml system will output pseudo-YPath, in that format, and then the server will convert it into true YPath before using it.

Get Test Driven Ajax (on Rails) now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.