Hello Please could you let me know if anyone has tried to validate attributes in Smart UI, like attribute type, attribute length and other conditions?
yes, but it does require enhancements to the SmartUI widgets to support that (even if just adding some JS to the fields). Your other post (https://forums.opentext.com/forums/developer/discussion/308450/validation-of-input-fields-in-content-server#latest) is on the server side so would also cover the Classic UI and APIs such as REST and CWS too.
yes, its easy and requires only the usage of REST forms and basic javascript (with a little css, if you want) at your own forms or the usage of map to override the alpaca "forms" package in smartui with your custom written forms smartui package
@Reiner Merz agree it can be done, for Validation I usually recommend doing it in the OScript level so that the logic is applied to all access types - Classic UI, SmartUI, REST, CWS, WebReports etc rather than just the SmartUI.
@Greg Griffiths in smartUI, you can get all the infos using the categories form REST API.
So you can validate the entries directly after entering data, which allows you to use the html5 forms features, which are nice.
The todo is:
either override the smartUI Forms package with your own (clone it, add the validation, map the result over the smartUI forms module)
or provide your own mechanism to add category values (p.ex by adding your own categories panel on the "+" extension point). But this requires the knowledge of js and extension points in smartUI.
(or use standard document type form with required attributes. )
(There is an example in the smartUI sdk. This is open for customizing)
If you are adding documents from smartUI :
Doing the validation on the server side does require some js magic informing the client that something went wrong. Can be done via fetch (xmlhttp) closures, but this requires a lot of js skill to deal all scope issues. IMO a client sided validation is easier, but this is only my opinion.
@Reiner Merz agree that covers the SmartUI aspect, my statement was if the user also uses other interfaces such as Classic UI, WebServices, direct REST etc then a rule only delivered in SmartUI would not trigger in those cases. If the client is SmartUI only then you solution, as usual, is a great one.
