Hi Cameron,
Cameron McCormack wrote:
As part of my main project I'm making a Batik extension, as you might know. I want to make available a new element which acts similarly to a tref element. This element, tval, will generate text content as a result of evaluating an expression.
While implementing this extension I like to modify the core Batik classes as little as possible, so I could eventually just distribute the extension classes and not a whole modified version of Batik. Taking the path of least resistance, I derive a bridge class from SVGTextElementBridge and install this as the Bridge class for the standard text element. This derived class then overrides only those methods that do something with a child text element (like tref). For each of these methods, I just copy the method from SVGTextElementBridge and then modify it slightly to handle my tval element.
Yah, as you noticed I did something similar for the flow text element bridge. Really the text stuff needs something like the rest of the bridge classes to handle it's children. Anyway, this isn't the main topic of your post...
I have come across one problem, however, and that is that fillAttributedStringBuffer needs to call storeEventListener on the BridgeContext when it handles an a element. This method is protected in BridgeContext, and only accessible to SVGTextElementBridge by virtue of it being in the same package. Since the class I wrote that derives from SVGTextElementBridge does not live in the org.apache.batik.bridge package, it can't access storeEventListener.
Poking around the flow text extensions, I notice that SVGFlowTextElementBridge also derives from SVGTextElementBridge, but luckily doesn't have to access any protected methods from the BridgeContext.
So I think in general that extensions should be allowed to access storeEventListener in particular, since they may set up event handlers and want the BridgeContext to remove them again later on. I guess the way to allow this would be to add a protected method to AbstractGraphicsNodeBridge called storeEventListenerInBridgeContext or something less wordy which just delgates the call to the BridgeContext.
I would in general support just making storeEventListener public in BridgeContext.
It is a simple enough modification, but I just like to run these sorts of architectural things by you (the other committers), especially since it comes up only because of my project.
As long as it doesn't hold you up. It is probably a good idea at least for the short term.
On a similar note, there is another modification I have been working with for a while. I added a method isDynamicElement to org.apache.batik.bridge.BridgeExtension which is called by BaseScriptingEnvironment.isDynamicElement, so that one can write an extension element that causes a document to be dynamic.
I don't like the idea of asking each registered bridge extension about each element in the document. That said probably the current isDynamic check code is probably slow enough that it shouldn't make a huge difference.
Anything wrong with these two proposed changes?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
