Re: validation in gui and error handling

On 10/31/2010 1:33 AM, harryos wrote:


The thing here is should the model really be aware of the user's input
data?

First, to echo John's sentiments, there's also JFormattedTextField which
might make the input of values easier on users (and less likely to be
wrong when you validate it).

(Note: none of the code in this post was checked with a compiler.)

   JFormattedTextField num = new JFormattedTextField( new Integer(32) );
   JFormattedTextField fract = new JFormattedTextField(
                 new DecimalFormat( "###,###.##" ) );

But for validating in the model, for me it kinda depends on what your
model is. If the model is an actual object with an integer field, a
decimal field and an image, then perhaps adding a factory to parse an
object from string parameters is sensible.

public class MyModel {

   private int num;
   private BigDecimal fract;
   private Image img;

   public static MyModel makeInstance( String num, String fract,
                   String img )
            throws IllegalArgumentException
   {
      // verify here...
   }

Factories are a slightly more standard idiom Java, and easily
recognizable to most programmers.

OTOH, if the int, decimal and image are unrelated to each other, if you
don't actually have a "model" for those, then building a ResultData
object seems rather baroque to me. Java already has standard models for
those, with their own string factories or constructors (as appropriate),
and there's no reason not to use them.

   String num = ...
   String fract = ...
   String img = ...
   try {
     int number = Integer.parse( num );
     BigDecimal fraction = new BigDecimal( fract );
     Image image = ImageIO.read( img );
   } catch( ... variousException ex ) {
     view.setErrorMessage( ex.toString() );
   }

This seems a lot simpler to me than your way of doing it. It's simple
enough where making it part of the model doesn't seem to add a lot of
value. It could be easily done by the controller, there's no need for a
complicated return object or special validation code.

If the code gets much more complicated, you can always add a static
"utility" method to do parsing and return an exception, but I think
that's as far as I would go unless things get truly horrendous.