Hi Thomas,
On Tue, 30 Dec 2003, Thomas DeWeese wrote:
There is a decent chance that I may change this attribute to be a SoftReference to the element.
If I may ask: why?
* As long as the DOM Document exists, the Element will exist.
* As long as the Bridge exists, the DOM Document will exist.
* Thus, in practice with an SVGComponent, there will always be a strong-reference to the Element, so using a SoftReference will accomplish nothing. In addition, there will be the added overhead of having the SoftReference object itself.
There is the possibility of using just the JGVTComponent with a GVT tree for static content. Currently this references is the only reference from GVT to DOM (or bridge) - if it went away then you could construct the GVT tree and let the DOM tree be GC'd.
Or if I'm wrong and it is possible for all the strong-references to
disappear, then the availability of that Element becomes
non-deterministic. And, theoretically (though I doubt it'd ever
show up in practice), anyone attempting to use that through the
SoftReference could create a race condition if the VM decided it was
time to clear SoftReferences between when the TextNode was created
and when someone tried to grab that Element. This could be even
more unpleasant if threads are involved (which they frequently are
with Batik, if I remember right).
For a Dynamic document the reference could never go away.
I'd also be perfectly content to modify the TextNode directly, as long as they DOM stayed synchronized with the changes. From what I've seen in this list's archives, though, it sounds like the best/easiest way to keep them synchronized is to mess with only the DOM.
Yes, the GVT tree never directly updates the DOM. In fact other than the afore mentioned text attribute there are no back references.
[..]I needed to be able to recieve events even if the user clicked in an area of the SVGCanvas which did not contain part of the SVG.
Looking back, I could just have tossed a full-size rectangle (maybe
even a transparent rectangle) as the first SVGElement in the DOM after
loading it, and taken it out when saving, which would have allowed me to get
the events I needed and allowed me to use GVTEvents / DOMEvents.
This is the time tested hack to support this in SVG. With the current versions of batik you can use:
<rect x="-1000%" y="-1000%" width="2000%" height="2000%"
fill="none" stroke="none" stroke-width="0"
pointer-events="fill"/>Maybe if I get time, I'll rewrite things in this cleaner manner; but I'm on a schedule now. (and maybe there are other possibilities I didn't try... *shrug* it's been a while; I can't even remember what I /did/ try ;-).
The above would probably greatly simplify your life :) The one real advantage of interactors is that they are 100% modal. So no one else get's any events when an interactor is active - they are also good to avoid the overhead of DOM event dispatch (which can be expensive - locating target etc.) But if what you want to do in the end is modify the DOM - DOM events are almost always easier to work with.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
