struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: The validator & FieldChecks
Date Thu, 01 May 2003 11:11:08 GMT

The framework provides a general extension point, validate, which can be 
used to call whatever validation routine you like. The Struts validation 
is one routine that can be called here, but anything is possible.

Originally, the validation was tightly coupled to Struts. Then, we moved 
  the core to the Commons, to help uncouple it, and placed the 
Struts-specific extension in the Struts CVS.

The validation is intended to do what you ask, but work may still need 
to be done.

The next big step for Struts will be moving its messaging system to use 
the MessageList (now) in Commons Resources. This will encourage business 
domains to return a "generic" MessageList that can be passed directly to 
Struts, where it will be rendered as ActionErrors are now.

The best way to plan for the future is to help shape it. If you have a 
need for a common validation system between your business code and your 
presentation code, that is what the validation is trying to do. But, it 
may need your help to get all the way there. Most everything in Struts 
and the Commons comes from working developers solving their own problems 
and then sharing the solution.


The Struts nightly builds are build against all the other nightly builds.

Specific Struts milestones will have specific dependencies. The 
appropriate Commons JARs are included with each milestone.

It's not possible to make a flat statement whether a frozen-in-time 
milestone will be forwardly compatible with the latest nightly build of 
anything else.


Christoper Willingham wrote:
> Hello,
> I have 2 questions, both of which I tried to find answers for on my own
> by searching previous threads, etc., but have had no luck so here goes.
> 1) The system I am building includes a daemon-like stand alone java
> interface feed program plus a good-sized struts application.  Both call
> the same business layer where business validations occur.  These
> validations do not include simple data type validations so we want to
> use the validator for both before the BO's are called.   Mainly, I want
> to use the same 'canned' FieldChecks that I thought comes with
> validator(doesn't seem to be in most recent release though) as well as
> in struts.  Of course the signatures are different, which lends me to
> believe struts is somewhat coupled to what I would think should be
> generic field checking routines that could be called by either type
> client(stand alone or web app).  You see, I want to use the same field
> check code for both, and also if I need to create customs field checks,
> not have to code two versions.  Can someone explain why this is and
> better yet inform me on how best to plan for the future if indeed this
> is something in struts that has yet to be cleared up?  Am I simply stuck
> having two code sets for data type validations or would a go-between
> class that resolved the signature issues fits future plans for struts
> using the validator.  I would prefer that the way I resolve this problem
> fit future plans for decoupling the canned edits from struts, if indeed
> there are any plans for this.  Frankly I am confused on the reusability
> of the validation edits between different programs.
> 2) I'm also concerned about whether Struts has any dependencies on
> particular versions of commons jars beyond what is stated on the apache
> site(where it is said you must use at least up a particular version).
> At one point I took all the latest commons libraries and added them to
> my WEB-INF/lib, overwriting what I had before(from blank app I guess),
> and I ran into problems.  So I am worried about coupling between the
> latest Struts version and specific versions of jars.  Or can I just go
> with the latest and greatest of commons and be safe(I realizes I need
> the nightly of common-logging which should be addressed soon). 
> Chris

Ted Husted,
Struts in Action <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message