...
# | Questions/Open Issues | Notes | Decisions | ||||
---|---|---|---|---|---|---|---|
1 | What kind of naming validation should be in place? |
Alternate approach, exclude characters:
PLease not we do allow (include)
| |||||
2 | Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict. | As part of this commit, we can modify the code so anchor creation will happen for the cm handle registration. So if it fails the validation at this point, the CM-Handle will not be registered. | cm handle CM-Handle will follow same rules. shen to validate is impl. detailed | ||||
3 | Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? | Not recommended as this will add little value, at a high cost | prefer Prefer to validate query/get input | ||||
4 | Should dashes be included? | A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these. | Yes, see above | ||||
5 | Implementation approach for validation | We have discussed 3 possible libraries for implementing this validation. These include java's util library, spring validator at the service level of CPS, along with using open api's 'keyword' for dealing with CM-Handle ID validation, or using apache commons validation regex library. | Have decided to use basic java util package. | ||||
6 | The validation logic with the regex should be implemented in a separate utility class. | A new common utility class should be created specifically for regex validation as part of this user story. | Have decided to not use to use a separate class for this right now |
Implementation Proposals
At CPS's service layer within the the Java API:
...
# | Implementation Approach | Pros | Cons |
---|---|---|---|
1 | Java Util Package |
|
|
2 | Spring/OpenApi keyword |
|
|
3 | Apache Commons Validator |
|
|
...