Return-Path: Delivered-To: apmail-xml-batik-dev-archive@xml.apache.org Received: (qmail 1856 invoked by uid 500); 9 May 2001 12:11:48 -0000 Mailing-List: contact batik-dev-help@xml.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: batik-dev@xml.apache.org Delivered-To: mailing list batik-dev@xml.apache.org Received: (qmail 1785 invoked from network); 9 May 2001 12:11:36 -0000 X-Authentication-Warning: frog.image.kodak.com: deweese set sender to deweese@image.kodak.com using -f From: Thomas E Deweese MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.13301.437520.69181@gargle.gargle.HOWL> Date: Wed, 9 May 2001 08:11:33 -0400 To: batik-dev@xml.apache.org, Thierry.Kormann@sophia.inria.fr Subject: BridgeExtension and the DOM X-Mailer: VM 6.76 under Emacs 20.5.1 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi Thierry, I'm working on the regular polygon extension example, and I have it working... more or less :). As you might guess from the title there is still a sticking point with the DOM. My new tag looks like: First I wrote my BatikRegularPolyElementBridge and the BatikBridgeExtension class, after a few tries I had my polygon coming up 'black', (it was ignoring the 'fill' attribute). I soon discovered that for the Bridge's fill/stroke stuff to work the element had to be a subclass of SVGElement. This led me to construct a BatikRegularPolyElement class, and I stuck a call into SVGOMDocument.registerCustomElementFactory so it would use my subclass of SVGGraphicsElement for regularPoly nodes. The problem is that the Bridge Context stuff is done multiple times (so each time I re-register my factory with the DOM, which is ugly), and worse the Bridge Context stuff is done _after_ the DOM stuff (so the first time the poly comes up black the second time blue :). In looking at SVGOMDocument, it appears that it has a very similar structure to the Bridge (people register small factory objects for each tag they want to handle). So my question is should I build a similar structure for the SVGOMDocument to allow for the dynamic registration of custom DOM extensions? The other alternative I see would be to rewrite a lot of code that assumes that the elements the bridge works on are SVGElements and have all that code work on GenericElementNS (I already fixed one class cast exception around this). Personally I think it makes some sense for people to have to extend the DOM if they are interested in extending the Bridge. In this case the DOM extension would commonly register the corresponding BridgeExtension as part of it's work. What do people think? PS: I'm currently working on the example extension stuff in batik.ext.svg do we want to create an examples directory? Should it be a separate source tree, or a directory under batik? sources/org/apache/batik/... test-sources/... example-sources/org/apache/batik/... or sources/org/apache/batik/examples/... --------------------------------------------------------------------- To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org For additional commands, e-mail: batik-dev-help@xml.apache.org