[boost] GUI validation [was: GUI Library Proposal for a Proposal]

From: Mathew Robertson (mathew.robertson_at_[hidden])
Date: 2004-11-18 03:06:58

> > Not really, there are two reasons why validation code is not necessary.
> > 
> > 1. User validation always needs to be done by your business/process rules.
> >    -> When the 'go' event is generated, your app should validate the application variables (some of which will be connected to widgets).  The validation will need to reset any variables which are in an out-of-bound condition (this implies that the GUI will need to re-synchronize to the new state of the variables).  I wont comment on whether it is good to intertwine business logic within GUI update code....
> > 
> > 2. Some widgets dont need validation eg: spinner, combobox, slider...  These almost never need validation, since they are only ever populated with valid values.
> > 
> 
> I'm talking about your business logic.
> Why shouldn't a combo-box / slider not have validation?
>
> And as a side-note, combo-boxes can be "drop-down" as well. In which 

What other combo-box is there which doesn't drop down?

> case, you can :
> - select from existing values
> - enter a new value yourself
>
> (which could require validation).

Combo-boxes shouldn't be populated with something which wont produce a valid business rule.  Editable combo-boxes are more rare -> usually they allow you "select an entry by typing the first few characters".  Truely editable combo-boxes are just about always used in the wrong context -> usually the interface needs the use of an editline with history-popup.

Sliders should always only allow you to select valid values.  I'm not sure why you would have a slider which would allow you to select invalid business rules...

> And as for validation, take an employee's data:
> 
> 
> struct employee {
>      std::string first_name;
>      std::string last_name;
>      int id;
>      unsigned long salary;
> 
>      time_t birth_date;
> 
>      std::string country;
>      std::string address;
>      std::string email;
> 
>      bool has_homepage;
>      std::string homepage;
> };
> 
> Here are possible validations:
> - First and last names should not be less than 4 chars

This is a feature of the editline -> no validation is necessary

> - ID should be within 10000 and 20000 range

A slider with the lower value set to 10000 and the upper value to 20000

> - salary should not be bigger than 150,000

An numeric editline has the feature of having a bounded upper limit.

> - birth_date should not be bigger than 1980

You should be using a "calendar widget", I'm not sure what you mean by 'bigger' in the context of dates...

> - email address should be valid

Define 'valid' for an email address.  Should it contain an @ symbol?  If so, then use an Email-Editline widget, dont use a generic text editline widget.

> - homepage should be valid.

Same response as email address question.

> How do you handle those (and lets not remember user-friendlyness)?

I think you ment to say "lets not forget user-friendlyness"...  In each case I have provided a reasonable example where no validation was necessary by the application programmer.  All of which provide a reasonable good HCI, far better than simple editlines.

> And just for fun, try downloading win32gui, and run these examples:
> examples/samples_dlg/simpl_empl_edit
> examples/samples_dlg/simpl_empl_edit_bolded
> 
> , to see what I mean.

Prior to the Boost::GUI discussions of the last month or two, I have previously taken a good look at win32gui as I have been following widget library development for a few years now.  My analysis of each toolkit is irrelevant here, except to say that I found the FOX toolkit to offer what I would call "the most technically correct toolkit" (for some arbitrary value of 'correct'...).  That said, it suffers from slow development (although minor releases are frequent).

The origonal point was that variables connected to widgets, always need validation (which they dont always) and they need synchronisation (which they dont always).  I'm just letting other know what the state of the art is wrt. GUI toolkits.

regards,
Mathew