actionDispatcher.dispatchAfterNextUpdate - when is it send?

[rsoika]

I have a question regarding the actionDispatcher methods dispatch and dispatchAfterNextUpdate

My scenario is a little bit complex:

1. I have an UI Extension where the user can click a button. This will issue a custom Operation send from the client to the server
2. The Server implements the corresponding GModelOperationHandler and starts updating the source model according to the operation. Of course the Handler updates also the GModel.
3. As a result of the model update the UI Extension needs to be updated too. So my GModelOperationHandler sends after updating the models a custom Action called BPMNPropertyPanelUpdateAction which is an Action not an Operation.

My problem now is that when I send this final action from the server to the client with the method dispatch, the UI Extension receives this action, but did not yet see the updated GModel :-(

Before GLSP Version I used the method dispatchAfterNextUpdate to send the final action which did the trick. But now calling dispatchAfterNextUpdate will not send any action.

What could be the reason for this behavior?

[tortmayr]

Hi @rsoika.
dispatchAfterNextUpdate should be the right approach for you scenario. This ensures that the server sends the action after the model update has been sent to the client.

Regarding the dispatch API nothing has changed and dispatchAfterNextUpdate should work the same as in previous versions.
We also use it in our base GModelCreateNoteOperationHandler to select the created node after the update.
I quickly retested this and the behavior still works as expected.

Maybe you could share the source code so that we can have a a quick look otherwise it's not really possible to pinpoint the problem.

[rsoika]

Hi @tortmayr thanks for your answer. The problem is that dispatchAfterNextUpdate does not trigger anything.

Maybe I have some misunderstanding here:

• On the client in my UI Extension I defined an Action here (implementing the Action class)
• My client UIExension is dispaching this action here
• On the server I define this action now as an Operation (!) defined here
• And on the server I have a corresponding OperationHandler here which is calling a lot of internal extension classes.
• And these classes manipulate the model and dispatchAfterNextUpdate a new different Action! like here

Maybe GLSP is not treating my inital action as an Operation ?? And this is why not dispatchAfterNextUpdate does not have any effect and my queued actions get lost?

Dispatching it with dispatchworks, but it is to early and my client side gmodel is not updated yet (and did not see the changes from the server). Selecting another element and selecting the change element again shows that the uiextension now sees the new model data.

[tortmayr]

Maybe GLSP is not treating my inital action as an Operation ?? And this is why not dispatchAfterNextUpdate does not have any effect and my queued actions get lost?

Yes, your suspicion is correct. You need to define the BPMNApplyPropertiesUpdateOperation as Operation on both sides (i.e. implementing the Operation interface on the client side, and extending the Operation class on the server. Currently you have implemented the client side as plain action:

/**
 * This action is send after a property change to the backend providing the ID and the new value
 */
export class BPMNApplyPropertiesUpdateOperation implements Operation {
    static readonly KIND = 'applyBPMNPropertiesUpdate';
    readonly kind = BPMNApplyPropertiesUpdateOperation.KIND;
    constructor(readonly id: string, readonly jsonData: string, readonly category: string) { }
    args?: Args | undefined;
    isOperation: true;
}

Other than that your code looks correct to me. So hopefully that's the only issue.

[rsoika]

No, this does not work either. I already tried this and checked it now once again.

From the documentation you wrote, that an operation is send always from server to client. And my BPMNApplyPropertiesUpdateOperation is the event send from my UIExtension to the server that is operating on the model. So I understand that this should be an Action. Finally the server is sending back a different event BPMNPropertyPanelUpdateAction. And maybe that should be now the Operation.

So I changed also the BPMNPropertyPanelUpdateAction now also into an operation on my client side. - but without any positive effect.

On the other hand, my UIExtension is only implementing a IActionHandler

export class BPMNPropertyPanel extends AbstractUIExtension implements IDiagramStartup, ISelectionListener, IActionHandler {
 ....
   handle(action: Action): ICommand | Action | void {
     if (action.kind === BPMNPropertyPanelUpdateAction.KIND) {
            console.log('do update panel' + this.selectedElementId);
 ...
}

and this is as the documentation explains it..... the client seems not to know about Operations ??

Anyway, maybe my scenario is an edge-case

1. UIExtension sends Action to Server
2. Sever updates GModel
3. Server sends Operation back to UIExtension
4. UIExtension is updating its layout based on the new GModel

... strange that it worked somehow before.... Looks like a race condition....

I think I will solve the problem now in a different way: The server will simply dispatch an action containing all the Data which is needed by the UIExtension to update its layout. So the UIExtension does not need to lookup new GNodes from the model. This works fine. And when I change the diagram selection of GNodes all is updated correctly. So this proves that the GModel is new too.

[tortmayr]

From the documentation you wrote, that an operation is send always from server to client

It's exactly the other way round. Operations are always sent from the client to the server (or dispatched internally on the server).
The server is the only one that has a special handling for operations (as its the one who holds the current model state).
The client itself does not distinguish between actions and operations meaning if it would receive an operation from the server it would just be handled like any other plain action.

So I changed also the BPMNPropertyPanelUpdateAction now also into an operation on my client side. - but without any positive effect.
Yeah that was my bad. For the Java implementation it does not make a difference whether the action representation on the client side is an action or an operation. The only thing that matters is how its defined in on the server side. So your implementation was already fine here.

Anyway, maybe my scenario is an edge-case
UIExtension sends Action to Server
Sever updates GModel
Server sends Operation back to UIExtension
UIExtension is updating its layout based on the new GMod

It's not really an edge case. It's a quite common usecae that should be resolved with the dispachAfterNextUpdate. It`s really strange, that that's not working for you...

I think I will solve the problem now in a different way: The server will simply dispatch an action containing all the Data which is needed by the UIExtension to update its layout. So the UIExtension does not need to lookup new GNodes from the model. This works fine. And when I change the diagram selection of GNodes all is updated correctly. So this proves that the GModel is new too.

Good to know that you found an alternative approach. Nevertheless, it would still be interesting why the dispachAfterNextUpdate approach is not working

[rsoika]

Just one other thing related to the strange behavior in my UIExtension:

In my previous version (GLSP 1.x) my UIExtension also registered itself for the EnableToolPaletteAction - see here

This was a result of an earlier discussion here

And this action is now in GLSP 2.x also no longer working - means: my UIExtension never ever received an action with EnableToolPaletteAction.KIND . Neither in Theia nor in VSCode.

This was the other discussion a few days ago.

So at the moment I do not know how to initialize my UIExtension after the model was loaded. To me it looks like GLSP 2.x has some changes that effect my in my UIExtension in different ways....

[tortmayr]

Regarding the initialization issue:
As we discussed in the other thread, the main issue it that currently the postModelInitalization hooks does not provide the model root parameter. So you can currently not properly initalize the extension this way.
However, there is an alternative approach that should work. Instead of directly activating the extension you could dispatch a SetUiExtensionVisibilityAction. This action comes from sprotty and has a (command) action handler that should invoke extension.show() with the correct root:

  postModelInitialization(): MaybePromise<void> {
        this.actionDispatcher.dispatch( SetUIExtensionVisibilityAction.create({ extensionId: BPMNPropertyPanel.ID, visible: true, contextElementsId: [] }
    }