Best practice for assigning IDs?

[dmm9]

Particularly, when working with EMF models, what is considered a suitable method to generate the ElementID? For example, in:

GNode node = new GNodeBuilder().id(???).build();

Until now, I have used the URIFragment, which is, by design of EMF, unique for each element in the resource.

String id = eObj.eResource().getURIFragment(eObj);

So far so good... or not?

This ID seems the obvious and most straightforward way of mapping EMF EObjects to diagram elements, and it works seamlessly in both directions: EMF to GModel when generating the diagram and GModel to EMF when performing actions on the diagram like edit, select, etc. However, it turns out that this ID is not liked by everyone out there.

I have tried to add some playwright tests, and it turns out that..

DOMException: Failed to execute 'querySelectorAll' on 'Document': 'xxxx/xxx/xx' is not a valid selector

This error means that such ID cannot be used to look for elements in the DOM. It's not a GLSP's or playwright's error, but pure browser error, as explained in this stackoverflow answer.
It seems that for HTML 4:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

Whereas for HTML 5 and newer, the rules are much more permissive:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace.

There are no other restrictions on what form an ID can take; in particular, IDs can consist of just digits, start with a digit, start with an underscore, consist of just punctuation, etc.

Whether or not the browser (playwright chromium, in this case) should accept such ID with slashes is maybe out of scope here. However, to overcome this situation I see 2 alternatives:

1. Change the way of generating the IDs

• Risk: A character substitution algorithm may render the ID transformation to work only in one direction. For example, changing slash for underscore in an uri like some_object/some_child would be translated to id=some_object_some_child, and then the way back would yield some/object/some/child, which would be wrong.
• Needs: a good explanation/hint in GLSP documentation about how and why to create IDs which are compatible with playwright-chromium

2. Adapt glsp-playwright

• The glsp-playwright is using css-selectors to find elements in the DOM by it's id attribute. However, instead of using locator('#${id}'), it could switch to attribute selectors: locator('[id=${id}]'), as suggested in this stackoverflow answer. The former fails, while the latter works.

Therefore, I come back to my original question. Is the URIFragment "as is" a best-practice for model element IDs, or is there another alternative? In case URIFragment is the preferred way, how to overcome the issue with playwright?

[ndoschek]

Hi @dmm9,

Thank you for reaching out!

Overall, I'd like to mention the concept of the *IdGenerator, particularly in the context of the Java implementation of the GLSP server.
It seems you're likely using this based on the code snippet you shared.
The *IdGenerator is essential for generating IDs for GModelElements and therefor for managing the model elements, for example in the GModelIndex.

For example, if you use EMFDiagramModule as a base implementation, it is necessary to bind an available EMFIdGenerator.
There are different implementations available already, just to name two here:

• FragmentIdGenerator - creates the same IDs as you mentioned above, i.e. EMF URI fragments as element IDs
• UUIDIdGenerator - creates UUIDs as element IDs (in the style of f58t61at-928c-4ok8-78s9-fdbnp9uz15f3)

Alternatively, if you're working with a node-based GLSP server, uuid generation is typically the default mechanism. For instance, you can create a new ID using uuid.v4() (import * as uuid from 'uuid';).

Given your testing requirements, I would recommend using UUIDs as element IDs. This method should align well with your testing framework and offer the compatibility you need.
UUIDs eliminate the compatibility issues encountered with URI fragments in CSS selectors. UUIDs adhere to web standards, containing only alphanumeric characters and hyphens, ensuring they work seamlessly in Playwright tests without the syntax problems URI fragments may cause.

If you have any further questions or need more clarification, feel free to get in touch. We're always happy to assist!

HTH and best regards,
Nina

[dmm9]

Hi, thanks for the thorough explanation. I hadn't noticed the different *IdGenerators that are available. I think the UUID should be suitable to comply with the CSS selectors, as you say. Nonetheless, debugging with those IDs will be funny ^^