Stricter Identifiers Value validation

[alexander-schranz]

As documented in #618 not all search engines support all kind of characters for identifiers. So maybe it make sense to be stricter here already on the abstraction level to avoid problems if somebody switches to another engine:

• https://www.meilisearch.com/docs/learn/getting_started/primary_key#formatting-the-document-id
• https://support.algolia.com/hc/en-us/articles/13959016478609-Are-there-any-forbidden-characters-when-formatting-objectIDs

As I'm unsure if Meilisearch will support URN like ids in future: https://github.com/orgs/meilisearch/discussions/872

[alexander-schranz]

@Toflar what kind of document identifiers are you using currently in your projects and contao backend search?

[Toflar]

I've built some type prefix. So we have files__* and news__* etc.
For regular old database integer rows it's then news__42. For files it's currently files__this/is/the/path/to/the/file.png which is rather stupid anyway 🤣 I can easily change this to some hash.
I'm totally okay with SEAL validating against some regex so that can work everywhere. I would just appreciate if it were some public/static accessible function so I can validate internally too for better DX (fail early with Contao exceptions rather than later on in some SEAL internals the users are not familiar with).

[alexander-schranz]

Thx for the feedback

For files it's currently files__this/is/the/path/to/the/file.png

You may also run into issues with Meilisearch when containing / currently.

I would just appreciate if it were some public/static accessible function so I can validate internally too for better DX

Make sense 👍