Hi Tom,
no I'm not calling any fireDOMModification.
The document, the one that is going to be loaded from disk, saved to
disk (remember,
it's an editor!), is just an Apache Document.
A root EditPart listens for DOM events on the Apache Document.
When a DOMNodeInserted event is detected, two objects are created, one
is an EditPart,
another one is the ViewPart. The ViewPart is the SVG Node. The EditPart
is a simple object
that does again the same job of the rooteditpart. It listens for
Mutation Events on its own Apache Node.
and creates child editparts and child viewparts when necessary.
When an EditPart sees that its own Viewpart has fired a
DOMAttributeChanged, it simply calls
setAttribute for the view element (but in the Batik thread).
When an EditPart sees that a child of the document is deleted, it
deletes also the corresponding
child editpart, and the corresponding viewPart.
So... the view is synchronized to the document.
But the document is not synchronized to the view. That might be much
more difficult to implement.
Just look at it as unidirectional synchronization.
Ciao,
Luca.
Tom McCallum ha scritto:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
