Thanks for your reply, interesting approach.
What you are saying is that instead of using the get/setAttribute routines
you call the fireDOMModification... functions instead? If my
understanding of batik is correct what you have effectively done is to
turn it into a synchronous update model.
(1) what is the performance like when you do this?
(2) Are there any problems you can tell us about to avoid?
(3) Are you saying that your way you cannot run any Rhino Javascript
functionality?
Thanks for your reply - most informative.
Tom
On Tue, 05 Feb 2008 15:51:01 -0000, Luca Piccarreta
<[EMAIL PROTECTED]> wrote:
Hi Tom,
I'm developing an SVG editor. And... I can't imagine many scenarios in
which
bidirectional interaction is so frequent with the SVG document.
The best solution I found was an MVC approach, in which the document is
a simple Apache DOM document, the view is a Batik Document, and the
controller is a hierarchy of objects that forward DOM Mutation Events to
the Batik Document.
This way you can set and query attributes on the Apache Document without
worrying about threads and queues and whatever.
Mouse events are also dispatched through the controller hierarchy (they
are
captured and forwarded to the GUI main thread, SWT in my case).
It cost me a couple of weeks of work, but now the code is so much
cleaner.
On the other hand this approach is not feasible if the Batik document
runs
any sort of scripts (the whole stuff works if the view is not... self
modifying)
Best of luck,
Luca.
Tom McCallum ha scritto:
Hi Everyone,
Quick question of style really. I have created an app which has a
large amount of interaction between Java and Batik. I do all my
'setAttributeNS' statements in the updatemanager thread, and
'getAttributeNS' statements outside of this thread.
Obviously this leads to some situations where the sub-thread with the
'setAttributeNS' statement has not been completely executed at the time
of the 'getAttributeNS' statement in the java code.
I currently can think of two possible solutions:
Move any code that ever interacts with Batik ( most of my application )
into the Batik UpdateManager thread, effectively making everything
synchronous - kind of against the whole asynchronous-ness of Batik.
The only other way I can think is to store the attributes all locally
before the 'set' statement gets dispatched and make sure the 'get'
statement will retrieve this value and not call 'getAttributeNS', but
that seems like a rather silly option to me.
By the way part of this started because I was merrily setting
attributes and the getAttributeNS was returning 'null', and what was
happening was the liveAttributeValue table had my latest and correct
values in, while the 'attributes' table still had the original basic
values in, and the only thing I can think of is that a thread somewhere
is causing the listener between the two not to fire - any other
suggestions?
Any thoughts or comments grateful,
Tom
---------------------------------------------------------------------
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]
--
PS Note this is the new email address - delete [EMAIL PROTECTED] as it
won't work soon!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
