No native support for running xpath's on results. about reboot HOT 7 CLOSED

@adamdecaf is this needed on dispatch? jsoup provides css selectors and dom manipulation.

from reboot.

There are some more features that xpath has that I haven't seen in jsoup. Are they there?

http://en.wikipedia.org/wiki/XPath_2.0#Function_library

from reboot.

1. XPath only works for valid documents, afaik. See this Stack Overflow Answer jsoup works on tagsoup (invalid docs).
2. For selection, with the regular css3 selectors and psuedo-selectors available from jsoup, the functions listed in that table (except for the datetime transformations) are covered. Since selectors are strings, you could use joda or something to create the correct corresponding string selector.
3. For manipulation, the attr('name', 'value'), text('value'), html('html'), prepend('html'), append('html'), and wrap('html') methods are easier to use than corresponding XPath transformations.
4. For extraction, the attr('name'), text('name'), outerHtml(), and html() methods are easier to understand and use than the Xpath counterparts.
5. For traversal, siblingElements(), firstElementSibling(), lastElementSibling(), nextElementSibling(), previousElementSibling(), parent(), children(), child(int index) are easier to understand than XPath queries that do the same thing.
6. The traversal and selector methods are chainable and contextual.

IMHO selector('#someId').parent().lastElementSibling() is easier than //[id='someId']/../following-sibling[last()] or some other such nonsense.

Take it from a front-end dev that has to make interactive guis with the DOM -- selectors, attr, text, outerHtml, innerHtml, nextSibling, parent, children are way easier to use than xpath or xslt. Developers use jQuery and dom traversal to select and change things, not xpath. On top of all of that, if you use </> on an xml document, you get all the niceties of scala native xml handling. My 2 cents.

from reboot.

Oh yes, I agree that whenever developers can use DOM selection, traversal, etc.. that they should always do that. However, not every legacy application will be able to do that. I'll close this for any future reference.

from reboot.

Right, but using </> they get a NodeSeq, and that allows them to use xpath,
right? If they move their application to reboot, it is a small change for
their application that is less invasive than Promises, imho.

On Thu, Mar 28, 2013 at 8:41 AM, Adam Shannon [email protected]:

Oh yes, I agree that whenever developers can use DOM selection, traversal,
etc.. that they should always do that. However, not every legacy
application will be able to do that. I'll close this for any future
reference.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/47#issuecomment-15588753
.

from reboot.

It lets them do similar things as xpath (and jsoup). They'll still have to deal with promises though. Unless I'm missing what you're saying?

from reboot.

@adamdecaf I don't think so. What I was saying was basically that switching the handler verb is less of an invasive refactor as modifying the application to deal with Promises correctly.

from reboot.