xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefán Freyr Stefánsson <stef...@althingi.is>
Subject Voting system UI - manipulating DOM vs. Extending Batik
Date Wed, 06 Aug 2003 22:47:30 GMT
Hash: SHA1


I sent a message to this mailing list yesterday and got some responses which I 
thank you for (G. Wade Johnson and Thomas DeWeese).  The message can be found 
here: http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03800.html.

Since then I've been reading everything I can get my hands on about Batik and 
one thing intrigued me.  I may be way off base but I still want to share my 
ideas with the list... if nothing more I hope I provide you with a good laugh 

The problem at hand is that I want to be able to display the result of a vote 
in an SVG image.  The image is a floor plan and the votes are displayed per 
seat (green seat = yes vote, red seat = no vote).  So my original idea was to 
create a regular SVG image and embed attributes specific to our scenario.  
The SVG might look something like this:

<svg xmlns:embla="http://www.althingi.is/2003/embla">
    <g id="chair"....

  <use xlink:href="#chair" x="10" y="10" embla:chair-id="1"/>
  <use xlink:href="#chair" x="20" y="20" embla:chair-id="2"/>

Then a Java object would communicate with the voting system and get the voting 
status of each "chair" and somehow update the DOM tree to display the chairs 
in different colors, for example by adding the fill attribute to the element 
containing the correct "chair-id".

Then I read the section about "Extending Batik" on the Batik website 
(http://xml.apache.org/batik/extendingBatik.html) and that got me thinking 
that maybe that would be a better way to solve my problem of displaying the 
voting results instead of manipulating the DOM tree like described before. 
Mr. DeWeese: I noticed that you wrote the code mentioned in that section (the 
example DOM/bridge extensions) so I really hope that you have some input on 

My new idea is that maybe it would be better to "extend" SVG for our 
application.  This would involve writing a new bridge extension for my 
"chair" element so that the aforementioned svg might look something like:

<svg xmlns:embla="http://www.althingi.is/2003/embla">
  <embla:chamber-chair id="1" x="10" y="10" width="30" height="30"/>
  <embla:chamber-chair id="2" x="50" y="20" width="30" height="30"/>

Of course, this SVG wouldn't be viewable in any "normal" SVG viewer but that's 
quite allright, even preferrable.  The only thing we want to do with this SVG 
image is define the layout of the floor for that particular application, 
we're not going to be exporting this image or anything.

I've managed to gain some understanding on how to implement way #1 but way #2 
is a bit more vague (probably because I haven't done any trials on it).  
First of all I'd like to know if I'm way off with this... do you think this 
is a stupid idea?  If so, why?  I don't know exactly what it is but #2 has 
something about it that I like... probably that it simplifies the SVG.  
Another thing about #2 that I'm not completely sure about is how it would be 
best to connect to the voting system to get the voting status for individual 
seats.  Should the bridge object itself contain code that connects to the 
voting system?  What if the voting system pushes the information so that when 
a vote is cast from a particular chair a notification is sent to our client 
application?  Should the voting system talk to the bridge object or what?  
How would the image be updated by using the bridge object?  I suppose that it 
would be possible to still use the same method as in #1, that is manipulate 
the DOM tree by getting all the <chamber-chair> elements and adding style 
attribute(s) to it to change the color.

The final question is: Would I be gaining something by implementing my own 
bridge element (ChamberChairElement)?  That would probably make it more 
difficult to change the appearance of the chair on the rendered image right?

Well, I hope someone has been able to read this whole thing through, sorry for 
the long mail.

Kind regards, Stefan Freyr.
Version: GnuPG v1.2.2 (GNU/Linux)


To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message