And, nothing is stopping you from doing something like this in your
own code. I have a class called ComponentUtils where I put stuff like
this. I have two methods:
public static T extends Serializable IModelT modelOf(T bean);
public static T extends Serializable IModelT modelFor(ClassT
Or use wicket as I explained on this page :)
http://java.dzone.com/articles/faster-development-easywicket
From: James Carman jcar...@carmanconsulting.com
To: users@wicket.apache.org
Sent: Fri, April 16, 2010 2:05:12 PM
Subject: Re: Type Inference for Wicket
://java.dzone.com/articles/faster-development-easywicket
From: James Carman jcar...@carmanconsulting.com
To: users@wicket.apache.org
Sent: Fri, April 16, 2010 2:05:12 PM
Subject: Re: Type Inference for Wicket 1.4
And, nothing is stopping you from doing something
I can sympathise with that. However I don't think it would be a
maintenance nightmare if the constructors are set to private; but that
would mean a dramatic API change for such convenience and I'm guessing
you're not willing to do this.
Best,
James.
On 14 April 2010 17:01, Igor Vaynberg
On 04/15/10 13:06, James Perry wrote:
I can sympathise with that. However I don't think it would be a
maintenance nightmare if the constructors are set to private; but that
would mean a dramatic API change for such convenience and I'm guessing
you're not willing to do this.
Apart from the huge
This is the key - and it has been discussed before (in the many grueling 1.4
conversations). The short of it is that with private constructors there's a
huge change and an inability to extend. And without the private
constructors, the static methods are dumb and extraneous because you would
need
you are going to have one factory method for each constructor, its
going to be a pita to maintain. not something we will want in core.
-igor
On Wed, Apr 14, 2010 at 8:51 AM, James Perry
james.austin.pe...@gmail.com wrote:
I am looking to migrate from Wicket 1.3 and Wicket 1.4 and I really
like