Hey Ivan. Ivan Andjelkovic: > I have been working on creating those pop - ups, updating the view in > the Viewer when the document changes and editing the tree, the table > and the text area. > Here are some issues so far: > > 1. Allowing the "don't live track" option might cause the Viewer to > become incompatibile with the document - for example some nodes or > attributes might have been removed from the document, but are still > shown in the Viewer, etc. > If so, there wouldn't be much sense to allow editing. But anyway there > are few possibilities here: > a) Allow the "don't live track" option anyway. In this case > compatibility of the document shown in the Viewer and the document > itself has to be determined > when the Viewer is used for editing the document. If incompatibile - > send some notification that document cannot be edited due > incompatibility with the Viewer... > b) Set the Viewer to be "always_dynamic" and always live - track > the document. > c) An addition to b) is implementation of command pattern to allow > undo and redo actions for the changes on the document. > I think of c) as the most useful.
That’s a good point. I do like the idea of being able to browse the “history” of the document–is that what you mean by the undo and redo actions? Would you also include changes made by scripts in the document? Either way, editing would have to be restricted to when viewing the “up to date” document. > 2. If the document is shown on JSVGCanvas, then the updates of the DOM > should be called using the UpdateManager. Adding a method > setCanvas(JSVGCanvas canvas) instead of setDocument(...) would allow > the Viewer to get the canvas anytime and perform the update using the > canvas's UpdateManager. This way there would be no need of calling the > setDocument(...) method explicitly outside of the Viewer. > a) But still setDocument(...) would remain public to handle the > existing code... > b) New method setCanvas(...) would be available for tracking the > changes on the canvas where the document is displayed. Hmm. I think giving the JSVGCanvas explicitly to the Viewer is giving too much information to it. At this point, all the Viewer component needs is the document and a way to schedule the modifications to the document (i.e., dispatching a runnable to the UpdateManager’s queue). Perhaps later, you (or Jasleen) will need access to other things too (like the CSSEngine). Perhaps an interface to provide this information to the Viewer would be better? If not, then maybe just give the BridgeContext to the Viewer (from which you can get access to the UpdateManager)? -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
