You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Jake B <ot...@gmail.com> on 2007/08/18 20:19:00 UTC
using Batik with JSON
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. In order to manipulate the
client-side SVG DOM tree, I would like to use JSON, passing the client
javascript commands in the form of strings and then executing them using the
eval() function. 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'. 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?
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.
Thanks.
Jake
Re: using Batik with JSON
Posted by Jake B <ot...@gmail.com>.
The advantage to using a thin-client, distributed architecture is that it
will tremendously simplify real-time collaboration, which is the
functionality that I would ultimately like to bring to the project.
Making it a thin client might entail a hit to performance, but we've made
some prototypes, and I believe that we can still produce a snappy,
functional UI under this architecture.
Thanks for the input.
Jake
On 8/23/07, noni_4444 <na...@gmail.com> wrote:
>
>
> We plan to use batik for something similar but we want to use a fat
> client.
> Why do you want to use a thin client, when user would be interacting with
> your thin client at fast speed. I mean won't using a thin client with Ajax
> effect the performance/responsiveness of your client.
>
> Naveed
>
> --
> View this message in context:
> http://www.nabble.com/using-Batik-with-JSON-tf4291082.html#a12288848
> Sent from the Batik - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: using Batik with JSON
Posted by noni_4444 <na...@gmail.com>.
We plan to use batik for something similar but we want to use a fat client.
Why do you want to use a thin client, when user would be interacting with
your thin client at fast speed. I mean won't using a thin client with Ajax
effect the performance/responsiveness of your client.
Naveed
--
View this message in context: http://www.nabble.com/using-Batik-with-JSON-tf4291082.html#a12288848
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: using Batik with JSON
Posted by Jake B <ot...@gmail.com>.
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, thomas.deweese@kodak.com <th...@kodak.com> wrote:
>
> Hi Jake,
>
> "Jake B" <ot...@gmail.com> 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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: using Batik with JSON
Posted by th...@kodak.com.
Hi Jake,
"Jake B" <ot...@gmail.com> 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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org