Missing Field is Causing JavaScript Exception

[Dustin Martin]

I've got a field that isn't on one of my forms and the JavaScript validation is throwing an exception because it is missing. As soon as I remove the rule from the XML config it works properly. Is this typical behavior? Can I tell ValidateThis to ignore missing fields on the client?

Thanks,

Dustin

[Matt Quackenbush]

It sounds like you're running an older version of VT, as this was fixed a good while back. Can you check your version against the latest on GitHub?

--
You received this message because you are subscribed to the Google Groups "ValidateThis" group.
To view this discussion on the web visit https://groups.google.com/d/msg/validatethis/-/PXAoJS3cNDkJ.
To post to this group, send email to valida...@googlegroups.com.
To unsubscribe from this group, send email to validatethis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis?hl=en.

[Dustin Martin]

I'm using 1.1. That is the latest version, correct? (Note: I was on 0.99 and didn't have this problem.) The following is a JavaScript snippet that is being generated by VT. 

    fm['CashControl'] = $(":input[name='CashControl']", $form_VendorForm);

    fm['CashControl'].rules('add', {

        "maxlength": 6,

        "messages": {

            "maxlength": "The Cash Control must be no more than 6 characters long."

        }

    });

Perhaps I'm wrong, but shouldn't this snippet be checking if the field exists before adding rules to the field?

Dustin

[John Whish]

Can I ask why you aren't using contexts to handle that? To me, you
shouldn't have references to non-existent HTML fields in the generated
JavaScript, although I'm open to persuasion :)

> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/validatethis/-/Sgn_ohmfu38J.

[Dustin Martin]

True, contexts might be a solution to this. But it still seems odd to have the framework throw an exception for a missing field. Here is an example of why this might be a problem.

The user submits a form with fields A, B, and C. On the server, I dynamically generate generate a value that we'll call field D. I still want to validate it but the field isn't on the client side and doesn't need to be. In this scenario, having the client throw and exception is unhelpful. Perhaps having VT log a message to the browser console if a field is missing would be useful. But throwing an exception just breaks my forms. The only solution I see is to remove the validation rule completely or only do server side validation. Neither options seems desirable.

Dustin

[Dustin Martin]

I submitted a pull request on Github that should fix this issue. Check it out and let me know what you think: 

https://github.com/ValidateThis/ValidateThis/pull/75/files 

[John Whish]

Thanks for the pull request Dustin. I was just writing the same patch :)
I think I may have been over zealous in my optimisation of the
JavaScript that caused this so I apologise - I always use contexts for
this, but I can see from your use case that that's not always
appropriate.

Can I request that you use .length instead of size() as there is a
slight performance improvement.

Also, do people think that a client side field should be ignored by
the client side validation if missing _and_ required?

> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/validatethis/-/orklz9UnJVkJ.

[Matt Quackenbush]

John,

No, in my opinion if it is required, it should be required. VT's responsibility is to administer the application according to the rules it is given, not to reach into the view and determine whether or not it finds a match.

Regardless of whether it should be required and present in the form, or not required and absent in the form, it is a bug that the programmer has written into his/her application and needs to fix. By silently assuming that if it's missing from the form its required status should be ignored, VT would be aiding the programmer's sloppy coding habits. Throw the exception and let the programmer decide how to fix it. :-)

[John Whish]

Thanks Matt,

That's what I think as well. Glad you agree :)

- John

[Dustin Martin]

John, I'll change my patch to use .length instead. Thanks for the tip.

As far as how to handle required fields, if I revise my earlier example I think you can see there may still be a need to ignore required fields if they are missing. So, fields A, B, and C are on the form. Another field D, comes in after the form is submitted. D is also required by the BO. Perhaps it is pulled from another system somewhere or dynamically generated. Where or not the field is on the form, it is still required. While D may not be user entered, it may come from a system where the data is not always reliable and needs to be validated. Server side validation will alert the user/programmer if the field is missing on the BO but throwing and exception on the client seems premature. If nothing else, providing a flag to the programmer to ignore missing client side fields seems like a good option.

Dustin

[Bob Silverberg]

There is actually an open ticket for an enhancement to allow a
developer to specify whether a rule applies to just the client, just
the server, or both:
https://github.com/ValidateThis/ValidateThis/issues/39

It sounds like that might be the answer to this scenario, and maybe
the others requiring this as well.

From my perspective, if we want to make VT handle client-side
"problems" gracefully by ignoring form fields that it expects but do
not exist (which I think is a reasonable idea), then I think it should
always ignore those, regardless of whether the field is required or
not. This is no longer about enforcing validation rules, but rather
about how to handle exceptions. A missing form field that should
actually be there is a pretty major exception which I would hope would
be caught by some mechanism other than VT. VT's job isn't to make sure
developers don't make mistakes - it's to enforce the rules that a
developer tells it to, to the best of its ability. If it cannot
enforce a rule because a form field doesn't exist then I think it
makes perfect sense for it to ignore that rule altogether.

That's my take on this anyway.

Bob

> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/validatethis/-/WiL0nayViGAJ.

>
> To post to this group, send email to valida...@googlegroups.com.
> To unsubscribe from this group, send email to
> validatethis...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/validatethis?hl=en.

--
Bob Silverberg
www.silverwareconsulting.com

[Bob Silverberg]

So, what does everyone think of what I had to say about this?

1. Will adding the feature described in
https://github.com/ValidateThis/ValidateThis/issues/39 actually
address the use cases that have been brought up? Would this mean that
we don't need to have the framework check for the existence of form
fields before accessing them?

2. If we still feel that the framework should check for the existence
of form fields before accessing them, are we happy to put that check
in place using .length()?
2b. Do people agree that if that check is in place it should always
be done, regardless of what the rule is (i.e., it doesn't matter if
the rule is a required rule)?

I will try to take a stab at adding the feature this week to address item #1.

Thanks,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[Dustin Martin]

While that feature may be useful it still seems "wrong" for the framework to throw an exception for a missing form field. I'd still rather have it validate what it can and leave the rest up to me. There may be many valid reasons for leaving a field off a form and it could be left off sometimes or all the time in which case the new feature wouldn't help. Yes, contexts might work but having VT ignore missing fields is a much simpler/cleaner solution it seems. If nothing else, it seems that VT should validate everything it can on a form, regardless of what might be missing. It isn't the frameworks job to tell the developer a field is missing. It's to validate data.

Perhaps if others do want VT to throw an exception in this case a config flag called ignoreMissingClientFields or something can be added to the VT config. Or a message could be logged to the browser console notifying the programmer of the missing field.

> > > To post to this group, send email to valida...@googlegroups.com (mailto:valida...@googlegroups.com).

> > > To unsubscribe from this group, send email to

> > > validatethis...@googlegroups.com (mailto:validatethis...@googlegroups.com).

> > > For more options, visit this group at
> > > http://groups.google.com/group/validatethis?hl=en.
> >
> >
> >
> >
> >
> > --
> > Bob Silverberg

> > www.silverwareconsulting.com (http://www.silverwareconsulting.com)
>
>
>
>
>
> --
> Bob Silverberg
> www.silverwareconsulting.com (http://www.silverwareconsulting.com)

>
> --
> You received this message because you are subscribed to the Google Groups "ValidateThis" group.

> To post to this group, send email to valida...@googlegroups.com (mailto:valida...@googlegroups.com).
> To unsubscribe from this group, send email to validatethis...@googlegroups.com (mailto:validatethis...@googlegroups.com).

[Matt Quackenbush]

I wholeheartedly agree with you that VT's job is to validate data. Where I disagree is that I believe VT should validate _according to the rules it has been provided_. This means that if it has a rule and a missing field/property/value, VT returns an invalid result. It should never simply ignore rules it has been provided and is tasked to enforce.

The fact that VT already supports "ignoring missing fields" via the use of contexts is, in my opinion, quite sufficient. That said, I suppose I'm not totally opposed to some sort of `ignoreMissingClientFields` flag as you've suggested, provided that it defaults to false (keeping the current behavior as the default). Although I'm not really a big fan of adding in a bunch of configuration options for edge cases, I realize that sometimes it's a necessary evil.

HTH

To post to this group, send email to valida...@googlegroups.com.
To unsubscribe from this group, send email to validatethis...@googlegroups.com.

[Dustin Martin]

But, in the case of a missing field, VT doesn't really validate it. It simply throws an exception and that exception is a framework error and not a validation of some data.

Plus, the exception halts further validation of the form which is totally inconsistent with every other validation that VT does. If a missing field was treated like all other field validations and a message was displayed saying, "The [field name] is required but is missing on the form" and then continued validating the form, it would be more consistent with the rest of the framework.

Since this is new behavior it took me quite a while to figure out why the exception was being thrown. As discussed earlier, 0.99 didn't behave like this. John even said that he may have been "overzealous" in optimizing the Javascript which says to me that the current behavior wasn't on purpose or expected. And if VT was behaving in a particular way for the last several versions and was inadvertently changed, do we want everyone using VT to be forced to change the way they use the framework because of an accidental change?

I completely agree that VT should validate "according to the rules it has been provided". It's just a matter of who to trust more: the programmer or the framework? Do we give the programmer the flexibility to use VT in multiple ways and trust that they have a good reason for leaving a field off a form? Or do we force the programmer to use the framework in only one way and throw an exception in an effort to prevent "sloppy coding habits".

At the very least I think a configuration option needs to be added so the original behavior can be restored.

Dustin

On Tuesday, January 31, 2012 at 7:13 PM, Matt Quackenbush wrote:

> I wholeheartedly agree with you that VT's job is to validate data. Where I disagree is that I believe VT should validate _according to the rules it has been provided_. This means that if it has a rule and a missing field/property/value, VT returns an invalid result. It should never simply ignore rules it has been provided and is tasked to enforce.
>
> The fact that VT already supports "ignoring missing fields" via the use of contexts is, in my opinion, quite sufficient. That said, I suppose I'm not totally opposed to some sort of `ignoreMissingClientFields` flag as you've suggested, provided that it defaults to false (keeping the current behavior as the default). Although I'm not really a big fan of adding in a bunch of configuration options for edge cases, I realize that sometimes it's a necessary evil.
>
> HTH
>

> > > > > To post to this group, send email to valida...@googlegroups.com (mailto:valida...@googlegroups.com) (mailto:valida...@googlegroups.com).

> > > > > To unsubscribe from this group, send email to

> > > > > validatethis...@googlegroups.com (mailto:validatethis%2Bunsu...@googlegroups.com) (mailto:validatethis...@googlegroups.com (mailto:validatethis%2Bunsu...@googlegroups.com)).

> > > > > For more options, visit this group at
> > > > > http://groups.google.com/group/validatethis?hl=en.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Bob Silverberg

> > > > www.silverwareconsulting.com (http://www.silverwareconsulting.com) (http://www.silverwareconsulting.com)
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Bob Silverberg
> > > www.silverwareconsulting.com (http://www.silverwareconsulting.com) (http://www.silverwareconsulting.com)

> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "ValidateThis" group.

> > > To post to this group, send email to valida...@googlegroups.com (mailto:valida...@googlegroups.com) (mailto:valida...@googlegroups.com).
> > > To unsubscribe from this group, send email to validatethis...@googlegroups.com (mailto:validatethis%2Bunsu...@googlegroups.com) (mailto:validatethis...@googlegroups.com (mailto:validatethis%2Bunsu...@googlegroups.com)).

> > > For more options, visit this group at http://groups.google.com/group/validatethis?hl=en.
> >
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "ValidateThis" group.

> > To post to this group, send email to valida...@googlegroups.com (mailto:valida...@googlegroups.com).

> > To unsubscribe from this group, send email to validatethis...@googlegroups.com (mailto:validatethis%2Bunsu...@googlegroups.com).

> > For more options, visit this group at http://groups.google.com/group/validatethis?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups "ValidateThis" group.

[Bob Silverberg]

Thanks for your feedback, Matt, but I have to agree with Dustin here
(as may be obvious from my earlier remarks). Generating a Javascript
error, which may be very difficult to debug and may not even be
noticed by a developer just doesn't make sense.

I think there is just a fundamental difference between what VT can and
should do on the server vs the client. It doesn't really have control
on the client. It just generates JS that then has to be executed on
the client, whereas on the server it is in total control and can add
exception information to the result object. I think, if possible, VT
needs to always generate valid JS that will execute without error, and
it sounds like it was doing that before. So really this is a bug that
needs to be fixed.

John is the go to person for client-side code now, so if he's happy
with the length() solution then I think we need to add that back in.

Bob

> To post to this group, send email to valida...@googlegroups.com.
> To unsubscribe from this group, send email to validatethis...@googlegroups.com.

[Matt Quackenbush]

Dustin,

I think I must be missing something. I agree that an exception should not be thrown; I was only understanding that the validations were failing. If there is an exception - as in, KABOOOM!!!!! - then I think that's a bug in VT. :-)

HTH?

[Dustin Martin]

Oh yeah, big Javascript exception and a KABOOM!!! :-)

Dustin

[Bob Silverberg]

OK, I have merged Dustin's pull request, and I have also implemented
the processOn behaviour, both of which are in the develop branch on
GitHub. They will both be included in the next release.

In case anyone is interested, you can now specify an attribute of
"processOn" in your rule metadata. A value of "client" will have the
rule only enforced on the client, a value of "server" will have the
rule enforced only on the server, and any other value will have the
rule enforced on both the client and the server.

Let me know if anyone has any questions about this,
Bob

> To post to this group, send email to valida...@googlegroups.com.
> To unsubscribe from this group, send email to validatethis...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/validatethis?hl=en.
>

--
Bob Silverberg
www.silverwareconsulting.com

[Dustin Martin]

Sounds great. Thanks for taking care of this.

On Tuesday, January 31, 2012 at 10:56 PM, Bob Silverberg wrote:

> OK, I have merged Dustin's pull request, and I have also implemented
> the processOn behaviour, both of which are in the develop branch on
> GitHub. They will both be included in the next release.
>
> In case anyone is interested, you can now specify an attribute of
> "processOn" in your rule metadata. A value of "client" will have the
> rule only enforced on the client, a value of "server" will have the
> rule enforced only on the server, and any other value will have the
> rule enforced on both the client and the server.
>
> Let me know if anyone has any questions about this,
> Bob
>

> Bob Silverberg
> www.silverwareconsulting.com (http://www.silverwareconsulting.com)
>

[John Whish]

Man, I miss out on all the conversations don't I because you guys have
weird time zones!!

I personally like my JavaScript to only reference fields on my form,
but I'm completely happy that this might just be me and others would
rather it silently ignored it :)

> To post to this group, send email to valida...@googlegroups.com.
> To unsubscribe from this group, send email to validatethis...@googlegroups.com.

[Bob Silverberg]

Sorry, John. I was developing and got overzealous. I'm not sure what
you mean by:

>
> I personally like my JavaScript to only reference fields on my form,
> but I'm completely happy that this might just be me and others would
> rather it silently ignored it :)
>

Are you agreeing with the approach Dustin wrote or not? Are you saying
that you would want the JS that VT generates to attempt to use form
fields that may not exist on a form?

Cheers,
Bob

--
Bob Silverberg
www.silverwareconsulting.com

[John Whish]

Hi Bob,

Sorry for the confusion. I'm happy with the changes that Dustin has
made (thanks Dustin!)

- John