Differentiate decoded EntityAttributes from other sorts
Basics
Logistics
Basics
Logistics
Description
This is probably not worth it, and may just be a dumb idea outright, but the naming conventions we apply for IdPAttribute are sometimes in conflict with the auto-generated names that get assigned when decoding EntityAttribute tags since we allow those to just auto-decode in some cases into unwieldy names.
The hyphen was the obvious case since many URLs contain them.
We could do this with separate constructors, I’m just not sure there’s enough value to bother.
Environment
None
Activity
Scott Cantor July 22, 2024 at 12:41 PM
No, my dumb ideas was to have separate constructors for IdPAttribute, one that enforced the naming rules and one that didn’t. We would call the latter to bypass rules like hyphens but the rest of the code base would use the original.
I think it’s probably a bad idea.
Rod Widdowson July 20, 2024 at 10:45 AM
So, the need here is a “Construct attribute with name normalization” idp generator, then entity attributes would get safe names?
Observations
If that is the case then this is a change of behavior which might affect upgrades? e might want to start with a warning (maybe we do so already)
If this is what is needed (and I need to review the code because we might do so already), do we want to police the names when a “normal” attribute is created (via attribute-resolver.xml).
This is probably not worth it, and may just be a dumb idea outright, but the naming conventions we apply for IdPAttribute are sometimes in conflict with the auto-generated names that get assigned when decoding EntityAttribute tags since we allow those to just auto-decode in some cases into unwieldy names.
The hyphen was the obvious case since many URLs contain them.
We could do this with separate constructors, I’m just not sure there’s enough value to bother.