>>>>> "AFB" == Antonio Fiol Bonn�n <[EMAIL PROTECTED]> writes:
>>
>>
>> I must say that I have a few reservations about the general
>> technique of adding new elements to SVG. I don't really know what
>> your constraints are but you might consider using a transformation
>> language like XSLT to map your custom grammer into standard SVG.
>>
AFB> I will use some brain cycles to process that idea. I had not
AFB> previoulsy thought of that.
>> However if you really need to be able to use Java2D to do rendering
>> of the element this approach is probably the only feasable one.
>>
AFB> I need no Java2D at all. But I need to make things
AFB> appear/disappear/change depending on (a set of) Java variables
AFB> which represent the state of an automation system.
Once again I don't know the details but this might be easily
accomplished by manipulating the SVG DOM directly from Java. For
simple things (like making things visible/hidden) this can be easy,
however if you have more complex changes (like updating the 'angle' of
a line based on a reading) you may end up 'replicating' this logic in
the XSLT and the Java code.
AFB> So, to use XSLT I would have to generate some dynamic XML which
AFB> would change only a little bit, every time a variable
AFB> changes. Then I would have to do an entire transform, and an
AFB> entire render.
This is an option, the other is to manipulate the SVG DOM instead
of the 'high level' DOM. I realise that this might not be 'good' in
your case.
AFB> If I use custom "g" components that make their content be
AFB> rendered/not rendered, I only would need to do the entire render,
AFB> thus being much more efficient.
Essentially the same logic to map changes in the custom element
to changes in the SVG DOM would need to be implemented here. Although
it would be easier to avoid the temptation to break encapsulation this
way.
My concern here is that this approach 100% binds you to a
specific SVG renderer (Batik). If you can limit your code to
manipulating the SVG-DOM you may be able to work with other SVG
renderers 'down the road'. If you are already 100% bound then this
isn't really and issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
