xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <...@mcc.id.au>
Subject Re: substituting different DOM implementation
Date Fri, 15 Sep 2006 00:44:34 GMT
Yaroslav Bulatov:
> Actually the reason I want to provide my own implementation is to
> enable XForms events generated by another framework (Chiba) to
> propagate to the DOM hierarchy generated by Batik.


> Right now those XForms events are dispatched through
> org.apache.batik.dom.events.EventSupport.dispatch(), which discards
> all events that are not instances of w3c's CustomEvent or batik's
> AbstractEvent
> Since I can't get Chiba to usea different implementation for event
> generation, I understand that I must provide my own DOMImplementation
> which overrides getEventSupport and getDocumentEventSupport to provide
> my own event support classes. In particular my version of EventSupport
> would override "dispatchEvent" to wrap Chiba's XFormsEvent into an
> implementation compatible with Batik, and call the original
> dispatchEvent method.
> The question is -- how do I substitute this DOM implementation into
> SVG document loaded into JSVGCanvas using loadSVGDocument?
> As far as I can see, the DOM implementation used when I invoke
> JSVGCanvas.loadDocument() is hardcoded to be SVGDOMImplementation (it
> uses DocumentLoader, which uses SAXSVGDocumentFactory which uses
> SVGDocumentImplementation), so I would need to override at least those
> 3 classes, is that correct?

Yes.  It doesn’t look like the nicest way that Batik can handle foreign
event objects (DOM 3 Events doesn’t require it to), but it should work.

Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message