Author Topic: Error checking controls on form  (Read 6593 times)

0 Members and 1 Guest are viewing this topic.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: Error checking controls on form
« Reply #15 on: January 09, 2009, 08:16:47 PM »

Just to take the heat out of this .. or redirect it ;

It's my understanding that the databinding of a control enforces the type conformance.

.. and that any other validation ( usually based on business rules) should be done via a specific callback.
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

sinc

  • Guest
Re: Error checking controls on form
« Reply #16 on: January 09, 2009, 08:37:25 PM »
Validation in the business rules can be re-used, regardless of the interface.

Say you initially create a Forms interface to part of your program.  Then later, you also want to add a web interface.  If your validation is in the business objects, it does not have to be redone for the web interface.  However, if you are validating in your interface, you have to make sure every interface does the correct validation.

Of course, this can be colored by other factors.  For example, validation in a web interface may be desirable, because validation in the business objects may require a request be sent to the server.  Meanwhile, validation in the interface can happen immediately, on the client side.

TonyT

  • Guest
Re: Error checking controls on form
« Reply #17 on: January 10, 2009, 01:26:21 PM »
Data binding can only validate the formatting of textual input, it can't
do any other kind of validation.

In the case of binding to properties of objects (as opposed to binding
to fields of a database record, for example), a property's setter must
usually validate the value it is given in any case, regardless of whether
the value is being set by data binding, or by other consumer code.

The point here is that it is counter-productive to couple code that
does validation, to specific controls, namely because there are many
scenarios where one might want to present data in different ways,
like for example, you may want to offer the user a 'form view' or you
may want to offer them a 'tablular' view where the values appear in a
single row of a DataGridView, or you may want to present the values
in a property grid.

If the validation code is placed in handlers of control events on
a form, then how can one easily reuse that code to do the same
validation when the same data is presented in a data grid row, or
in a property grid?

So, that's the problem with Ken's approach.

You can't easily change how you present data, and/or present it in
multiple or different ways, if you couple the validation code directly
to the user interface or to user interface controls.


Just to take the heat out of this .. or redirect it ;

It's my understanding that the databinding of a control enforces the type conformance.

.. and that any other validation ( usually based on business rules) should be done via a specific callback.

« Last Edit: January 10, 2009, 01:34:11 PM by TonyT »

TonyT

  • Guest
Re: Error checking controls on form
« Reply #18 on: January 10, 2009, 01:37:27 PM »
Right. And validation can be done both at the client and at the server.

If for example, a value must be unique, the data set that it must be
tested against for uniqueness may be quite large, and that means
the validation would need to happen on the server, where the data is.

Validation in the business rules can be re-used, regardless of the interface.

Say you initially create a Forms interface to part of your program.  Then later, you also want to add a web interface.  If your validation is in the business objects, it does not have to be redone for the web interface.  However, if you are validating in your interface, you have to make sure every interface does the correct validation.

Of course, this can be colored by other factors.  For example, validation in a web interface may be desirable, because validation in the business objects may require a request be sent to the server.  Meanwhile, validation in the interface can happen immediately, on the client side.

TonyT

  • Guest
Re: Error checking controls on form
« Reply #19 on: January 10, 2009, 08:54:43 PM »

You are right; the ErrorProvider does not do any validation.  It requires you to re-enter validation code for every control in every form you want to validate.  Your data binding method requires basically the same.


Sorry, that's just not the case. :roll:

The data binding method does not require me to write any code to
validate the input text and convert it to the input data type.

That's about it for me.

Ken Alexander

  • Newt
  • Posts: 61
Re: Error checking controls on form
« Reply #20 on: January 12, 2009, 05:57:41 PM »
Let’s get down to the real nuts and bolts here. 

First of all, in both examples, the validation was written in private methods specific to the examples.  I know I did this, and I’m quite certain Tony did to, for readability.  Typically all of this type of validation or logic would be contained as shared methods of a class.  The validation method can be used anywhere, in a single controls event, in a Properties setter, or in a component such as mine that automatically creates the link between the validation method and control event.  So it is safe to say that with either method chosen for validation, the actual validation code is written only once and can be used anywhere.

Second, let’s look at the responsibility of validation.  Let’s say we have two vendors, both are giving us an employee object to work with.  Well Vendor A decided to put logic in the setter of the Employee phone number property to force a string that looks like: “(555) 123-1234” while Vendor B only required the property to be a string.  What vendor am I going to choose?  Before I answer, let’s look at something else.  This same employee object has another property called Experience of type Integer.  Vendor B assumed, that for obvious reasons, no one would hire somebody with zero experience so he decided to put validation in the setter of the Experience property to prevent a value less than one.  Worse yet, an exception is thrown if the value is less than one.  I’m thinking to myself, the property is asking for an Integer, I’m giving it an Integer, why the exception (put that in a 1000 iteration loop and you’ll see what I mean)?  I’m going to choose Vendor B because I want my phone numbers to look like: “555-123-1234” and I might want to hire someone with zero experience.  So it is also safe to say that much of the input validation and formatting will happen at different tiers of an application.

Third, data binding is great for its intended purpose, to link control values to some form of data source.  The framework also gives you the means to do validating between your data and visual controls.  That means you may be required to put more rules on a property than you should.  From what I have read, I didn’t see it in Tony’s example, that the framework also provides you with two events, Format and Parse, which you can use to help with formatting of data bound controls.  Data binding has been around long before you had the ability to bind to a custom object so I doubt the intent of data binding was to perform proper form validation.

Finally, let’s get back to the OP’s original question and quit trying to shoot holes in a method you must not understand.  He’s not asking the best approach in engineering an N-Tier application.  He’s asking what is the best way to error check that a user has populated all controls on a form.  Are you saying that your answer to him would be to look at your data binding example for the answer?
Ken Alexander