× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.