Email Validation No Longer Working

I had an email validation up and working on the client side, and it has recently just stopped working even though I have not changed the code in that part of my app for ages.

The structure of the code is described below - it is slightly unconventional, but it certainly used to work.

Is this a bug that came into Wappler in a recent release?

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
I have a repeat children:

<div id="rg_attendees" is="dmx-repeat" key="attendee" dmx-bind:repeat="attendees.data" class="">

Inside that I have a hidden form:

<form id="get_contact_activity" method="post" is="dmx-serverconnect-form" action="dmxConnect/api/form/form_get_contact_activity.php"
            dmx-on:success="flow_start_booking.run({})">
            <input id="h_contact_email" name="email" class="form-control" dmx-bind:value="i_contact_email.value" type="hidden" required="">
            <input id="h_contact_attendee_number" name="attendee_number" class="form-control" dmx-bind:value="$id?$id:1" type="hidden">
            <input id="h_contact_attendee_count" name="attendee_count" class="form-control" dmx-bind:value="attendees.data.count()" type="hidden">
            <input id="h_contact_in_test_mode" name="in_test_mode" class="form-control" dmx-bind:value="in_test_mode.value" type="hidden">
</form>

And the Email field and submit buttons are outside of the form (but inside the repeat)

<input type="text" class="form-control input_form" id="i_contact_email" name="email" aria-describedby="input1_help" placeholder="" dmx-bind:disabled="(show_contact_details == 1)" style=""
                        data-msg-email="Please enter a valid email address" data-rule-email="" dmx-bind:value="email">
                    </div>
<button id="b_start_booking" class="btn btn-success" dmx-on:click="this_attendee_number.setValue($id);get_contact_activity.submit();scroll.goto('#a_contact_details_'+$id)"
                        dmx-show="(show_booking_details==0) && (form_mode.value=='event')" dmx-on:keydown.enter="this_attendee_number.setValue($id);get_contact_activity.submit();scroll.goto('#a_contact_details_'+$id)"
                        dmx-bind:disabled="(i_contact_email.invalid) || (i_contact_email.value.length()==0)">Start
                        <span dmx-show="browser.viewport.width>576">Booking</span></button>

I can PM a link for you to test it with if that will help! :slight_smile:

This will no longer work as first validation of a field happens only on form submission now. I think this was done in the previous release. Earlier it used to validate on input. This new behaviour is in line with Bootstrap.
Once a form is submitted, and there are validation issues, then all fields get validated on input.

Now, you need to validate the input manually on click of button since its outside the form.
You can make use of FLOW for this. Here’s what you can try inside the flow:

  1. RUN => i_contact_email.validate()
  2. WAIT => 50ms (might not be required, please test)
  3. CONDITON => i_contact_email.invalid
  4. THEN/ELSE …

Thanks for that update @sid… I always really appreciate the detail and clarity of your posts! :slight_smile:

@George, is what @sid posted your view of the situation?

If so, then Wappler introduced a breaking change into the codebase…

and I would really appreciate the release notes each week including a big
:warning: BREAKING CHANGE! :warning:
note against anything of this nature so we can all be very clear this has happened and check our code to see if our app will develop a bug based on upgrading.

Do you have this problem anymore? I was not sure what I did wrong because suddenly my email validation didn’t work. Had to add dynamic event to validate it on data update.

Officially when the validator was released it did validate when the form is committed and then on each change. Then at some time an update broke this behavior and it validated with each change in an input. This was fixed again just recently, but it seems that several users now expect the behavior of validating on change which was actually not intended.

Normally we mention a big change, but in this case it was just a bugfix and we didn’t expect that there were users that expected the buggy behavior to be the default behavior. We should perhaps have been expecting this, since the bug was already a long time in it.

Thanks for the feedback @patrick!

Yes, when a bug stops a clearly expected feature from working then it feels like a bug fix.

When the bug takes an ability away then it feels like a breaking change.

I find the topic of validation quite complex to understand. @patrick, what is the best complete and thorough documentation to read about how it is meant to work?

I’ve not found anything which explains it from all angles so I’ve just built my app based on what actually happens!