Clearing a web interface field does not trigger revalidation

[tom....@mycit.ie]

I have a field on a form which validates as follows:
1. it may be empty
2. but if not empty, it should not have the same value as another field

I've used this Javascript to try to implement it:
("[[preferred_first_name]]" == "undefined") ||
(("[[preferred_first_name]]" != "undefined") && ("[[preferred_first_name]]".toUpperCase() != "[[last_name]]".toUpperCase() ))

and also:
!(id_preferred_first_name.getValue()) ||
(id_preferred_first_name.getValue() && ("[[preferred_first_name]]".toUpperCase() != "[[last_name]]".toUpperCase() ))

This works up to a point: if I enter a value in preferred_first_name that's the same as last_name, the validation message appears as expected, but if I then CLEAR the preferred_first_name field, the message remains visible, and the form may not be submitted.

So clearing a value fails to trigger a validation refresh.

1. why would clearing a value NOT trigger a revalidation?
2. what are my options here?

[Gareth Thiveux]

Hi Tom,

You've guessed right. Emptying a field doesn't trigger any event, so is not detected by the validation rule.

In this case, the only solution I can offer you is to use a "manual" listener, which will be able to detect when fields are emptied.

So create an hidden JS widget at the bottom of you form, and put this script inside it :

function valueChanged_name( name, value ) {

if(name == "preferred_first_name" || name == "last_name") {

if((RMPApplication.get("preferred_first_name") == "") || (RMPApplication.get("last_name") == "") || ((RMPApplication.get("preferred_first_name") != "") && (RMPApplication.get("preferred_first_name").toUpperCase() != RMPApplication.get("last_name").toUpperCase()))){

RMPApplication.set("name_validation","OK");

} else {

RMPApplication.set("name_validation","NOK");

}

}

}

RMPApplication.addListener( valueChanged_name );

And in the validation rule of your preferred_first_name, replace the script you had by :

"[[name_validation]]" == "OK"

Just to give a little explanation, when you use the RMPApplication.addListener function, you're creating what we could call a manuel listener, that listens to anything that changes in your form, and each something changes, calls the function given as a parameter, valueChanged_name in this case.

And it's in this function that you'll filter on which variables you want to perform an action. In this case, you want to react if the variable preferred_first_name or last_name changes. You just add below the condition you want to check, and do whatever action you want (could be an alert, or set a field as visible or active ...), but we've got no way of forcing as invalid, which we would like to do in this case (id_widget.setValid(true/false) doesn't exist). So what we'll do to bypass this, is to set a randomly chosen variable (name_validation here) as "OK" or "NOK" for example, and use this variable value in the validation rule of your preferred_first_name field as described above.

That should hopefully solve your problem.

Hope I was clear enough.

Regards,

Gareth THIVEUX   

Consultant Avant-Vente / Pre-Sales Consultant

 Fujitsu RunMyProcess

22 rue Chauchat, 75009 Paris - France (GMT+1)

website : Fujitsu RunMyProcess      

Fujitsu RunMyProcess user? Please add a review on GoogleApps Marketplace

Afin de contribuer au respect de l'environnement, merci de n'imprimer ce message qu'en cas de nécessité.
Be environmentally friendly: do not print this email unless it is entirely necessary.

2013/7/18 <tom....@mycit.ie>

--
Fujitsu - RunMyProcess
---
You received this message because you are subscribed to the Google Groups "RunMyProcess Support Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to supportforum...@runmyprocess.com.
To post to this group, send email to suppor...@runmyprocess.com.
Visit this group at http://groups.google.com/a/runmyprocess.com/group/supportforum/.
For more options, visit https://groups.google.com/a/runmyprocess.com/groups/opt_out.

[tom....@mycit.ie]

Thanks Gareth, I appreciate the detailed response. The manual listener seems to get a step closer to a solution - it fires when a variable is cleared, the name_validation variable is assigned the correct value, but the validation error message remains visible, and the form cannot be submitted.

[Gareth Thiveux]

Hi Tom,

If you try adding an hidden/inactive text input field with variable name_validation with "OK" as default value, is it any better ?

Regards,

Gareth THIVEUX   

Consultant Avant-Vente / Pre-Sales Consultant

 Fujitsu RunMyProcess

22 rue Chauchat, 75009 Paris - France (GMT+1)

website : Fujitsu RunMyProcess      

Fujitsu RunMyProcess user? Please add a review on GoogleApps Marketplace

Afin de contribuer au respect de l'environnement, merci de n'imprimer ce message qu'en cas de nécessité.
Be environmentally friendly: do not print this email unless it is entirely necessary.

2013/7/18 <tom....@mycit.ie>

Thanks Gareth, I appreciate the detailed response. The manual listener seems to get a step closer to a solution - it fires when a variable is cleared, the name_validation variable is assigned the correct value, but the validation error message remains visible, and the form cannot be submitted.

[tom....@mycit.ie]

No, that doesn't change anything.

[Gareth Thiveux]

Tom,

What is the case that you would like to be valid and is not ? Last name specified and Preferred first name empty ?

Can you maybe attach a screenshot that would illustrate it ?

Regards,

Gareth THIVEUX   

Consultant Avant-Vente / Pre-Sales Consultant

 Fujitsu RunMyProcess

22 rue Chauchat, 75009 Paris - France (GMT+1)

website : Fujitsu RunMyProcess      

Fujitsu RunMyProcess user? Please add a review on GoogleApps Marketplace

Afin de contribuer au respect de l'environnement, merci de n'imprimer ce message qu'en cas de nécessité.
Be environmentally friendly: do not print this email unless it is entirely necessary.

2013/7/18 <tom....@mycit.ie>

No, that doesn't change anything.

[tom....@mycit.ie]

Gareth, I feel myself slipping down a rabbit hole. The general use case is simple: a field may be empty, or if it has a value, it should satisfy a condition. From a user's perspective, the simplest way of correcting the entry of an invalid value is to delete it, thereby making the value empty but valid.

The specific case I'm looking at is when users wrongly enter their last name as their preferred FIRST name (this has happened surprisingly often). The obvious solution for them (once warned) is to delete it. But the system has to support re-validation on variable clearance to implement this, which it does not (easily, or at all).

I'm going to fix this server-side by wiping preferred first names that are equal to last names there instead.

Could I log a feature request: that the client Javascript library should implement sensitivity to variable clearance for dependent validation rules, activity rules, visibility rules and listening JS widgets. It is not logical to consider clearance of a variable as anything other than a material change to its value, one which should have an automatic impact on all dependent validation rules, activity rules, visibility rules, and listening Javascript widgets.

[Gareth Thiveux]

Tom,

I do perfectly understand your concern. This feature has already been logged with our R&D team.

What I can't understand is that the workaround with the manual listener works fine for me. That's why I was asking for some details as I thought I was maybe missing something.

This is what I've tried :

I fill in preferred_first_name with "test"

Then I fill in last_name with "test" => Invalid value red message appears next to preferred_first_name field

Finally I empty preferred_first_name (or last_name or both)  => message disappears, and I'm able to submit

Regards,

Gareth THIVEUX   

Consultant Avant-Vente / Pre-Sales Consultant

 Fujitsu RunMyProcess

22 rue Chauchat, 75009 Paris - France (GMT+1)

website : Fujitsu RunMyProcess      

Fujitsu RunMyProcess user? Please add a review on GoogleApps Marketplace

Afin de contribuer au respect de l'environnement, merci de n'imprimer ce message qu'en cas de nécessité.
Be environmentally friendly: do not print this email unless it is entirely necessary.

2013/7/18 <tom....@mycit.ie>

Gareth, I feel myself slipping down a rabbit hole. The general use case is simple: a field may be empty, or if it has a value, it should satisfy a condition. From a user's perspective, the simplest way of correcting the entry of an invalid value is to delete it, thereby making the value empty but valid.