|
From: Tom T. <tom...@pr...> - 2004-04-28 07:39:02
|
Hello,
While upgrading to spring 1.0.1, I've noticed some minor annoyances that
may be easy to fix, possibly for 1.0.2:
1. HttpServletBean apparently does not support properties of type
Resource, because BeanWrapperImpl does not register a Resource property
editor by default. However, there's no possibility to register custom
editors with the BeanWrapper used by HttpServletBean. Maybe an
"initBeanWrapper" protected method could be added here, like initBinder
in BaseCommandController?
2. Unlike ResourceBundleMessageSource, ResourceBundleViewResolver only
has a basename property, no basenames property. As we keep controller
cfg, dao cfg and messages in separate resource files by functional
domain, it also makes sense to keep the view cfg in different files.
We're currently using an adapted ResourceBundleViewResolver, but maybe
this functionality could be added to spring, or maybe there's a good
reason to keep all view cfg in a single file?
3. In AbstractWizardFormController, it would be useful if processFinish
had an extra "int submissionPage" parameter (the currentPage value in
processFormSubmission could be passed to validatePagesAndFinish and on to
processFinish), though I have no suggestion how to add this in a
backward-compatible way...
It would be useful, because some of our legacy stored procedures perform
validation logic that we can't duplicate in java, i.e. the result of a
stored procedure could indicate a user-correctable error, which we would
like to display in the same way as a global validation error, e.g.:
protected ModelAndView processFinish( HttpServletRequest request,
HttpServletResponse response, Object command,
BindException errors, int page ) throws Exception {
// stored procedure is called in onSubmit,
// messageInfo is an output parameter
MessageInfo messageInfo = onSubmit( command );
if ( messageInfo.isError() ) {
errors.reject( "", messageInfo.getMessage() );
return showPage( request, errors, page );
}
if ( messageInfo.isWarning() ) {
return handleWarning( command, messageInfo );
}
return handleSuccess( command, messageInfo );
}
Note that getCurrentPage can't be called in processFinish, as we are
"after processFormSubmission".
Even if the page parameter can't be added to processFinish, it would
still be useful to add it to validatePagesAndFinish:
private ModelAndView validatePagesAndFinish(HttpServletRequest request,
HttpServletResponse response, Object command,
BindException errors, int currentPage) throws Exception {
// in case of binding errors -> show current page
if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
return showPage(request, errors, currentPage);
}
for (int page = 0; page < pages.length; page++) {
validatePage(command, errors, page);
// in case of field errors on a page -> show the page
if (errors.getErrorCount() - errors.getGlobalErrorCount() > 0) {
return showPage(request, errors, page);
}
}
// no field errors -> maybe global errors, or none at all
return processFinish(request, response, command, errors,
currentPage);
}
The first if was added to ensure the current page is shown again if there
were binding errors, such as typeMismatch. Otherwise, those errors will
always result in the first page being shown, instead of the submission
page where the error actually occured.
Also, shouldn't the "if (pages == null | pages.length == 0)" in setPages
use "||" instead of "|"?
Kind regards,
Tom.
|