You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Ivan Andjelkovic <an...@gmail.com> on 2007/04/14 06:26:04 UTC

Introducing enchancing DOMViewer on Google summer of code

Hi everyone,
My application about enhancing BATIK's document viewer has been accepted on
Google summer of code.
The application is about enhancing document manipulation through the BATIK's
DOMViewer component. User should be able not only to browse but also edit
the content of the document After performing the changes, the document
referred by the Viewer needs to be refreshed.
So the following options need to be added:
1. The user – requested option which would update the state of the DOMViewer
(the tree and the attribute list) from the content of the document,
2. The options for editing elements of the document, such as adding new
elements and attributes, and changing the values of the ones already in the
list.
The goal of the project is to develop intuitive GUI which will allow the
manipulation.

Ivan

Re: Introducing enhancing DOMViewer on Google summer of code

Posted by th...@kodak.com.
Hi Ivan,

    I am very sorry to take so long to respond ("real" work has been
insane).

"Ivan Andjelkovic" <an...@gmail.com> wrote on 04/14/2007 
12:26:04 AM:

> My application about enhancing BATIK's document viewer has been 
> accepted on Google summer of code.

   This is great.

> The application is about enhancing document manipulation through the
> BATIK's DOMViewer component. User should be able not only to browse 
> but also edit the content of the document After performing the 
> changes, the document referred by the Viewer needs to be refreshed. 

   Sounds useful.

> So the following options need to be added: 
> 1. The user ? requested option which would update the state of the 
> DOMViewer (the tree and the attribute list) from the content of the 
document,

    This shouldn't be too hard, The current code does this when you toggle 

the showing of empty text nodes. However it "forgets" the state of the
tree viewer when that happens, which you would not want to have happen.

    You might consider using Mutation events to update the DOM viewer 
automatically (perhaps with a "don't track live DOM" check box). For
most documents this should be fairly reasonable, especially if you
were careful to only really look at the mutation events that effected
what was being shown in the DOMViewer.

> 2. The options for editing elements of the document, such as adding 
> new elements and attributes, and changing the values of the ones 
> already in the list. 

    The UI should be the only really challenging part of this, the
DOM is really simple from this point of view; createElementNS,
setAttributeNS, removeAttributeNS, appendChild, insertChild, 
removeChild.   You would probably want to provide popups for 
common elements/attributes.

    If you wanted to try and muck directly with CSS things would be
trickier since you would need to create a UI for stylesheets and then
automatically tweak something like 'class' to effect a single element.

> The goal of the project is to develop intuitive GUI which will allow
> the manipulation. 

    It's great to have you helping to improve Batik.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org