[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-ui-dev] Proposal for CommandStack in JFace
|
You're
correct in that Swing's implementation only requires undo/redo methods and
not an execute method. That could be overcome by subclassing to add an execute.
Alternatively, because the "redo" is quite often the exact same code as the
execute, the convention could be to just use the redo when executing, and if the
command needed to do something different for a "real" redo, it could keep track
of whether it is being "done" or "redone".
From
what I can see, the Swing edit classes/interfaces aren't specific to text
editing; there are some implementations/subclasses that add specific
support, as that's pretty much the only area that Swing uses the command
pattern.
RE
changes performed by the widget; what you're seeing is poor implementation of
the undo support interfaces being used by the text widgets. I totally
agree that the command itself should make the model changes. However, I don't
see anything in the interfaces that require this approach.
I think they could be used in exactly the same way as the GEF/EMF
commands...
Check
out the javax.swing.undo.UndoManager class too -- you should be able to add
commands to the undo manager that indicate when the user saved, and you can
undo/redo to that point, as well as check if the last
significant edit (command) was a Save, which would indicate the editor is
clean as well.
So...
Based
on what I'm hearing/seeing so far, I'd stand by my
suggestion.
I'd
definitely like to hear if I missed something else though, and I'd like to
hear from some of the EMF folks as well...
--
Scott
==============================================================
Scott
Stanchfield scott@xxxxxxxxxxxx http://javadude.com
Lead
author of "Effective VisualAge for Java, Version
3"
http://javadude.com/evaj
VisualAge for Java Tips and
Tricks http://javadude.com/vaj
AWT & Swing FAQ Manager,
jGuru.com
Visit for Java
Enlightenment!
http://www.jguru.com
==============================================================
Scott--
I'll start off by
answering your first response. I knew about Swing's undo support but have
never looked at it until now. I think the main difference between our approach
and the Swing approach is that Swing is missing the execute portion of the
command. Swing's UndoableEdit is designed for a text widget, where the
change to the "model" is handled internally by the widget, and the change is
simply *documented* on the undo stack. UndoableEdit does NOT make the change
itself.
Our command has a
.execute(). It is intended that the model be changed only by the
command. However, there are still cases like the ones Swing designed for
(for example, continuous typing). Editors like Page Designer (an HTML
editor) can still achieve the Swing behavior by making execute() a
no-op.
Our CommandStack offers a
little more. It now contains a mechanism for marking the save point, and
then detecting when the User has undone the stack to the save point,
indicating the Editor is "clean".
Finally, Swing lets you label (and therfore translate) the command in
both directions. I recommended this at one point, but none of our
translators have identified situations where this is necessary.
Swing's classes are not a suitable
alternative.
Frank--
I don't think this is something unique to
Graphical or EMF-based editors, so I don't think you are arguing that they
should stay in GEF/EMF.
1)Are arguing
that they need to be in Core or some plugin higher-up?
2)What is missing in the proposed API that cannot be
achieved in subclasses?
UI
Team--
The TextEditor could benefit
from better undo support. Lots of cool stuff has been added to
AutoIndentStrategies, but some of these features result in two or more "edits"
to the StyledText widget. The result is that a single keystroke requires
multiple undos. For an example, type a Javadoc header '/**' in front of
a method and press ENTER, then undo the change.
-Randy
| Scott Stanchfield
<scott@xxxxxxxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx
01/04/2003 02:18 PM Please respond to platform-ui-dev
| To:
platform-ui-dev@xxxxxxxxxxx cc:
platform-ui-dev-admin@xxxxxxxxxxx Subject:
RE: [platform-ui-dev] Proposal for CommandStack in
JFace |
This is the type
of thing that would make me suggest switching both
implementations to the
Swing undo framework. It's very similar (from what I
see so far), and
doesn't have any dependency on UI code (despite being
under
javax.swing.undo).
Because it's in the Java core, both EMF and
GEF (as well as anything else
that wants undo support) could use it without
depending on other plugins.
Thoughts?
--
Scott
==============================================================
Scott
Stanchfield scott@xxxxxxxxxxxx
http://javadude.com
Lead author of "Effective VisualAge for Java,
Version 3"
http://javadude.com/evaj
VisualAge for Java Tips and Tricks
http://javadude.com/vaj
Visit for Java Enlightenment!
http://www.jguru.com
==============================================================
>
-----Original Message-----
> From:
platform-ui-dev-admin@xxxxxxxxxxx
>
[mailto:platform-ui-dev-admin@xxxxxxxxxxx]On Behalf Of
frankb@xxxxxxxxxx
> Sent: Saturday, January 04, 2003 2:12 PM
> To:
platform-ui-dev@xxxxxxxxxxx
> Cc: platform-ui-dev@xxxxxxxxxxx;
platform-ui-dev-admin@xxxxxxxxxxx
> Subject: Re: [platform-ui-dev]
Proposal for CommandStack in JFace
>
>
> This proposal isn't
acceptable for EMF. EMF's common commands are UI
> independent - they
can't have a dependency on JFace. The proposed API is
> also not
sufficient.
>
>
Frank.
>
>
>
>
>
>
>
Randy
>
>
Hudson/Raleigh/IBM@IBM
To:
> platform-ui-dev@xxxxxxxxxxx
>
>
US
cc:
>
>
Sent by:
Subject:
> [platform-ui-dev]
Proposal for CommandStack in JFace
>
>
platform-ui-dev-admin@
>
>
eclipse.org
>
>
>
>
>
>
01/03/2003
06:11 PM
>
>
Please respond to
>
>
platform-ui-dev
>
>
>
>
>
>
>
>
>
>
>
GEF provides a Command and CommandStack implementation. This should be
>
moved into JFace (which was proposed _too_ late during the 2.0
>
developement
> cycle).
>
> Other technologies such as EMF
[Edit] also require their own Command and
> CommandStack. We have both
invented the wheel. When plugins
> combine GEF and
> EMF, it
becomes difficult to deal with multiple definitions of the same
>
concept/classes.
>
> Attached is a proposal for a Command and
CommandStack implementation.
> Moving them into JFace will simplify
future WSAD releases as well as the
> work of others who are combining
the "Tools" plugins mentioned above.
>
> We are considering one
more feature for the CommandStack (the ability to
> append to an
executing command), but the code itself it pretty simple and
> stable
;-)
>
> -Randy
>
>
>
>
> ####
JFaceCommands.jar has been removed from this note on January 04 2003
>
by Frank Budinsky
>
>
>
_______________________________________________
> platform-ui-dev
mailing list
> platform-ui-dev@xxxxxxxxxxx
>
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
_______________________________________________
platform-ui-dev
mailing
list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev