You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Chuck Deal (JIRA)" <ji...@apache.org> on 2007/05/08 19:31:15 UTC
[jira] Created: (WICKET-544) Refactor duplicate code into
ConversionException
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
Reporter: Chuck Deal
Priority: Minor
Fix For: 1.3
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.
[jira] Updated: (WICKET-544) Refactor duplicate code into
ConversionException
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alastair Maw updated WICKET-544:
--------------------------------
Fix Version/s: (was: 1.3)
Affects Version/s: 1.3
> 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
> Reporter: Chuck Deal
> Priority: Minor
>
> 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.
[jira] Updated: (WICKET-544) Refactor duplicate code into
ConversionException
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alastair Maw updated WICKET-544:
--------------------------------
Fix Version/s: 1.3.0-rc1
Assignee: Alastair Maw
> 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.
[jira] Updated: (WICKET-544) Refactor duplicate code into
ConversionException
Posted by "Alastair Maw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alastair Maw updated WICKET-544:
--------------------------------
Affects Version/s: (was: 1.3)
This isn't a blocker for 1.3, taking off the 1.3 list for now.
> 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
> Reporter: Chuck Deal
> Priority: Minor
>
> 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.
[jira] Commented: (WICKET-544) Refactor duplicate code into
ConversionException
Posted by "Chuck Deal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494350 ]
Chuck Deal commented on WICKET-544:
-----------------------------------
As soon as I get back to my Wicket-based project, I'll try to work on a patch.
> 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
> Reporter: Chuck Deal
> Priority: Minor
> Fix For: 1.3
>
>
> 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.