You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Peter Ertl (JIRA)" <ji...@apache.org> on 2009/07/23 01:01:14 UTC

[jira] Updated: (WICKET-2390) random-looking usage of Serializable and String as parameters for feedback messages

     [ https://issues.apache.org/jira/browse/WICKET-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl updated WICKET-2390:
-------------------------------

    Description: 
When looking over feedback messages I found it confusing that some methods use as a parameter

   Serializable message

and others

  String message.

For example in org.apache.wicket.Component:

	public final void error(final --- Serializable --- message)
	{
		Session.get().getFeedbackMessages().error(this, message);
		Session.get().dirty();
	}

and

	public final void fatal(final --- String  ---- message)
	{
		Session.get().getFeedbackMessages().fatal(this, message);
		Session.get().dirty();
	}

There are a few more methods that show this difference.

When looking at FeedbackMessage's ctor I guess the right pick would be Serializable:

 FeedbackMessage::  public FeedbackMessage(final Component reporter, final Serializable message, final int level)

I think for consistency all these methods should use Serializable. This should not break API compatibility as 

   String implements Serializable

and all methods calls to e.g. fatal(String) will match fatal(Serializable)

This affects 1.3.x and 1.4.x


  was:
When looking over feedback messages I found it confusing that some methods use as a parameter

   Serializable message

and others

  String message.

For example in org.apache.wicket.Component:

	public final void error(final --- Serializable --- message)
	{
		Session.get().getFeedbackMessages().error(this, message);
		Session.get().dirty();
	}

and

	public final void fatal(final --- String  ---- message)
	{
		Session.get().getFeedbackMessages().fatal(this, message);
		Session.get().dirty();
	}

There are a few more methods that show this difference.

When looking at FeedbackMessage's ctor I guess the right pick would be Serializable:

 FeedbackMessage::  public FeedbackMessage(final Component reporter, final Serializable message, final int level)

I think for consistency all these methods should use Serializable. This should not break API compatibility as 

   String implements Serializable

and all methods callw to e.g. fatal(String) will match fatal(Serializable)

This affects 1.3.x and 1.4.x



> random-looking usage of Serializable and String as parameters for feedback messages
> -----------------------------------------------------------------------------------
>
>                 Key: WICKET-2390
>                 URL: https://issues.apache.org/jira/browse/WICKET-2390
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>            Reporter: Peter Ertl
>
> When looking over feedback messages I found it confusing that some methods use as a parameter
>    Serializable message
> and others
>   String message.
> For example in org.apache.wicket.Component:
> 	public final void error(final --- Serializable --- message)
> 	{
> 		Session.get().getFeedbackMessages().error(this, message);
> 		Session.get().dirty();
> 	}
> and
> 	public final void fatal(final --- String  ---- message)
> 	{
> 		Session.get().getFeedbackMessages().fatal(this, message);
> 		Session.get().dirty();
> 	}
> There are a few more methods that show this difference.
> When looking at FeedbackMessage's ctor I guess the right pick would be Serializable:
>  FeedbackMessage::  public FeedbackMessage(final Component reporter, final Serializable message, final int level)
> I think for consistency all these methods should use Serializable. This should not break API compatibility as 
>    String implements Serializable
> and all methods calls to e.g. fatal(String) will match fatal(Serializable)
> This affects 1.3.x and 1.4.x

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.