Re: wicket migrating getConverter to 1.5
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter; // cast
}
else
{
return super.getConverter(clazz);
}
}
On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov mgrigo...@apache.org wrote:
Hi Vineet,
Can you paste an example that needs casting in the users' code ?
On Mon, Nov 28, 2011 at 8:20 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
you are right cast is only done once but it is done by *wicket users*
when they override the method,
it can be avoided by introducing the new method like it is discussed
in the that thread but the gain is
minimal..
On Sun, Nov 27, 2011 at 8:55 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now, thats
all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
:-)
We have different understanding of what is user code ...
I mean that you do that once in the component (e.g. DateTextField) and
then you can do:
Date asDate = dateField.getConverter(Date.class).convertToObject(..., locale)
Calendar asCalendar =
dateField.getConverter(Calendar.class).convertToObject(..., locale)
Integer sinceEpoch =
dateField.getConverter(Integer.class).convertToObject(..., locale)
...
So, you do the cast in the library code (it doesn't matter that the
component is yours. in this case you have your own library) and from
there on all clients of this component don't need to cast.
On Mon, Nov 28, 2011 at 10:05 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter; // cast
}
else
{
return super.getConverter(clazz);
}
}
On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov mgrigo...@apache.org wrote:
Hi Vineet,
Can you paste an example that needs casting in the users' code ?
On Mon, Nov 28, 2011 at 8:20 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
you are right cast is only done once but it is done by *wicket users*
when they override the method,
it can be avoided by introducing the new method like it is discussed
in the that thread but the gain is
minimal..
On Sun, Nov 27, 2011 at 8:55 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now,
thats all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For
Re: wicket migrating getConverter to 1.5
martin,
i actually know what you are referring to user code and library code :)
i am not saying dont do that cast,just saying it can be hidden from a
wicket user,
wicket user will just override the new method which will have
formcomponent generic type,the getconverter(*) method will call the
new method ,do casting etc. like it was discussed in that thread..
but yeah the gain is not worth the pain ..
On Mon, Nov 28, 2011 at 3:50 PM, Martin Grigorov mgrigo...@apache.org wrote:
:-)
We have different understanding of what is user code ...
I mean that you do that once in the component (e.g. DateTextField) and
then you can do:
Date asDate = dateField.getConverter(Date.class).convertToObject(...,
locale)
Calendar asCalendar =
dateField.getConverter(Calendar.class).convertToObject(..., locale)
Integer sinceEpoch =
dateField.getConverter(Integer.class).convertToObject(..., locale)
...
So, you do the cast in the library code (it doesn't matter that the
component is yours. in this case you have your own library) and from
there on all clients of this component don't need to cast.
On Mon, Nov 28, 2011 at 10:05 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter; // cast
}
else
{
return super.getConverter(clazz);
}
}
On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Vineet,
Can you paste an example that needs casting in the users' code ?
On Mon, Nov 28, 2011 at 8:20 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
you are right cast is only done once but it is done by *wicket users*
when they override the method,
it can be avoided by introducing the new method like it is discussed
in the that thread but the gain is
minimal..
On Sun, Nov 27, 2011 at 8:55 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now,
thats all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
Re: wicket migrating getConverter to 1.5
;] hehe yep this is a little misunderstatement ;] from that point this is ok.
well as vineet said it is small gain but it will be less confusing for
coders. (we are just discussing, right?? no hard feelings ;])
what about locator issue I pointed out??
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 28 November 2011 12:47, vineet semwal vineetsemwal1...@gmail.com wrote:
martin,
i actually know what you are referring to user code and library code :)
i am not saying dont do that cast,just saying it can be hidden from a
wicket user,
wicket user will just override the new method which will have
formcomponent generic type,the getconverter(*) method will call the
new method ,do casting etc. like it was discussed in that thread..
but yeah the gain is not worth the pain ..
On Mon, Nov 28, 2011 at 3:50 PM, Martin Grigorov mgrigo...@apache.org wrote:
:-)
We have different understanding of what is user code ...
I mean that you do that once in the component (e.g. DateTextField) and
then you can do:
Date asDate = dateField.getConverter(Date.class).convertToObject(...,
locale)
Calendar asCalendar =
dateField.getConverter(Calendar.class).convertToObject(..., locale)
Integer sinceEpoch =
dateField.getConverter(Integer.class).convertToObject(..., locale)
...
So, you do the cast in the library code (it doesn't matter that the
component is yours. in this case you have your own library) and from
there on all clients of this component don't need to cast.
On Mon, Nov 28, 2011 at 10:05 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter; // cast
}
else
{
return super.getConverter(clazz);
}
}
On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov mgrigo...@apache.org
wrote:
Hi Vineet,
Can you paste an example that needs casting in the users' code ?
On Mon, Nov 28, 2011 at 8:20 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
you are right cast is only done once but it is done by *wicket users*
when they override the method,
it can be avoided by introducing the new method like it is discussed
in the that thread but the gain is
minimal..
On Sun, Nov 27, 2011 at 8:55 PM, Martin Grigorov mgrigo...@apache.org
wrote:
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now,
thats all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org
wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering
the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe,
wicket migrating getConverter to 1.5
hi all,
In 1.5 getConverter has new signature using generics : public C
IConverterC getConverter(ClassC type)
and this is nice when you have global converter registered in
application but in 1.4 it was handy to return different converter in
specific component by overriding its getConverter(type).
now it is also possible but it requires casting from C type to target
type of the component and then back to C. for me this is a bit
inconsistent as component always knows which type it using.
maybe there should be additional method that can be overridden and it
will return converter of type declared on component, what do you
think??
public abstract class LinkL
{
public Link(String id, IModelL model)
{
super(id, model);
}
@Override
public IConverterL getConverter()
{
return new MyCustomConverterThatIsUsingTypeL;
}
}
and another things is how ConverterLocator sets converters.
it is possible to register converter that doesnt match key type
ConverterLocator locator = (ConverterLocator) super.newConverterLocator();
locator.set(MyType.class, new IConverterString()
{
@Override
public String convertToObject(String value, Locale locale)
{
return null;
}
@Override
public String convertToString(String value, Locale locale)
{
return null;
}
});
where set should be declared as public final C IConverterC
set(final ClassC c, final IConverterC converter).
how you deal with this things? maybe there is a better way
thanks
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
like this?
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-td3744435.html
On Sun, Nov 27, 2011 at 7:36 PM, kamiseq kami...@gmail.com wrote:
hi all,
In 1.5 getConverter has new signature using generics : public C
IConverterC getConverter(ClassC type)
and this is nice when you have global converter registered in
application but in 1.4 it was handy to return different converter in
specific component by overriding its getConverter(type).
now it is also possible but it requires casting from C type to target
type of the component and then back to C. for me this is a bit
inconsistent as component always knows which type it using.
maybe there should be additional method that can be overridden and it
will return converter of type declared on component, what do you
think??
public abstract class LinkL
{
public Link(String id, IModelL model)
{
super(id, model);
}
@Override
public IConverterL getConverter()
{
return new MyCustomConverterThatIsUsingTypeL;
}
}
and another things is how ConverterLocator sets converters.
it is possible to register converter that doesnt match key type
ConverterLocator locator = (ConverterLocator) super.newConverterLocator();
locator.set(MyType.class, new IConverterString()
{
@Override
public String convertToObject(String value, Locale locale)
{
return null;
}
@Override
public String convertToString(String value, Locale locale)
{
return null;
}
});
where set should be declared as public final C IConverterC
set(final ClassC c, final IConverterC converter).
how you deal with this things? maybe there is a better way
thanks
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
something like that, my google didnt show any result for getConverter 1.5 ;] I will read that, thanks pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
I just dont understand why getting converter is so strict right now, thats all
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now, thats all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
fair enough ;] pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Hi Vineet,
Can you paste an example that needs casting in the users' code ?
On Mon, Nov 28, 2011 at 8:20 AM, vineet semwal
vineetsemwal1...@gmail.com wrote:
you are right cast is only done once but it is done by *wicket users*
when they override the method,
it can be avoided by introducing the new method like it is discussed
in the that thread but the gain is
minimal..
On Sun, Nov 27, 2011 at 8:55 PM, Martin Grigorov mgrigo...@apache.org wrote:
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq kami...@gmail.com wrote:
dont get me wrong, technically it is OK, it is just the logic is
unclear and code redundant.
In my opinion frameworks are build to simplify work, that's why I said
it should ring bells - this goes in wrong direction.
I think this response
http://apache-wicket.1842946.n4.nabble.com/Can-t-properly-override-getConverter-on-FormComponent-subclasses-tp3744435p3744867.html
explains that the cast is done once, in the library code, and then all
users' code gain from that. No casts in the users' code
I perfectly understand that Component has no idea of type declared on
descendant but for me it simply doesnt matter. Component should knew
itself that it has converter and if there is none it should ask
application for any. now this two step process is implemented in one
method.
Component.java has no converter. Its #getConverter() just delegates to
the ConverterLocator
Any component may have its own converter, but since Component class
has no generic type and IConverter class has such we experience
troubles when we want to mix the generic type of for example
FormComponentT with IConverterT because FormComponent's T is
declared at type level, and IConverter's T at method level
(Component.getConverter()), and as a result Java says that these T's
are not the same type.
I just dont understand why getting converter is so strict right now, thats
all
Try to improve it. Play with the source and if you have success come
back with your solution.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
On 27 November 2011 15:55, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq kami...@gmail.com wrote:
well yeah this is exactly the same except for locator.
code like this
public final C IConverterC getConverter(ClassC clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverterC)converter;
}
else
{
return super.getConverter(clazz);
}
}
should always ring bells that something is wrong.
Care to explain what exactly is wrong ?
anyway I think that type checking should be done while registering the
converter and not while getting it.
pozdrawiam
Paweł Kamiński
kami...@gmail.com
pkaminski@gmail.com
__
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
thank you,
regards,
Vineet Semwal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
