EStudio End User Form - Text Field - Validation Regex

This should be simple, but there are absolutely no technical documents for EStudio, so nothing is simple with EStudio development. I have opened a support ticket, but even the support folks don't seem to know much about EStudio under the hood. What I am trying to do is solve this simple requirement: The input text field should not allow an entry less than 4 characters in length.

My validation regex looks like this: [0-9a-zA-Z]){4,}

I've tried some other variations, such as this and similar: ^([0-9a-zA-Z]){4,}$

No luck. It just happily allows an entry of: 123 or 1 or nothing entered at all. And if I modify the regex to be "[0-9a-zA-Z]){4,6}" and enter something much longer than 6 chars, it still allows it. So clearly this syntax is not registering with this field. I am wondering if anyone has had any luck with validation regex in EStudio with a similar requirement with success and what syntax was used. Or some other regex for something else with an obviously different syntax may be helpful as well. With no tech docs as a guide, and no experts at OpenText seemingly available, I am really at a loss here.

TS 16.4.1 on Linux

Comments

  • David Smith
    edited January 23, 2020 #2

    Update....

    I did a quick test in Forms Publisher on a simple text field with the same regex:

    <text validation-regex="^[0-9a-zA-Z]{4,}$"/>

    and it works perfectly. I adjusted the string in my Validation Regex for the EStudio End User Form Text field to be: ^[0-9a-zA-Z]{4,}$

    and still it does nothing. So this is definitely a bug. It should be coded the same for both. There's no reason/excuse for them to code these things differently. And if they are coded the same, then their QA did not test it - big shocker there. We've been their QA for most of the Search functionality, so why not EStudio as well.

  • You probably won't like hearing that this is fixed in 16.6.1

    Just tested and it fails for 123 but works for 1234, 12345, etc.

  • David Smith
    edited January 27, 2020 #4

    Jerk.

    I had them file a bug for 16.4.1. They better give me a patch. Piece of junk. How do you not QA this field that is called Validation Regex for actual regexes????? There's no way we will upgrade just for this. We have upgraded enough this past year and a half for 5 companies.

  • And it also worked in 16.4.0, I do not have a 16.4.1 instance readily available.

  • I confirmed with Andy that he was looking at DCT forms and not Assets->Forma (End User Forms) as I was trying to create. These are 2 completely different animals. While DCT form fields are working fine for Validation Regex, the End User Form fields are not.

  • One of my coworkers discovered there is a Form Settings tab, and under its Advanced Settings, there is a checkbox labeled Form Validation, which is defaulted to unchecked. The help text for this checkbox says to check the box if you want the form to be validated upon Submit. Once I checked this box, the regex started to work.

    While it was nice thatthis made my Validation Regex work, it also brought up some other questions for me about the design of this "advanced feature":

    1. What is its purpose? Why would anyone who entered data in a validation field NOT want the data to be validated?
    2. Why in the world is this checkbox not defaulted to checked? Would a user not assume that when they entered validation for their fields that the validation would be executed?
    3. I would expect that if I did not enter any validation, then sure, don't do validation. And hence, what is the purpose of this checkbox?????
  • I received the answers to the above questions from OpenText Engineering as follows:

    I understand the pain customer is going through. However, would like to confirm that this was neither a miss nor should it be compared directly with DCT just because the Designer UI looks similar. DCT is an "authoring side" functionality and does not allow attaching Javascripts for validation. Whereas, End User Forms are placed on a page and can include validation either by using the support that we provide OOTB or by writing validations in external resources (such as JS) and including them on the page. Hence, additional configurability is required - to suggest which one to use!
    This is definitely not a miss but was designed this way primarily to be able to switch on/off validation at the form level without having to manually do so for each field. Imagine a form with 15+ fields and you would want to turn on/off the validations. Without this configuration, you will have to disable the validation flag for every single field/remove the regex. But if there is a form level uber setting, you can let the field level validations still remain configured but enable / disable the overall validation functionality alone by turning on/off the form level flag. Similar paradigm is followed for asset level vs. site level Experience Insights configuration. Agree DCT works differently - because it is a legacy functionality and its use case does not demand for it...but when we added End User Forms, we tried bringing in a more contemporary design that's more suitable for its use case!
    Since it was intentionally built that way (to give better control for the form designer) and not a miss, the tooltip does suggest that the field level validation will trigger only when form level validation is turned on

    With regards to the response from Engineering, I think it makes little sense. If the developer wanted to use external validation rather than the authoring validation for any field, or all fields, the developer would simply not code a validation on the authoring side for the field(s). It's rather silly to have the checkbox. Regardless, since it's there, it should most certainly be defaulted to CHECKED so that if the developer chooses to use the TeamSIte validation, it is then defaulted to being used. That just makes common sense. This is TeamSite and the default should be to use the provided interface - you can't assume that the developer would rather use the external validation when there is a field provided that is built-in.

    The owner of the support ticket promptly closed the ticket upon my response, without asking me. Wonderful customer service on this one.

TeamSite Developer Resources

  • Docker Automation

  • LiveSite Content Services (LSCS) REST API

  • Single Page Application (SPA) Modules

  • TeamSite Add-ons

If you are interested in gaining full access to the content, you can register for a My Support account here.
image
OpenText CE Products
TeamSite
APIs