search

GistLabs / mechanize

mechanize for java
http://gistlabs.com/software/mechanize-for-java/
Mozilla Public License 2.0
78 stars 21 forks source link

Reintroduce the Query API #72

Open MartinKersten opened 10 years ago

MartinKersten commented 10 years ago

1.1 to 2.0 the not CSS related Query API was removed. Since it was quite easily extendable and easy to read in tests it should be investigated if the Query API might get reintroduced in a different fashion.

jheintz commented 10 years ago

This is a good idea, and I'll record it in the Future milestone. The codebase is now cycle-free so reintroducing this exactly as 1.x is not an option. The NodeVisitor mechanism is likely the best way to build this as an extension. Another option is to have a Query interface/plugin mechanism, but that would need to be thought through carefully to not introduce excess complexity.

MartinKersten commented 10 years ago

We could also do a kind of a Processor like interface. Instead of binding to a query object directly we just offer to play the query on a certain object. Therefore the object only needs to understand how to play back any query so the complexity is completely hidden from the elements itself.

example:

html.find(query(tag("img").and(href("href")))));

All those methods come as static imports using import static HtmlQuery.*. So html find just knows how to play any query and the query itself adapts to the given element. Interface like: Query.search(Element).

Or we provide a build in query mechanism per implementation. HtmlElements.query() : HtmlQueryBuilder. This way we only couple HtmlElement with a HtmlQueryBuilder and any other like Json requires its own query API if necessary. This way we have queries and it will be cycle free. There was no need to generalize Query in the first place (dont know if I did this).