takes a UML glance at how the library is structured internally.
UML Diagrams
The library comes with two DomBinder implementations: JaxenDomBinder and JaxpDomBinder (The latter is slower, see: Performance.)
Each DomBinder implementation relies on a specific set of dynamic proxies, with a use of java.lang.reflect.InvocationHandler
objects.
In this diagram:
- net.avcompris.binding.Binder<U>
- net.avcompris.binding.dom.DomBinder
- net.avcompris.binding.dom.impl.AbstractDomBinderInvocationHandler
- net.avcompris.binding.dom.impl.JaxenDomBinderInvocationHandler
- net.avcompris.binding.dom.impl.JaxpDomBinderInvocationHandler
- net.avcompris.binding.dom.impl.DefaultDomBinder
- net.avcompris.binding.dom.impl.JaxenDomBinder
- net.avcompris.binding.dom.impl.JaxpDomBinder
- net.avcompris.binding.impl.AbstractBinder<U>
- net.avcompris.binding.impl.AbstractBinderInvocationHandler<U>
DefaultDomBinder is merely an alias for JaxenDomBinder.
By using a DomUniqueBinder, you can filter your chosen binder so it returns unique proxy instances for given org.w3c.dom.Node
objects, even though they are accessed by different XPath expressions:
final DomBinder binder = new DomUniqueBinder(new DefaultDomBinder()); final Book book1 = binder.bind(document, Book.class); final Book book2 = binder.bind(document, Book.class); assertSame(book1, book2); assertSame(book1.getReferences()[0], book2.getReferenceByLang("en")); ...
In this diagram: