personally, i would validate prior to getting to the EJB. The overhead of
validating at the EJB layer is really high, and requires, as you have
discovered, some coordination in communicating to the user.
In general, I view the key validation as occuring on the client side, and
then simply confirm the validation to ensure integrity on the server. I have
been experimenting with automating the validation process entirely (I have
used automated javascripot validation for years - the information required
for validation is contained in the HTML form names) - creating a generic
validation servlet that will use submitted form names as the validation
keys, something like:
Title_required_alphanumeric_5_20
means Title is a required field, containing letters and numerals, minimum of
1 character and maximum of 20. when I get my head around them, I imaging I
could use a filter to validate.
If you are using a ValueObject to pass data into the EJB tier, than this is
also a good place to perform validation...so when a ValueObject is created,
the data is validate and if it fails can be communicated directly to the
user. this way you can have a local message object (the Struts framework,
for example, uses message objects to collect information and repsond to the
user).
----- Original Message -----
From: "Doron Gan" <[EMAIL PROTECTED]>
To: "Jboss-User" <[EMAIL PROTECTED]>
Sent: Friday, July 20, 2001 5:10 AM
Subject: [JBoss-user] Question on business validation rules and EJB servers
in general.
> Hi,
>
> So I want my business entity objects to be consistent before they are
> commited. I figured this couold be done on the ejbStore() call when a
> transaction is about to be commited. At this time I could check, for
> example, if a string property is too long. If this fails I can
> setRollbackOnly() on the current transaction. The question is, how do I
> communicate the validation error that occured to the user? I.e. the user
> could have called a session bean that did a bunch of object modifications
> and when the transaction commited each of those objects could generate
> validation errors. Right now the client app(user) only gets a transaction
> rollback exception.
>
> Is there some-way to tie an object to the currrent transaction and use
that
> object to store all the error messages so they can be accessed
> programatically by the user if a transaction failes?
>
>
> -Doron
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user