xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bishop, Michael W. CONTR J9C880" <Michael.Bis...@je.jfcom.mil>
Subject RE: Antwort: String to SVGElement?
Date Mon, 13 Mar 2006 18:51:42 GMT
Well I have a design in place...I have a set of actions that describe
how things are to be done.  The "create element" action is the only one
where the entire element is sent.  There are optional attributes for the
action; a "parentId" that describes which element the new element is to
be appended to (root element, g element, etc.) and a "beforeId" that can
specifically describe which element the new element will be inserted
before (Node.insertBefore(...)).  Moves, updates and deletions work like
you describe.  You find the element by its ID and apply modifications.


To send the outgoing message, I use XMLBeans to transform the Element to
an XmlObject which can be represented as a String.  Now I need to do the
reverse, but I don't think XMLBeans can do it, so I need to find another
way.  I'd hate to use a SAXParser to parse the element into a new
document, then do a copy from one document to another.  I'd rather
import it directly into the client document.


Maybe another approach would be the "create element" message has a
different structure?


-          Tag name.

-          Namespace.

-          Collection of attributes.

-          (Optional) parentId.

-          (Optional) beforeId.


I posted here because I thought maybe someone had done something like
this before; most of the stuff I've undertaken for this project has been
a learning experience.  I haven't done anything similar to this


Michael Bishop



From: dvholten@computer.org [mailto:dvholten@computer.org] 
Sent: Monday, March 13, 2006 1:36 PM
To: batik-users@xmlgraphics.apache.org
Subject: Antwort: String to SVGElement?



that looks like a tricky problem. I see no simple solution. 
If I would have to design something like this I would try to go this
- master and slaves (clients) start with the same document. So all have
the same structure and id's. 
- i would try to detect changes in the master element's attributes and
propagate just that: id, attribute and new value. 
- on client-side, I would locate the element by id and change the

A problem is structural changes: where to put new elements? When they
are within a <g> ? 
That may be possible when you send the parent's id... 

So it can be reduced to some basic operations: 
- insert new element under a parent-element 
- delete element(id) ( plus it's children) 
- modify element-attributes 
- add/delete attributes(?) 

Maybe it's simpler to distribute the modification-commands (which create
the dom-modifications) 
and do the same modifications in the clients. 

DOM consistency is quite a challenge: namespace-things, valid

If you can give some more details we may provide some more ideas. 


View raw message