Home » Modeling » GMF (Graphical Modeling Framework) » obtain command for request without edit part
| obtain command for request without edit part [message #109557] |
Wed, 07 March 2007 07:28  |
Eclipse User |
|
|
|
Hi,
I'm stuck with a problem concerning requests, commands and edit parts.
In short, I'm trying to implement a two-step command that first
creates a view and element and then does some further editing on this
object. The second editing step, which includes reconnecting an
existing connection to the new view/element, should ideally be handled
by requesting a command from an edit part. However, since the new
view/element does not yet exist, I haven't the corresponding edit
part. Hence, I either have to (re)implement the reconnect logic or
somehow obtain the edit part. I've tried to create the edit part
manually, but I couldn't make this hack to work.
One solution is to post a request asynchronously, but how. Another
solution is to register a listener somewhere, to get hold of the edit
part (when it is created) and then request and execute the command
later.
Any suggestions?
Hallvard
|
|
|
| Re: obtain command for request without edit part [message #110067 is a reply to message #109557] |
Wed, 07 March 2007 17:34  |
| Eclipse User |
|
|
|
Hallvard,
The approach we have taken in the GMF Runtime, is to use an IAdaptable
in the second request and command from which the editpart can be
retrieved when the second command is run.
Here is some pseudocode that will explain this in more detail.
The CreateViewRequest will return an IAdaptable that will adapt to the
new view created after the CreateCommand is executed...
Command firstCommand =
containerEditPart.getCommand(createViewRequest);
IAdaptable newViewAdapter = (IAdaptable)
((List)createViewRequest.getNewObject()).get(0);
My first suggestion to get the reconnect command, would be to use this
IAdaptable in a custom request...
Since you are trying to do a reconnect command, you cannot use the
ReconnectRequest as it is requires the editparts, so you will need to
create your own 'DeferredReconnectRequest' and editpolicy to supply the
command. To reconnect a relationship and the connection view, you will
need the commands supplied by the GraphicalNodeEditPolicy (see
getReconnectSourceCommand/getReconnectTargetCommand) and the command to
reorient the semantic relationship (see
getReorientRefRelationshipSourceCommand/getReorientRefRelati onshipTargetCommand).
At a quick glance of these editpolicies, it seems to me that this is
possible, but you will have to copy more code that potentially desired.
My second suggestion, would be to postpone the sending of the
ReconnectRequest until after your first command executes, by creating a
simple command whose doExecute() method sends the request and executes
the command retrieved. As an example, take a look at the
DeferredCreateConnectionViewCommand. It's doExecuteWithResult() method
shows you how to find the editpart from the viewer using your
newViewAdapter. You can then send a ReconnectRequest with the editparts
and avoiding knowing anything about how the reconnect works.
The one problem with this second approach is that if you are testing for
enablement of your two-part command, you will not be able to test if the
reconnect command will succeed.
I hope that was clear. Let me know if you have any questions.
- Cherie
Hallvard Trætteberg wrote:
> Hi,
>
> I'm stuck with a problem concerning requests, commands and edit parts.
> In short, I'm trying to implement a two-step command that first
> creates a view and element and then does some further editing on this
> object. The second editing step, which includes reconnecting an
> existing connection to the new view/element, should ideally be handled
> by requesting a command from an edit part. However, since the new
> view/element does not yet exist, I haven't the corresponding edit
> part. Hence, I either have to (re)implement the reconnect logic or
> somehow obtain the edit part. I've tried to create the edit part
> manually, but I couldn't make this hack to work.
>
> One solution is to post a request asynchronously, but how. Another
> solution is to register a listener somewhere, to get hold of the edit
> part (when it is created) and then request and execute the command
> later.
>
> Any suggestions?
>
> Hallvard
|
|
|
| Re: obtain command for request without edit part [message #110080 is a reply to message #109557] |
Thu, 08 March 2007 02:55 |
| Eclipse User |
|
|
|
I managed to find a solution, based on my own suggestions (sometimes
just writing a question makes you find the solution). It was harder
than it needed to be.
First I added a listener that was triggered when the edit part for the
newly created view/element was added (addEditPartListener on what I
knew was the parent). Then I created a request and obtained the
command, which was executed by the command stack. However, since the
first step was triggered as part of committing the transaction, the
latter needed to be done inside a Runnable given to Display.asyncExec.
This ensured the second step got it's own transaction, with the
side-effect that the user must undo the whole operation in two steps,
first to undo the post-create editing, then to undo the create.
Hallvard
On Wed, 07 Mar 2007 13:28:16 +0100, Hallvard Trætteberg
<hal@idi.ntnu.no> wrote:
>Hi,
>
>I'm stuck with a problem concerning requests, commands and edit parts.
>In short, I'm trying to implement a two-step command that first
>creates a view and element and then does some further editing on this
>object. The second editing step, which includes reconnecting an
>existing connection to the new view/element, should ideally be handled
>by requesting a command from an edit part. However, since the new
>view/element does not yet exist, I haven't the corresponding edit
>part. Hence, I either have to (re)implement the reconnect logic or
>somehow obtain the edit part. I've tried to create the edit part
>manually, but I couldn't make this hack to work.
>
>One solution is to post a request asynchronously, but how. Another
>solution is to register a listener somewhere, to get hold of the edit
>part (when it is created) and then request and execute the command
>later.
>
>Any suggestions?
>
>Hallvard
|
|
|
| Re: obtain command for request without edit part [message #110093 is a reply to message #110067] |
Thu, 08 March 2007 03:17 |
| Eclipse User |
|
|
|
Cherie,
Thanks for your hints. I eventually used a variant of the second
approach, where a second command is executed. I didn't manage to get
it running within the first transaction, so in addition to the
enablement problem, I also have a two-step undo problem. There are
some differences in my setup that makes it a bit difficult to use the
code from DeferredCreateConnectionViewCommand, e.g. that I don't even
have the view/element pair that is created. However, I'm sure I can
cook up a solution that's closer to what you suggest. The enablement
problem isn't that important, since the reconnection step is more of a
convenience than a requirement.
Ideally, there should be a mechanism for "chaining" commands together,
with support for passing results to "future" commands.
Hallvard
On Wed, 07 Mar 2007 17:34:50 -0500, Cherie Revells
<crevells@ca.ibm.com> wrote:
>Hallvard,
>
>The approach we have taken in the GMF Runtime, is to use an IAdaptable
>in the second request and command from which the editpart can be
>retrieved when the second command is run.
>
>Here is some pseudocode that will explain this in more detail.
>
>The CreateViewRequest will return an IAdaptable that will adapt to the
>new view created after the CreateCommand is executed...
>
>Command firstCommand =
>containerEditPart.getCommand(createViewRequest);
>
>IAdaptable newViewAdapter = (IAdaptable)
>((List)createViewRequest.getNewObject()).get(0);
>
>My first suggestion to get the reconnect command, would be to use this
>IAdaptable in a custom request...
>
>Since you are trying to do a reconnect command, you cannot use the
>ReconnectRequest as it is requires the editparts, so you will need to
>create your own 'DeferredReconnectRequest' and editpolicy to supply the
>command. To reconnect a relationship and the connection view, you will
>need the commands supplied by the GraphicalNodeEditPolicy (see
>getReconnectSourceCommand/getReconnectTargetCommand) and the command to
>reorient the semantic relationship (see
> getReorientRefRelationshipSourceCommand/getReorientRefRelati onshipTargetCommand).
>
>
>At a quick glance of these editpolicies, it seems to me that this is
>possible, but you will have to copy more code that potentially desired.
>
>My second suggestion, would be to postpone the sending of the
>ReconnectRequest until after your first command executes, by creating a
>simple command whose doExecute() method sends the request and executes
>the command retrieved. As an example, take a look at the
>DeferredCreateConnectionViewCommand. It's doExecuteWithResult() method
>shows you how to find the editpart from the viewer using your
>newViewAdapter. You can then send a ReconnectRequest with the editparts
> and avoiding knowing anything about how the reconnect works.
>
>The one problem with this second approach is that if you are testing for
>enablement of your two-part command, you will not be able to test if the
>reconnect command will succeed.
>
>I hope that was clear. Let me know if you have any questions.
>
>- Cherie
>
>Hallvard Trætteberg wrote:
>> Hi,
>>
>> I'm stuck with a problem concerning requests, commands and edit parts.
>> In short, I'm trying to implement a two-step command that first
>> creates a view and element and then does some further editing on this
>> object. The second editing step, which includes reconnecting an
>> existing connection to the new view/element, should ideally be handled
>> by requesting a command from an edit part. However, since the new
>> view/element does not yet exist, I haven't the corresponding edit
>> part. Hence, I either have to (re)implement the reconnect logic or
>> somehow obtain the edit part. I've tried to create the edit part
>> manually, but I couldn't make this hack to work.
>>
>> One solution is to post a request asynchronously, but how. Another
>> solution is to register a listener somewhere, to get hold of the edit
>> part (when it is created) and then request and execute the command
>> later.
>>
>> Any suggestions?
>>
>> Hallvard
|
|
|
| Re: obtain command for request without edit part [message #110211 is a reply to message #109557] |
Thu, 08 March 2007 09:34 |
| Eclipse User |
|
|
|
Hallvard,
You might try implementing the reconnect semantics in an edit helper or
edit helper advice (in the 'configure' step of the creation of your new
element) and let a canonical edit policy handle updating the views for you.
As an example, you can look at the LEDEditHelper in the runtime logic
example, which implements the #getConfigureCommand to configure a new
LED after it is created. The configure is done in the same operation as
the creation so you'll only get one entry on the operation history.
Regards,
Linda
Hallvard Trætteberg wrote:
> Hi,
>
> I'm stuck with a problem concerning requests, commands and edit parts.
> In short, I'm trying to implement a two-step command that first
> creates a view and element and then does some further editing on this
> object. The second editing step, which includes reconnecting an
> existing connection to the new view/element, should ideally be handled
> by requesting a command from an edit part. However, since the new
> view/element does not yet exist, I haven't the corresponding edit
> part. Hence, I either have to (re)implement the reconnect logic or
> somehow obtain the edit part. I've tried to create the edit part
> manually, but I couldn't make this hack to work.
>
> One solution is to post a request asynchronously, but how. Another
> solution is to register a listener somewhere, to get hold of the edit
> part (when it is created) and then request and execute the command
> later.
>
> Any suggestions?
>
> Hallvard
|
|
|
Goto Forum:
Current Time: Tue Nov 04 08:32:29 EST 2025
Powered by FUDForum. Page generated in 0.04096 seconds |
Home