Re: Error messages and validating data -- WEB400

One method is to include all possible errors by the fields they apply to,
and put them in unique <div> containers set to hidden. When you go through
and process and find any errors make the appropriate errors "visable".

On Tue, Mar 5, 2013 at 8:38 AM, Dean Eshleman <Dean.Eshleman@xxxxxxxxxxxx>wrote:

Hi,

We are just starting to do some web development for our internal apps, and
I have a couple architecture questions.

Displaying error messages. This would be in relation to a user entering
data on a form and pressing enter or clicking OK to validate the data. The
validation could result in multiple error messages being generated. It
looks like we have 3 options. One, display them in a list at the top of
the screen before the detail fields. Two, display them in a pop-up window.
Three, display the error next to the field that caused the error. Since
one field could actually generate multiple messages, this last option could
be a bit tricky. Is there any consensus on which method is best?
Currently, we have 5250 apps as well as WinC/IBM I client server apps.
The 5250 apps display the messages in a 1 line message subfile at the
bottom of the screen and the client server apps use either a Dialog box to
display one message at a time or a pop up window to display multiple
messages.

Validating data. First, some background. Our current architecture for
our web apps is VS .NET for the front end for the UI and RPG on the back
end (generated from CA Plex) for business logic and data access. The last
5 years or so, I have been pushing the MVC architecture. With this
approach, I want the UI to be as thin as possible. This would mean either
no data validation in the UI or very little. Checking for
required/optional fields, valid dates and valid numeric are things I can
think of that would be acceptable to check on the UI side. Any validation
that requires data access would still occur only in the RPG code. Also,
the RPG code would repeat all of the client side validation since we don't
necessarily trust the input. That way, when the next UI flavor of the
month comes along (such as mobile or receiving data electronically) we
don't need to change the back end code. It can be reused. Our .NET
developers think we should take advantage of the "validation
controls" that are available in .NET. These "validation controls" are
attached at the field level and perform validation for that field. The
thought is that this will provide a better user experience because the
validation (at least some of it) will occur more quickly since it is
happening on the client side. Any thoughts on how much client side
validation should be done and the use of these validation controls? Is my
approach to do all of the data validation in the RPG code old school? I'll
be interested to hear your thoughts.

Dean Eshleman
Software Development Architect

Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com<http://www.everence.com>

________________________________________
Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do not
use or disclose this information. If you received this e-mail in error,
please delete or otherwise destroy it and contact us at (800) 348-7468 so
we can take steps to avoid such transmission errors in the future. Thank
you.
_______________

______________________________________________________________________
Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do not
use or disclose this information. If you received this e-mail in error,
please delete or otherwise destroy it and contact us at (800) 348-7468 so
we can take steps to avoid such transmission errors in the future. Thank
you.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.