I've spent some time abstracting out interfaces in an attempt to decouple gvt from bridge. So far it looks doable, but I'm wondering whether I'm missing something. I'm not sure I understand your statement about 'creating classes to hold the data between DOM and GVT'. I think you're suggesting that one way to decouple them would be to create an intermediate set of classes to hold the data and then pass the data objects off to some object in gvt that would build the tree. Another way would be to require bridge clients (like gvt) to implement an interface, and then have the clients build the tree themselves as the document is parsed. Here's what I've done so far and where I'm headed. Since I have limited batik experience, please let me know if you think I'm looking for trouble.
My goal is to leverage the considerable effort that has already been spent on building a gvt tree from svg. It seems to me that a framework for building arbitrary class trees from svg would do much to promote svg as it would lower the barrier to entry for 3rd party projects that wanted to read svg and transform it to their internal data format. So far I've factored out most of the calls within bridge to methods of GraphicsNode and CompositeGraphicsNode. What I have left to do is to abstract the creation of objects, which entails (I think) making many of the subclasses of AbstractGraphicsNodeBridge abstract (SVGShapeElementBridge, for example), moving the gvt creation code to gvt-specific subclasses, and then creating a second set of bridge subclasses that will create my own objects. Any comments? Does anyone think that this would be a useful feature of batik? Seth On 3/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Seth, > > "Seth Tager" <[EMAIL PROTECTED]> wrote on 03/13/2006 05:23:00 PM: > > > I don't think this post made it the first time. > > It did, I just didn't have much to add. You are correct > that the Bridge package is pretty tightly tied to both the > DOM and the GVT (although both of those are independent of > each other). > > There are some pieces that are very reusable like the > parsers package. But most of the stuff that the Bridge > does I have a hard time imagining how to abstract without > creating a whole new set of classes just to hold the data > between DOM and GVT - which to be honest just doesn't make > sense to me. > > The Bridge and GVT do try to use standard AWT classes > wherever possible so depending on what your back end is > you might be able to use parts of these. > > > Has anyone out there been able to leverage batik to build their own > > internal data structures for manipulating svg docs? > > > > On 2/28/06, Seth Tager <[EMAIL PROTECTED]> wrote: > > > > > I'd like to read an svg document and convert it to my own internal > > > object tree, similar to the way a gvt is built. It seems like the > > > org.apache.batik.bridge package might be useful, but it doesn't look > > > like the same kind of bridge described in Design Patterns by Gamma, > > > Helms, etc.? (i.e. it seems to be tightly coupled with the GVT > > > package, and _not_ meant for swapping gvt-like implementations) > > > > > > Is there some way I might leverage that package to build my own tree > > > from an svg doc? It looks like the best i can do is to use the bridge > > > and gvt packages as a template/guide for creating my own tree builder > > > code. Has anyone done something like this already? > > > > > > Seth > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
