iets3.opensource
iets3.opensource copied to clipboard
`extensionPoint/IdentifierConfigurator` should be used by `MessageDefiniton` concept
A customer wants to use MessageDefinition
with german umlauts.
Therefore MessageDefiniton
should use extensionPoint/IdentifierConfigurator/
that allows the user to decide if german umlauts and paragraphs are allowed by defining (aka implementing) such an extensionPoint.
On a side note: I really question the way we handle special characters in IValidNamedConcept
. The current handling is awful. We already have an extension point. Why not have a method where you can provide special characters that are allowed? The method should also map the character to an identifier e.g. ö to oe.
That would be much clearer and nicer i fully agree. Do you see a way to stay backward compatible (the methods allowUmlaute
and allowParagraph
would become obsolete, won't they)?
Yes, they would become obsolete but we can still use the information. You could read the return type of the existing two methods and add the corresponding character mappings to the map if they do not exist already. For the constraint of IValidNamedConcept
, you can then maybe also use the mappings instead of the hardcoded characters. For more complicated cases it might be necessary to just have the ability to overwrite the full regex of the constraint.
Okay, I think we should go ahead here first and create a new ticket for that approach.
Reasons:
- Nobody asked for more flexibility (maybe everyone silently accepted the situation so far).
- We need tests to ensure the backward compatibility.
- We will not forget that much more flexible approach and can work on it if there is a need for it.
Do you agree?