Thank you for the quick reply. I'm happy to hear that you think that this is feasible. I also found notes from a presentation that took place at SVG Open that coincides fairly precisely with what it is I am trying to do:
http://www.svgopen.org/2004/papers/MakingSVGaWebServiceinaMessageBasedMVCArchitecture/ The only difference is that, while their frontend is JSVGCanvas, and they have rolled their own event broker, my front-end will be Firefox, and my event broker will by an AJAX engine. I feel fairly confident now that Batik is the right choice for my project, so I will probably be fairly active on the mailing list from now on. I'll start a new thread to introduce myself and talk about my project. Thanks again for your help. Jake On 8/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Jake, > > "Jake B" <[EMAIL PROTECTED]> wrote on 08/18/2007 02:19:00 PM: > > > Hello, I'm trying to determine if Batik is an appropriate library to > > use in order to fulfill my project's special requirements. I am > > trying to construct a web application in which the users would > > interact with an SVG document within their browser. Rather than > > construct this application as a rich or fat client ( i.e., deploying > > JSVGCanvas inside a Java applet), I need to construct the > > interactive SVG front-end as a thin client. The only thing that the > > users would need to download would be a basic SVG document, and a > > minimal AJAX engine to pass UI events to the server, fetch updates > > from the server, and update the page asyncronously. > > Just up front I'm not sure that I buy that your clients will > be much thinner, > as it sounds like the clients will be making the same changes as the > server > does. However, I don't really know what your host on the server will look > like, > what other facilities it might tap into to generate the updates. > > > Basically, I need to push all of the logic to the server, and > > update the client-side SVG document by evaluating server-generated > > javascript function calls asyncronously. > > > > I believe that Batik's implementation of the SVG DOM would be superb > > for modelling the state of the client-side SVG document. However, > > every time the server-side model is changed programmatically, it > > would also need to generate javascript to update the document on the > > client's side. > > > For example, if the user were to click and drag a rectangle down to > > a new position, the client would use the AJAX engine to pass the > > user's mouse input event to the server. The server would switch this > > event, and update its model of the client's document, probably with > > a function call like ' rectangle.setAttributeNS(null, "y", "20");'. > > The server would then generate javascript code to pass back to the > > client, probably with a function call like 'rectangle.y = 20'. > > Actually the Javascript to update the client's SVG Document will look > like 'rectangle.setAttributeNS(null, "y", "20")', exactly the same > as is used on the server... > > > When the client's AJAX engine next pings the server, it GETs this code, > > runs eval on it, and updates the contents on the screen. > > > My question is, does anyone know of a way to tell Batik to generate > > javascript that can be used to manipulate client-side SVG in the > > above fashion? > > Probably the easiest thing would be to register a DOM Change Event > listener. This get's called whenever anything changes in the DOM. > The tricky thing tends to be figuring out how to tell the remote DOM > which element(s) you are manipulating. You can't send a 'pointer' and > normally you don't have id's on every element. You can try to identify > it by it's position in the DOM tree but SAX/DOM implementations may > split text elements in some cases which complicates things a bit. > > > If this functionality does not exist yet, I'm willing to write it > > myself. If anyone has any advice as to what would be the best way to > > build this functionality onto the existing core modules, I would > > greatly appreciate it if you would let me know. > > It doesn't already generate JavaScript but other than the caveat > above that is pretty simple. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
