Hi Rick,
there is another way to work with parameter form:action. If you use
Tiles in your applications create one reusable tiles lay with elements of
design, control buttons and page control. In this case you can use the page
with many forms. Then solution <html:form action="${myFormBean.the_action_URI}"/>
can be replaced with <html:form action="${ControlBean.the_action_URI}"/> .
What do you think ?
( Your lessons still the best ).
Andrey .
RR> Erik Weber wrote:
>> if you have a single JSP
>> that houses a form that is used for different commands (add, update),
>> you are still going to need two separate form elements in
>> validation.xml, causing redundancy (until "field inheritance" is
>> implemented at least), correct?
RR> That is correct, although if you are using the "trick" way I mentioned
RR> you could "sort" of get around this by setting up a
RR> "baseEmployeeValidation" in your valiation.xml that you know will be
RR> common amongst all the particular forms in question. Then you can create
RR> a couple sub ones for the specifics (ie = "updateEmployeeValidation",
RR> "insertEmployeeValiation"). Then, since you are calling the validation
RR> manually you simply call the baseEmployeeValidation and then the
RR> appropriate custom valiation in your action. I haven't tried this, but
RR> it should work.
RR> Although I just took a brief look at the API and I'm not sure if you
RR> call validate() more than once if you end up with a new Instance of the
RR> ValidationResults being set to the ValidationForm's instance of
RR> "validatorResults." If it reuses the same instance and just adds on to
RR> the map then that would be cool. If not, then the best you could do with
RR> this trick would be to call the base common validation and if no errors
RR> return then proceed on to validate the next custom validation. The
RR> drawback to this is say the user completes a large form and submits.
RR> It's possible he'll get a validation error saying "something is wrong"
RR> and then he could submit after fixing it and get a new error (based on
RR> the custom portion). Sort of annoying because it should come back all at
RR> once. Anyway an attempt at this might look like: (not tested at all)...
RR> validate(..) {
RR> ServletContext application = getServlet().getServletContext();
RR> ActionErrors errors = new ActionErrors();
RR> String parameter = request.getParameter( mapping.getParameter() );
RR> //set up Validator and test the base stuff common to both the add
RR> //update. Remember, we know the name of the base Validation..
RR> Validator validator = Resources.initValidator( "baseEmployeeValiation",
RR> this, application, request, errors, page);
RR> try {
RR> validatorResults = validator.validate();
RR> } catch (ValidatorException e) {
RR> log.error(e.getMessage(), e);
RR> }
RR> //you might in the above also be able to test this custom
RR> //stuff, just haven't looked at how validator.validate() deals
RR> //with validatorResults if validate is called more than once
RR> //parameter would be your dispatch parameter represening the
RR> //"custom" unique part that needs validation..ie "addEmployee"
RR> //or "updateEmployee"
RR> if ( validatorResults.isEmpty() ) { //no errors from the base test
RR> validator = Resources.initValidator( parameter, this, application,
RR> request, errors, page);
RR> try {
RR> validatorResults = validator.validate();
RR> } catch (ValidatorException e) {
RR> log.error(e.getMessage(), e);
RR> }
RR> }
RR> return errors;
RR> }
RR> Probably easier just to delcare the two different validations in the xml
RR> and copy and paste the common validations into both:) Extends sure would
RR> be nice.
--
Best regards,
Andrey mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
