Re: Data validation, mapping, and error handling

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Aaron Bartell wrote:
> > I haven't found the JSF keyword (if one exists) that will tell a field to
> > use an alternate style if the field is in error.
> >     
>
> Here is an example of applying a custom class to a JSF field in error:
>
> JSF controller logic code:
>   
Again, I know how to do it in the controller... it's incredibly easy.  I 
can do it in EGL using the UIViewRoot and all is good.  The trick is 
trying to get the tool to do as much as possible, and that's why using 
validation is a good technique.

> The issue I had is that JSF will do the built in validations first and if
> any of them fail it will exit the JSF lifecycle and send a response back to
> the screenbefore it gets to your business logic edits.
Correct.  This is the exact same thing as using things like RANGE or 
VALUES on a display file.  For simple edits, it works great, for more 
complex edits it doesn't.  The other thing that often happens, at least 
in less mature frameworks, is that the inline editing presents a sort of 
generic error message, and often it's not nice enough for production work.

> This was enough to
> make me not use "the validation framework" unless the validations were
> incredibly simple.  These are the types of "bummers" that bite you in the
> butt 3 months after you have made the decision to go with a framework and
> are the same types of "bummers" I am watching out for in EGL.  Not that I
> won't choose EGL for some project eventually, it would just be great to not
> learn the hard way.
>   
The trick is to know the tool before you do the design.  That's why I 
was willing to chase this down a little.  I don't consider this a 
"bummer" any more than I consider the VALUES keyword in DDS a bummer.  
It's a matter of understanding how it works before designing the system.

Joe