0

I want to know the best pratice, to validate the attributes on jsf project. I know two forms of validation:

Option 1: Validate on JSF page

JSF Page validation:

<h:inputText value="#{userBean.textEg}" maxlength="15" />

Bean attribute:

private String textEg; // ++getAndSetter

Where i defined by param at input my maxLength.

Option 2: Validate on Bean

JSF Page attribute:

<h:inputText value="#{userBean.textEg}" />

Bean Validation:

@Max(15)
private String textEg; // ++getAndSetter

Both options work fine, but, my question is when to use option 1 and when to use option 2, if apply.

0

If technology allows you you should validate in multiple layers - so someone with a security inclination would argue - "why not both?".

But to keep it simple I would suggest option 2. The reason being option 2 allows you to unit test your application and your unit test will be bound by the restrictions of the actually deployed application. Option 1 is unlikely to be UTed and hence I would suggest restricting yourself to the bare minimum code or logic possible.

0

I would say:

"Validate in every place you can do so."

The sooner you validate, the sooner you provide feedback to the user of the system. This reduces eventual errors, provides hands-on training and eventually improves the user experience.

You need to validate in your business logic, because there are many business rules that won't make it to your UI. The more important reason is that your back end cannot afford to trust your front end, especially over the web.

You need to validate in your repository because the UI isn't the only place that you can make changes to your data.

Especially with this strategy in place, it is very important that data is treated coherently, even if it is not treated consistently. The classic issue of this dilemma is a simple text area input field. It can be no longer than 43 bytes, say, because that is what the database field size is defined to be.

However, the text area in a web browser can accept non-ASCII characters, such as accents and glyphs. So, the string that arrives in your application may fit the text area maximum size, but, when translated to UTF-8 for insertion in your database, it's size might be somewhat larger.

The feedback to the user entering the data has to make sense, even when they don't (rightly so) understand the details of character encodings or database field limits.

  • I got it, but, i means about validation on front-end, how is the best decision to be made, conjecturing that my back-end have validation too. – AndreiDeholte Jul 15 '15 at 13:44
  • Validation at the front end can often give more immediate and pointed feedback. If you put up a tool tip when the character count reaches the limit, or even have a text label showing the number of characters left, as this site does, you reduce the shock to the user. There are a number of ways you can provide useful feedback: chose one or more of them. – BobDalgleish Jul 15 '15 at 23:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.