Which commmand to use to edit multi valued attribute

[quratulain-ali]

Which model server command to use to edit multi-valued properties? When I use the AddCommand it adds the element to multivalued property? Is there a ReplaceCommand available?

[eneufeld]

Hi @quratulain-ali ,

a SetCommand with a path that includes the index of the property you want to edit should do the trick.

Best,
Eugen

[quratulain-ali]

Hi @eneufeld,

Thanks for your reply. I am using a SetCommand asks for:

• owner which is ModelServerReferenceDescription, I pass the model uri with the id of the element and eclass as the class of model element
• feature which is string name of the feature to be updated
• dataValues which you want to update

I cannot get you where can I pass the index?

Thanks,
Qurat ul ain

[CamilleLetavernier]

Hi,

In EMF, the SetCommand is indeed what you need. If you want to replace the entire collection with a new list, you don't have to worry about indices: you can simply specify the new list as the value of the Set command:

List<?> newListValue = getNewValue();
Command command = SetCommand.create(editingDomain, eObject, eFeature, newListValue);

In that case, we simply expect the eFeature to be multivalued (upperbound > 1)

Based on your latest reply, I assume you're using the modelserver-client package to create these commands. In that case, you need to create a SetCommand, that will be interpreted by the server to generate and execute the corresponding EMF SetCommand:

const newListValue = getNewValue();
const command = new SetCommand(owner, feature, [newListValue]);

The trick is that the SetCommand isn't really clear about what the type of "newListValue" should be. For setting a new list value, the server expects a single value (We're not adding multiple elements; we're replacing the entire list as an atomic operation, so we need only one value. But this single value can be an array of objects).

I think there might be an issue with the way the SetCommand constructor is typed; so it might not actually allow the [newListValue] argument (it expects an array of EObjects like [objectRef1, objectRef2], but in this case we need to specify the entire list: [[objectRef1, objectRef2]]).

A workaround for this issue would be to create a CompoundCommand that contains two sub-commands:

• A RemoveCommand to clear the list
• An AddCommand that contains all the new values to be added

(Note: you should still try the SetCommand with the array value first; but if that doesn't work, fallback to the suggested workaround).

HTH,
Camille

[CamilleLetavernier]

Hey,

If the command is triggered by the Theia Frontend, I think there's indeed something fishy with the way the ensureCommandPrototype function is called (As you mentioned, it can't properly handle subclasses of ModelServerCommand, because a Command cannot be both a "ModelServerCommand" and a "CompoundCommand" at the same time). Therefore, the follow-up patchOrCommand instanceof ModelServerCommand check will fail, and the command will be treated as a JSON Patch instead (which will just cause errors, because it's definitely not a JSON Patch).

However, this shouldn't be an issue if the CompoundCommand is instantiated in the Theia backend directly, as the prototype chain should be correct in that case. Do you instantiate your Commands on the Theia frontend side? (I believe that, for the Frontend at least, we now moved to JSON Patches exclusively in all our example apps, which might explain why we didn't catch this issue).

Nevertheless, this surely looks like a bug.

[quratulain-ali]

Hi Camille,

Thanks for your reply. Yes, I am instantiating command from Theia Frontend; that's why this issue came up. I am not sure how we can instantiate CompoundCommand from Theia backend? If we want it to be triggered from the client side

[CamilleLetavernier]

I am not sure how we can instantiate CompoundCommand from Theia backend? If we want it to be triggered from the client side

You can implement a more abstract Theia service (e.g. an interface with a "replaceListValues" function that the frontend can call), and implement this service in the Theia Backend (Using a Theia JsonRpcConnectionHandler). This way, the client is responsible for triggering the event (by calling this service), but the command will actually be instantiated in the Backend. It's not always the most appropriate course of action, because it adds an indirection, but the frontend needs less knowledge about the implementation of the model server.

[quratulain-ali]

Perfect thanks. I will try this. Do you know if the above-identified bug can be fixed?

[CamilleLetavernier]

Hi,
We're trying to focus on more Web-native implementations, so I wouldn't expect a fix in the EMF-based model server. Instead, I would recommend one of the following workarounds:

• Instantiate the EMF Command in the Theia backend (as described in my previous post)
  or
• Use JSON Patches instead of EMF Commands. They shouldn't be affected by the prototype-chain issue when being sent over Json RPC from the frontend to the backend or server (although JSON-to-EMF patches also have their limitations, as there are some key differences in how EMF Model/Commands work compared to JSON Documents/Patches)