-----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]
