Question About Struts' validation

[Aquila Deus]

Hi all!

Since the validation of properties is tightly bounded to FormBean, why
not configure validation in FormBean instead? For example, you may use
following code in a setName() method:
if (! name.matches("^\w+$")) throws ValidationException("name is not
valid!");

and then the exception is caught by struts and the error message is set
to a corresponding request-scope variable such as
"myformbean.errors.name".

 

[Ryan Stewart]

Hi all!

Since the validation of properties is tightly bounded to FormBean, why
not configure validation in FormBean instead?

Instead of... what? And I think you mean ActionForm instead of FormBean.

For example, you may use
following code in a setName() method:
if (! name.matches("^\w+$")) throws ValidationException("name is not
valid!");

throws -> throw
A user entering invalid form data is hardly an exceptional circumstance. I think
most would agree this would not be a good use of Exceptions.

and then the exception is caught by struts and the error message is set
to a corresponding request-scope variable such as
"myformbean.errors.name".

Are you aware that there is a validate method in ActionForm that is for exactly
what you've described here? It's how all validation in Struts should be handled,
either automatically or manually.

 

[Aquila Deus]

Instead of... what?

Instead of using a separated configuration file.

And I think you mean ActionForm instead of FormBean.

Aren't they the same?

throws -> throw

AHHH! forget this, I need to set a better syntax coloring pattern...

A user entering invalid form data is hardly an exceptional circumstance. I think
most would agree this would not be a good use of Exceptions.

Are you aware that there is a validate method in ActionForm that is for exactly
what you've described here? It's how all validation in Struts should be handled,
either automatically or manually.

Yes. But why not use exception? I think an invalid form data passed to
ActionForm is very similiar to an invalid argument passed to a method,
isn't it? If a user enter an invalid data, it should be first checked
by javascript (and it would be "exceptional" if he turns js off)

 

[Ryan Stewart]

Instead of using a separated configuration file.

It's your choice. All validation (that I'm aware of) in Struts is done via the
ActionForm's validate method. How you define this validation is up to you.

Aren't they the same?

There is no FormBean class in the Struts libraries.

[...]

Yes. But why not use exception? I think an invalid form data passed to
ActionForm is very similiar to an invalid argument passed to a method,
isn't it? If a user enter an invalid data, it should be first checked
by javascript (and it would be "exceptional" if he turns js off)

They are not similar at all. An end user passing malformed data into your
program is totally different from you as a programmer passing malformed data
from one part of your program to another. Unless you intend to show the
Exception to the user (bad idea), don't use one. For example, a user entering a
date in an improper format is not exceptional. It happens often (if you allow
free typing in date fields). However, accepting that value and passing it to a
method that requires a properly formatted date would be exceptional. That's
where input validation has entered the picture since time (almost) out of
memory. After getting the value but before passing it along, you check to make
sure it is valid. There are two possible outcomes: it is valid or it is invalid.
Either of the two is a natural result of checking the data for validity. There
is nothing exceptional about either one of them. An exceptional circumstance
might be if you attempt to validate something and find nothing there (e.g. a
null value). That would indicate a flaw in your design and be exceptional in
that it is not expected to occur.

 

[Aquila Deus]

There is no FormBean class in the Struts libraries.

in struts-config.xml, <form-bean>

They are not similar at all. An end user passing malformed data into your
program is totally different from you as a programmer passing malformed data
from one part of your program to another. Unless you intend to show the
Exception to the user (bad idea), don't use one. For example, a user entering a
date in an improper format is not exceptional. It happens often (if you allow
free typing in date fields). However, accepting that value and passing it to a
method that requires a properly formatted date would be exceptional. That's
where input validation has entered the picture since time (almost) out of
memory. After getting the value but before passing it along, you check to make
sure it is valid. There are two possible outcomes: it is valid or it is invalid.
Either of the two is a natural result of checking the data for validity. There
is nothing exceptional about either one of them. An exceptional circumstance
might be if you attempt to validate something and find nothing there (e.g. a
null value). That would indicate a flaw in your design and be exceptional in
that it is not expected to occur.

I see. But my reason to use exceptions is that the same ActionForm may
be used by web service or some agent program. Thus it may be better to
throw exceptions at ActionForm's code. If the user is a human, struts
should be catch the exception and give him a human-readable error
message instead (not directly - the msg is saved to some variable for
jsp to display). Besides, isn't it more natural for a ActionForm
developer to throw exceptions (just what they do in ordinary beans)
rather than return an error message? Since ActionForm is not accessed
by end-user directly, I think the job to present its exception/error is
jsp and struts' job.

 

[Ryan Stewart]

I see. But my reason to use exceptions is that the same ActionForm may
be used by web service or some agent program.

Do you mean another program might pass data to your application? A web service
or other program should not use an ActionForm from your application. ActionForms
are internal to the Struts framework, and I think it would generally be
considered bad design to pass them around to other applications. And if you do
mean another application is simply sending requests to your application, are you
going to serialize the exception and send it back? Encode it in the response? Or
are you going to send back some kind of error code? I think the latter is more
likely, and in that case you still don't have any use for an exception.
Whoever/whatever your "user" is, you're unlikely to want he/she/it to see an
exception.

Thus it may be better to
throw exceptions at ActionForm's code. If the user is a human, struts
should be catch the exception and give him a human-readable error
message instead (not directly - the msg is saved to some variable for
jsp to display).

Again, humans entering invalid data is not exceptional. You're also overlooking
the likely circumstance of multiple validation errors. If your ActionForm throws
an exception at the first validation error, you're looking at multiple form
submissions to get all of the errors worked out since you can only alert the
user to one at a time. That would be annoying at best.

Besides, isn't it more natural for a ActionForm
developer to throw exceptions (just what they do in ordinary beans)

Ordinary beans throw exceptions? What do you mean?

rather than return an error message? Since ActionForm is not accessed
by end-user directly, I think the job to present its exception/error is
jsp and struts' job.

It is Struts' job to present errors, but I still maintain that the errors
shouldn't be generated by exceptions because validation errors are not
exceptional.

 

[Aquila Deus]

Do you mean another program might pass data to your application? A web service
or other program should not use an ActionForm from your application. ActionForms
are internal to the Struts framework, and I think it would generally be
considered bad design to pass them around to other applications. And if you do
mean another application is simply sending requests to your application, are you
going to serialize the exception and send it back? Encode it in the response? Or
are you going to send back some kind of error code? I think the latter is more
likely, and in that case you still don't have any use for an exception.
Whoever/whatever your "user" is, you're unlikely to want he/she/it to see an
exception.

Again, humans entering invalid data is not exceptional. You're also overlooking
the likely circumstance of multiple validation errors. If your ActionForm throws
an exception at the first validation error, you're looking at multiple form
submissions to get all of the errors worked out since you can only alert the
user to one at a time. That would be annoying at best.

Ordinary beans throw exceptions? What do you mean?

ah, ordinary classes. (and IllegalArgumentException)

It is Struts' job to present errors, but I still maintain that the errors
shouldn't be generated by exceptions because validation errors are not
exceptional.

understand

 

[Aquila Deus]

Ryan Stewart wrote:
<snip>

Heh, I just found that JSF does use exception for validating

 

[Ryan Stewart]

Ryan Stewart wrote:
<snip>

Heh, I just found that JSF does use exception for validating

Hmm, well to each his own. I currently have no experience with JSF, so I can't
answer that. If it's for the same general purpose, I won't be won over easily. I
was hoping JSF would be much better than Struts, but things like this that I'm
hearing are starting to make me doubt.

 

[Aquila Deus]

Hmm, well to each his own. I currently have no experience with JSF, so I can't
answer that. If it's for the same general purpose, I won't be won over easily. I
was hoping JSF would be much better than Struts, but things like this that I'm
hearing are starting to make me doubt.

JSF just covers more things. I would rather to see Sun add simple event
handling into jsp and taglib. But jsf is the future...