You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/05/09 14:11:33 UTC
BridgeExtension and the DOM
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:
<batikExt:regularPoly fill="blue" cx="225" cy="250" r="150" sides="6"/>
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
Re: BridgeExtension and the DOM
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <tk...@sophia.inria.fr> writes:
TK> On Wednesday 09 May 2001 15:18, Thomas E Deweese wrote:
>> Well, I seriously considered 'rpoly' :) I don't really care I used
>> 'poly' since the SVG spec uses 'poly'.
TK> Just kidding but it's <polygon> in SVG :)
Doh! Your right! I guess now I'll _have_ to change it to
'regularPolygon' before checking in. :)
TK> After discussion with Stephane, here were our requirements
TK> 1. Let users add extensions to the DOM
TK> 2. Let users add extensions to the Bridge
TK> 3. Do not add the dependencies 'DOM relies on the Bridge'
TK> 4. An extension might be a DOM extension, a Bridge extension or
TK> both
TK> 5. DOM extensions and Bridge extensions must be handled at the
TK> correct time and separately
Looks good.
I have one question here though.
Since the two are seperate when do we report that we support an
requiredExtension. :)
It's now possible for the DOM to support an extension but the
Bridge not to, and of course vice-versa. My preference is to say that
since 'switch' is pretty fundamentally a rendering thing, we only add
requiredExtensions to the UA for Bridge extensions.
Agree? Disagree?
TK> -- General --
TK> Both services register to a non static HashMap. To the
TK> BridgeContext for new Bridge instances To the SVGOMDocument for
TK> the new ElementFactory instances
Probably better, but the static didn't bother me too much.
TK> The Service classes should be in the batik/util package (I think
TK> it's the case) for dependencies between modules.
The Service class is there, actually since you pass in the
interface you want service providers for, the class is completely
independent of any package (other than java.* stuff). The code that
uses the Service class isn't but that is usually small and included in
bootstrap for each of the users of the provided services (like
BridgeContext).
TK> For DOM extensions:
TK> 1. Stephane will remove the static stuff for DOM extensions. Each
TK> SVGOMDocument will be able to have its own set of supported
TK> extensions.
TK> 2. You (or somebody else) will then be able to add the Service
TK> mecanism to the our DOM implementation.
OK, I'm game to do this work, unless Stephane (or someone else)
get's particularly interested (it's not very hard).
TK> 3. I will remove all the dependencies to the SVGElement in the
TK> Bridge. A simple 'grep' in the bridge source code shows me that
TK> it's gonna be easy to do it and there is no reason for that :)
Good.
TK> Stephane told me how to create your own DOM Element (without
TK> subclassing useless classes such as SVGOMElement).
[...]
TK> In conclusion, and due this long list of things to do, Stephane
TK> and I will prepare a package into which we will able to drop our
TK> extensions and an abstract class that will do the painful work
TK> (all of the previous code).
I guess I don't have strong feelings one way or the other on this.
But I'm not sure what I'm getting out of the new Abstract class. Since
I wanted my regularPolygon class to behave exactly like an SVG element
(it _is_ an svg element it just isn't in the SVG namespace) it didn't
seem like it was unreasonable to subclass SVGOMElement (I just
overrode the namespace call - a very small hack).
I suppose if all this were bundled in a new baseclass that both
the SVG classes derived off of and extensions derived off of (so they
shared the large set of behaviours that one wants in common) then I
guess this is a bit more elegant, but from how you are talking it
isn't immediately obvious that this is what is happening :).
TK> Hope you can wait...
No, I can't! :)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: BridgeExtension and the DOM
Posted by Thierry Kormann <tk...@sophia.inria.fr>.
On Wednesday 09 May 2001 15:18, Thomas E Deweese wrote:
> Well, I seriously considered 'rpoly' :)
> I don't really care I used 'poly' since the SVG spec uses 'poly'.
Just kidding but it's <polygon> in SVG :)
----------------------------
After discussion with Stephane, here were our requirements (and you have
mentioned most of them - if not all) :
1. Let users add extensions to the DOM
2. Let users add extensions to the Bridge
3. Do not add the dependencies 'DOM relies on the Bridge'
4. An extension might be a DOM extension, a Bridge extension or both
5. DOM extensions and Bridge extensions must be handled at the correct time
and separately
---
We agreed that the solution you have mentioned first seems the best.
a. The Bridge service mecanism handles bridge extensions only. Basically,
register to the BridgeContext and according to a namespaceURI and a local
name, bridges that will be used to create using a DOM Element, a GVT world
object.
--> This one is done!
b. Provide (as you mentioned) a DOM service mecanism (similar to the bridge's
one) that will register DOM Element according to their namespaceURI and local
name.
--> This one have to be done :)
-- General --
Both services register to a non static HashMap.
To the BridgeContext for new Bridge instances
To the SVGOMDocument for the new ElementFactory instances
The Service classes should be in the batik/util package (I think it's the
case) for dependencies between modules.
----------------------------
For DOM extensions:
1. Stephane will remove the static stuff for DOM extensions. Each
SVGOMDocument will be able to have its own set of supported extensions.
2. You (or somebody else) will then be able to add the Service mecanism to
the our DOM implementation.
3. I will remove all the dependencies to the SVGElement in the Bridge. A
simple 'grep' in the bridge source code shows me that it's gonna be easy to
do it and there is no reason for that :)
----------------------------
Stephane told me how to create your own DOM Element (without subclassing
useless classes such as SVGOMElement).
Create a class similar to SVGOMElement except some interface impl.
Something like:
class FooElement extends AbstractElement
implements ElementWithID, // XML+CSS basics
ElementWithPseudoClass, // XML+CSS basics
HiddenChildElement, // for <use> support,
{
// Step 1: Basic methods
// You don't have to implements SVGElement (as it's not SVG)
// and SVGConstants as it's not SVG :)
// Have a look at the SVGOMElement class, remove all the methods that
// came from SVGElement (all methods with the javadoc containing
// dom.svg.SVGElement#something)
// You have to override the following method if needed (you add new
// attributes to your class that are not transient...)
//
// protected Node export(Node n, AbstractDocument d)
// protected Node deepExport(Node n, AbstractDocument d)
// protected Node copyInto(Node n)
// protected Node deepCopyInto(Node n)
// Step 2: Support of styling if needed (typically graphical elements)
// The class must implements
// OverrideStyleElement,
// ExtendedElementCSSInlineStyle
// ElementNonCSSPresentationalHints
//
// To go faster, see SVGGraphicsElement and copy/paste the methods
// they all delegate to a <feature>Support class
}
In conclusion, and due this long list of things to do, Stephane and I will
prepare a package into which we will able to drop our extensions and an
abstract class that will do the painful work (all of the previous code).
Hope you can wait...
Have fun :)
---
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: BridgeExtension and the DOM
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <tk...@sophia.inria.fr> writes:
>> My new tag looks like:
>>
>> <batikExt:regularPoly fill="blue" cx="225" cy="250" r="150"
>> sides="6"/>
TK> What about 'regularPolygon' instead ? - It seems that you like
TK> short name, dear... :)
Well, I seriously considered 'rpoly' :)
I don't really care I used 'poly' since the SVG spec uses 'poly'.
>> 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).
TK> Have you extended the SVGDecoratedShapeElementBridge ? It will
TK> help but not solve the problem (you will have all CSS properties
TK> including marker working)
Yes I extend the DecoratedShapeElementBridge, so should be able to
put markers on the new poly. :)
>> 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 :).
TK> If I well understand, you have to re-register both your custom DOM
TK> Element and its associated bridge for each document, right?
TK> My understanding is that we have two problems:
TK> a. Register Bridge *and* DOM Element before anything else (in this
TK> case, before the DOM tree is created - otherwise it's to late at
TK> least for the first time)
Correct.
TK> b. Provide a way to register both (Element+Bridge) only one time
TK> for a particular extension.
I'm not as worried about this, simply because if we solve problem
'a' correctly problem 'b' should be solved as well.
TK> If the first time, your node is black and then blue, it means that
TK> the DOM extension mecanism is global. It's not the case for the
TK> Bridge extension mecanism. right?
Correct the registerCustomElementFactory is static and it stores
the factory in a static hashtable that is shared by all
SVGOMDocuments. This actually doesn't bother me at all, since the
Service provider stuff is it's self pretty static.
>> 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?
TK> Well, I have to wait for Stephane to come today... I will discuss
TK> with him about that topic and give you our first conclusions.
TK> A possible (and user-friendly) idea could be provide a mecanism to
TK> register both DOM+Bridge when starting a Batik module.
TK> What do you think? When and where do you bootstrap things till
TK> now?
I'm not certain what you mean by 'batik module'.
I am also little nervous about tying the DOM and Bridge extension
mechanisms too closely since it seemed logical that some extenders may
not care about rendering an extension (which would require a Bridge
extension) but simply want to extend the DOM. Also right now the
Bridge sits entirely above the DOM, this suggestion would force at
least a small dependency on the Bridge into the DOM APIs which would
be very bad I think.
This is why I proposed two extension mechanisms one for DOM and
one for the Bridge. When both need to be extended they have a choice
of having two service provider entries ('...batik.dom.DOMExtension' &
'...batik.bridge.BridgeExtension') which is most modular although
perhaps prone to breakage (easier to conceive of cases where only one
or the other get's registered), or one entry
('...batik.dom.DOMExtension') which may then programatically register
a BridgeExtension.
>> 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).
TK> Well, I have choosen Element rather than SVGElement first because
TK> I didn't need the SVGElement API in the bridge to build GVT nodes
TK> and because I didn't want to force extensions-developers to
TK> implement the SVGElement interface.
TK> Does it still make sence at this time?
I guess a bunch of the code I looked at might have been in the DOM
implementation or the CSS implementation but seemed like there were a
lot of down casts to SVGElement. At the very least, indirectly the
Bridge relies on the elements being convertible to SVGElements for
proper handling of some attributes (otherwise the fill would have
worked first time).
I would like to see it be the case that you don't have to be
anything other than an Element for all the default bridge support
stuff to work, but I think that may be too hard.
>> 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.
TK> You are right. To me, both a custom DOM Element and a custom
TK> bridge are needed (required!?) at any time.
>> I'm currently working on the example extension stuff in
>> batik.ext.svg do we want to create an examples directory?
TK> The package is fine to me. For the example, you mean just SVG file
TK> or do we need more? In case of just SVG file, what about
TK> samples/ext/
This is good and fine.
>> Should it be a separate source tree, or a directory under batik?
TK> I vote for the same source tree (if our extensions are just a
TK> proof of concept - I mean not tons of new graphic elements or
TK> filter primitives).
It should be relatively small (with the current set of planned
example extensions probably less than a dozen source files, none of
them very large).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: BridgeExtension and the DOM
Posted by Thierry Kormann <tk...@sophia.inria.fr>.
On Wednesday 09 May 2001 14:11, you wrote:
> I'm working on the regular polygon extension example, and I have it
> working... more or less :).
nice.
> As you might guess from the title there is still a sticking point
> with the DOM.
>
> My new tag looks like:
>
> <batikExt:regularPoly fill="blue" cx="225" cy="250" r="150" sides="6"/>
What about 'regularPolygon' instead ? - It seems that you like short name,
dear... :)
> 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).
Have you extended the SVGDecoratedShapeElementBridge ? It will help but not
solve the problem (you will have all CSS properties including marker working)
> 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 :).
If I well understand, you have to re-register both your custom DOM Element
and its associated bridge for each document, right?
My understanding is that we have two problems:
a. Register Bridge *and* DOM Element before anything else (in this case,
before the DOM tree is created - otherwise it's to late at least for the
first time)
b. Provide a way to register both (Element+Bridge) only one time for a
particular extension.
If the first time, your node is black and then blue, it means that the DOM
extension mecanism is global. It's not the case for the Bridge extension
mecanism. right?
> 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?
Well, I have to wait for Stephane to come today... I will discuss with him
about that topic and give you our first conclusions.
A possible (and user-friendly) idea could be provide a mecanism to register
both DOM+Bridge when starting a Batik module.
What do you think?
When and where do you bootstrap things till now?
> 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).
Well, I have choosen Element rather than SVGElement first because I didn't
need the SVGElement API in the bridge to build GVT nodes and because I didn't
want to force extensions-developers to implement the SVGElement interface.
Does it still make sence at this time?
> 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.
You are right. To me, both a custom DOM Element and a custom bridge are
needed (required!?) at any time.
> I'm currently working on the example extension stuff in
> batik.ext.svg do we want to create an examples directory?
The package is fine to me. For the example, you mean just SVG file or do we
need more? In case of just SVG file, what about samples/ext/
> Should it be a separate source tree, or a directory under batik?
I vote for the same source tree (if our extensions are just a proof of
concept - I mean not tons of new graphic elements or filter primitives).
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org