Hi Ivan, Cameron,
Cameron McCormack <[EMAIL PROTECTED]> wrote on 05/17/2007 11:23:45 PM:
> Ivan Andjelkovic:
> > 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...
Also depending on how you implement updates, you have the issue
that even when live tracking a change to the document may have made
the change you were about to apply to the document invalid. I'm
actually thinking that the Viewer may need to 'pause' the document
when it goes into 'edit' mode. There is a good question of how
best to have the user signal the move into edit mode. Should it
be a 'check box' in the UI. Should it happen automatically if you
click on a field (to start an edit) or try to create/delete elements?
> > 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.
Actually, I don't think editing would have to be restricted to
then. If you have rolled back changes the document is in the state
it was in earlier. Admittedly doing that may break a lot of scripts
but heck any editing of the document without being careful is likely
to do that.
Perhaps a better question would be if you include script
modifications (and I'm not sure it's a good idea just because of
memory consumption, certainly it needs to be a UI option to
turn of tracking history for dynamic documents) what would be
your granularity. Having undo one script change would likely
be almost useless. I was thinking that you might group all script
changes between user changes into one 'extra' undo block.
> > 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)?
I agree completely here. Right now the DOM viewer can be used
with any DOM, it would be a shame if we lost that. I think an
Interface that the Canvas/JSVGViewerFrame implements to fully
enable/integrate the editor would be much better.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
