Apologies in advance for a fairly long post. If I'm not misunderstanding, the basic design of what you want is relatively easy with just SVG and Batik. (Even without adding new attributes or elements.<grin/>) I'll have to defer to Thomas on the extending approach, I've not used that as yet.
Modifying your example slightly, <svg xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns="http://www.w3.org/2000/svg";> <defs> <g id="chair"/> <style type="text/css"><![CDATA[ .yes { fill:green; } .no { fill:red; } ]]></style> </defs> <use id="chair1" xlink:href="#chair" x="10" y="10"/> <use id="chair2" xlink:href="#chair" x="20" y="20"/> ... </svg> For a simple change in state like the vote, you could have the data stream that you read for updates contain the id and vote. For example, a CSV data stream with one change per line: chair1,yes chair2,no ... (For more complex changes, a more complex data stream might be necessary. But, to start, simpler might be better.) As each vote comes in you do the following, doc.getElementById( idstr ).setAttributeNS( null, "class", vote ); Of course, you will need the document in the 'doc' variable, and the 'idstr' and 'vote' need to be set up correctly. (Not to mention error checking.) But this is the basic idea. I could also see using a person's name for the chair id instead of a number, which could lead to other interesting features. If you want to keep up with more than a single state, associating a Java object with each "chair" would allow you to manipulate the the object in arbitrary ways. Also the "class" attribute can contain a space-separated list of classes. As long as the properties don't conflict, this allows you to make fairly complex visual effects. This approach would require you to develop less code and the SVG files could be created using standard tools. (That may not be an issue yet, but you can bet that someone is going to ask to make the picture more complex over time. Good tools would make that less of a hardship.) Later, G. Wade Stefán Freyr Stefánsson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello. > > 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 > ;o). > > 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";> > <defs> > <g id="chair".... > </defs> > > <use xlink:href="#chair" x="10" y="10" embla:chair-id="1"/> > <use xlink:href="#chair" x="20" y="20" embla:chair-id="2"/> > ... > </svg> > > 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 > this. > > 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"/> > ... > </svg> > > 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. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iQEVAwUBPzGFhr0ge6mq4AL2AQKPRQgAzAOHLp5bo9EtRPEInzJaxJkOL4BExCI6 > 70PmP4fvYjSi2hTvGEeCzxQAI5/br2dcflKZ4s5p59F/QfbVwR1dhFaIfqSr4nN7 > ry5KYU1sRlVbJ5U+8F8JY20hDNDKSU88yfxybbYSoNt6tP6C5K60paKo9Nm+ucft > 7aLqZ/pWqJezAWTFNy+5yflTJaNdhdNGxaJql8LteZRdLeIXfVwBfXEBEUgpCoAV > JyyuBO8nvHibSGU4dRdL2U5hdJ/PeTE5dRBdYEJvdfaClJtiAwItql8+r8ZsKyTD > hVMrd5i95ZoCF4GOUh+MSOYREQ0lIZqVtRENQ6qPG/JVs07cvy5Bdw== > =22s5 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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]
