About checking the input of the business application

Based on my experience focusing on web systems (business).

There are two most validation message display patterns.

For smartphones and tablets, choose 2 (to avoid scrolling)

The validation error items are often red colored in common.

I think it's best to use 3 as there are input validations in the current Java framework.
However, when it comes to tab indexes, I think it is necessary to implement them on the client side.
Most JavaScript validation libraries are placed on the right or just below the input items, so if you want to put them all together at the top of the screen, it might be faster to make your own.

When viewing error messages in bulk, you can see at a glance that the error has occurred, but the user will see the message to determine which entry is causing the error.

When displaying next to input items, it is clear at a glance which items and what errors are displayed, but depending on the screen layout, it may be difficult to notice the errors.(Example: If you do not scroll to see the error item)

Which is not more common.You can decide based on the number of entries, screen layout, and user familiarity.

It depends on the layout.The only thing I can say is that if you display an error, the layout will fail, which is proof that the design is poor design.In the case of web applications, it is necessary to take into account that the window size, font size, and screen resolution (ppi, not size) may vary depending on the user environment.Maybe the reason why I'm worried that the layout will collapse is because I'm trying to make a rough screen layout without considering them.

If you are using a framework, the first choice is to use the validation mechanism provided in the framework.If not, it would be either a general purpose library or a self-made one, but it depends on the requirements, so there is no best.If it's small, it might be faster to make your own, and if it's a general purpose library, it's more likely that it won't be flexible.The same can be said on the client side.

About web application input verification.

The general rule is to verify the input value of the web application on the server side.Client side validation can be bypassed by simply throwing a request without using a browser.(By the way, if you don't verify the same logic, for example, because you use select elements and you can only select fixed values in your browser, this will also be avoided.)

Server-side validation is designed to ensure that the input meets application requirements.On the other hand, please think that the verification on the client side is for UX.The purpose is completely different, so there is no need to prioritize which one.If you can press the Send button to see the error, you don't have to verify it on the client side.

Again, the input value verification is to ensure that the input meets the application requirements.Not for security purposes (except for validation of data other than user input values, such as CSRF avoidance tokens).For example, it is good to reject single-quotation marks according to the character types specified in the application requirements, but do not reject or remove single-quotation marks as SQL injection measures when they are not in the application requirements.To ensure security, use placeholders when data is being used (screened or DB saved) or SQL.

Hello
There are several typical patterns of input validation results, but … you may choose only one of the following or use it in combination.

Reasons to distinguish use depend on the ease of error and the steps you enter into the system.

Also, if you want to place an item in the vicinity, you need to make sure that the layout does not collapse even if you print an error message, and consider cases where you cannot see the error message for each item.
For example, it is difficult to display each item near the table type.
You may group into certain areas.

Also, let's implement verification of input values on both the client side and the server side.
You also need to check the values that you do not want to save to the database.

With B2C's system, I put it close to the items with priority on ease of understanding.Recently, I often see them overlaying in the "fukidashi" format.With this method, it's an overlay, so there's no need to worry about misaligned.
The disadvantage of Fukidashi is that it can be difficult to see many messages at once.As a countermeasure, it is recommended that the client inspects the message in real time (e.g., whenever the focus is off the item) to a certain extent.

In the case of business systems, many of the specifications were that users would be able to cover some of the difficulties, and in order to reduce development costs, servers would be notified of the results of the inspection in a dedicated area.

If you want to implement Fukidashi messages on the client side, it's easy to use a genre of js library called EFO.
It is recommended that you use the server side that comes with your framework.