Re: [Xmlunit-general] Advanced ElementSelectors

[Stefan B. <bo...@ap...>]

On 2015-02-10, Stefan Bodewig wrote:

> I can also see some nice builder syntax forming

> ElementSelector es = Builder
>     .whenElementIsNamed("foo").thenUse(byNameAndText)
>     .whenElementIsNamed("bar").thenUse(byNameAndAttributes("id"))
>     .otherwise(byName)
>     .build();

I've used defaultTo rather than otherwise, but this is now available
- most of it in
https://github.com/xmlunit/xmlunit/commit/eed0b2a6f2b16d54668990daabcd9513999df93c

> To get rid of RecursiveElementNameAndTextQualifier this is not enough,

...

> Taking
> http://stackoverflow.com/questions/23752354/xmlunit-recursiveelementnameandtextqualifier-not-working
> as example one could use something like

>     byXPath(".//a", byNameAndText)

> and apply that to "td" and "tr" elements.

https://github.com/xmlunit/xmlunit/commit/b6c24bf33f205676839bfce6fa8db59d089cf43c

> But I'm not sure this really is easy enough to understand and I'm afraid
> it would become repetitive.  So a better idea is more than welcome.

> Also ElementSelector only receives Elements as context, therefore the
> big brother of selectorForElementNamed - conditionalSelector - works
> with a Predicate<Element> to see whether it should apply.  This may be
> cumbersome and I can easily see problems where the element name is not
> enough and I need to know where the element is, something like the
> XPathContext would be helpful.  This might require a change to the
> ElementSelector and likely the NodeMatcher APIs.  Any ideas?

I'd still be thankful for any kind of feedback.

Stefan