[
https://issues.apache.org/jira/browse/WICKET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alastair Maw resolved WICKET-544.
---------------------------------
Resolution: Invalid
This code's been refactored with all the setType() stuff, so this bug's no
longer valid.
> Refactor duplicate code into ConversionException
> -------------------------------------------------
>
> Key: WICKET-544
> URL: https://issues.apache.org/jira/browse/WICKET-544
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-beta1
> Reporter: Chuck Deal
> Assignee: Alastair Maw
> Priority: Minor
> Fix For: 1.3.0-rc1
>
>
> I was working with wicket.datetime.util.DateConverter in an attempt to try
> and get it to report a parse error instead of silently accepting the bad
> input, when I nrealized that if it threw a ConversionException, the framework
> would be able to pick up on that (in my case FormComponent.convert() would
> catch it) and allow me to register the feedback error message.
> While following that thread, I noticed that not only was there identical code
> in FormComponent.convert in the two catch blocks, but a third class
> TypeValidator was also using the same block of code:
> Map args = new HashMap();
> final Locale locale = e.getLocale();
> if (locale != null)
> {
> args.put("locale", locale);
> }
> args.put("exception", e);
> Format format = e.getFormat();
> if (format instanceof SimpleDateFormat)
> {
> args.put("format", ((SimpleDateFormat)format).toLocalizedPattern());
> }
> All this block is really doing is analyzing the ConversionException to build
> the args HashMap for the error reporting facilities. I was thinking that if
> this code block was refactored INTO the ConversionException then the code
> duplication could be removed (as the first benefit), but then Converters
> would be able to inject their own variables into the Map to allow for even
> better message definitions.
> While I was looking at the usage of ConversionException, it also looked like
> AbstractConverter, AbstractNumberConverter,
> PropertyResolver$ArrayPropertyGetSet, and PropertyResolver$MethodGetSet might
> all benefit from the refactor by externalizing their messages and inject the
> proper variables into the Exception's Map.
> (See
> http://www.nabble.com/ConversionException-refactor-tf3559528.html#a9940039
> for original conversation)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
