You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by kamiseq <ka...@gmail.com> on 2011/11/27 15:06:43 UTC
wicket migrating getConverter to 1.5
hi all,
In 1.5 getConverter has new signature using generics : public <C>
IConverter<C> getConverter(Class<C> 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 Link<L>
{
public Link(String id, IModel<L> model)
{
super(id, model);
}
@Override
public IConverter<L> 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 IConverter<String>()
{
@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> IConverter<C>
set(final Class<C> c, final IConverter<C> converter).
how you deal with this things? maybe there is a better way
thanks
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by kamiseq <ka...@gmail.com>.
fair enough ;]
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by kamiseq <ka...@gmail.com>.
;] 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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
On 28 November 2011 12:47, vineet semwal <vi...@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 <mg...@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
> > <vi...@gmail.com> wrote:
> >> public final <C> IConverter<C> getConverter(Class<C> clazz)
> >> {
> >> if (Date.class.isAssignableFrom(clazz))
> >> {
> >> return (IConverter<C>)converter; // cast
> >> }
> >> else
> >> {
> >> return super.getConverter(clazz);
> >> }
> >> }
> >>
> >> On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov <mg...@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
> >>> <vi...@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 <mg...@apache.org> wrote:
> >>>>> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
> >>>>> FormComponent<T> with IConverter<T> 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
> >>>>>>
> >>>>>> kamiseq@gmail.com
> >>>>>> pkaminski.prv@gmail.com
> >>>>>> ______________________
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
> >>>>>>>> well yeah this is exactly the same except for locator.
> >>>>>>>>
> >>>>>>>> code like this
> >>>>>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
> >>>>>>>> {
> >>>>>>>> if (Date.class.isAssignableFrom(clazz))
> >>>>>>>> {
> >>>>>>>> return (IConverter<C>)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
> >>>>>>>>
> >>>>>>>> kamiseq@gmail.com
> >>>>>>>> pkaminski.prv@gmail.com
> >>>>>>>> ______________________
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Martin Grigorov
> >>>>>>> jWeekend
> >>>>>>> Training, Consulting, Development
> >>>>>>> http://jWeekend.com
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Martin Grigorov
> >>>>> jWeekend
> >>>>> Training, Consulting, Development
> >>>>> http://jWeekend.com
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> thank you,
> >>>>
> >>>> regards,
> >>>> Vineet Semwal
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Martin Grigorov
> >>> jWeekend
> >>> Training, Consulting, Development
> >>> http://jWeekend.com
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> thank you,
> >>
> >> regards,
> >> Vineet Semwal
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
>
> --
> thank you,
>
> regards,
> Vineet Semwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by vineet semwal <vi...@gmail.com>.
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 <mg...@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
> <vi...@gmail.com> wrote:
>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>> {
>> if (Date.class.isAssignableFrom(clazz))
>> {
>> return (IConverter<C>)converter; // cast
>> }
>> else
>> {
>> return super.getConverter(clazz);
>> }
>> }
>>
>> On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov <mg...@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
>>> <vi...@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 <mg...@apache.org> wrote:
>>>>> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
>>>>> FormComponent<T> with IConverter<T> 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
>>>>>>
>>>>>> kamiseq@gmail.com
>>>>>> pkaminski.prv@gmail.com
>>>>>> ______________________
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>>>>>>> well yeah this is exactly the same except for locator.
>>>>>>>>
>>>>>>>> code like this
>>>>>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>>>>>>> {
>>>>>>>> if (Date.class.isAssignableFrom(clazz))
>>>>>>>> {
>>>>>>>> return (IConverter<C>)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
>>>>>>>>
>>>>>>>> kamiseq@gmail.com
>>>>>>>> pkaminski.prv@gmail.com
>>>>>>>> ______________________
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Martin Grigorov
>>>>>>> jWeekend
>>>>>>> Training, Consulting, Development
>>>>>>> http://jWeekend.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> thank you,
>>>>
>>>> regards,
>>>> Vineet Semwal
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> thank you,
>>
>> regards,
>> Vineet Semwal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by Martin Grigorov <mg...@apache.org>.
:-)
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
<vi...@gmail.com> wrote:
> public final <C> IConverter<C> getConverter(Class<C> clazz)
> {
> if (Date.class.isAssignableFrom(clazz))
> {
> return (IConverter<C>)converter; // cast
> }
> else
> {
> return super.getConverter(clazz);
> }
> }
>
> On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov <mg...@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
>> <vi...@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 <mg...@apache.org> wrote:
>>>> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
>>>> FormComponent<T> with IConverter<T> 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
>>>>>
>>>>> kamiseq@gmail.com
>>>>> pkaminski.prv@gmail.com
>>>>> ______________________
>>>>>
>>>>>
>>>>>
>>>>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>>>>>> well yeah this is exactly the same except for locator.
>>>>>>>
>>>>>>> code like this
>>>>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>>>>>> {
>>>>>>> if (Date.class.isAssignableFrom(clazz))
>>>>>>> {
>>>>>>> return (IConverter<C>)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
>>>>>>>
>>>>>>> kamiseq@gmail.com
>>>>>>> pkaminski.prv@gmail.com
>>>>>>> ______________________
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Grigorov
>>>>>> jWeekend
>>>>>> Training, Consulting, Development
>>>>>> http://jWeekend.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> thank you,
>>>
>>> regards,
>>> Vineet Semwal
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> thank you,
>
> regards,
> Vineet Semwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by vineet semwal <vi...@gmail.com>.
public final <C> IConverter<C> getConverter(Class<C> clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverter<C>)converter; // cast
}
else
{
return super.getConverter(clazz);
}
}
On Mon, Nov 28, 2011 at 1:24 PM, Martin Grigorov <mg...@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
> <vi...@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 <mg...@apache.org> wrote:
>>> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
>>> FormComponent<T> with IConverter<T> 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
>>>>
>>>> kamiseq@gmail.com
>>>> pkaminski.prv@gmail.com
>>>> ______________________
>>>>
>>>>
>>>>
>>>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>>>>> Hi,
>>>>>
>>>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>>>>> well yeah this is exactly the same except for locator.
>>>>>>
>>>>>> code like this
>>>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>>>>> {
>>>>>> if (Date.class.isAssignableFrom(clazz))
>>>>>> {
>>>>>> return (IConverter<C>)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
>>>>>>
>>>>>> kamiseq@gmail.com
>>>>>> pkaminski.prv@gmail.com
>>>>>> ______________________
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Grigorov
>>>>> jWeekend
>>>>> Training, Consulting, Development
>>>>> http://jWeekend.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> thank you,
>>
>> regards,
>> Vineet Semwal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by Martin Grigorov <mg...@apache.org>.
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
<vi...@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 <mg...@apache.org> wrote:
>> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
>> FormComponent<T> with IConverter<T> 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
>>>
>>> kamiseq@gmail.com
>>> pkaminski.prv@gmail.com
>>> ______________________
>>>
>>>
>>>
>>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>>>> Hi,
>>>>
>>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>>>> well yeah this is exactly the same except for locator.
>>>>>
>>>>> code like this
>>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>>>> {
>>>>> if (Date.class.isAssignableFrom(clazz))
>>>>> {
>>>>> return (IConverter<C>)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
>>>>>
>>>>> kamiseq@gmail.com
>>>>> pkaminski.prv@gmail.com
>>>>> ______________________
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> thank you,
>
> regards,
> Vineet Semwal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by vineet semwal <vi...@gmail.com>.
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 <mg...@apache.org> wrote:
> On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
> FormComponent<T> with IConverter<T> 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
>>
>> kamiseq@gmail.com
>> pkaminski.prv@gmail.com
>> ______________________
>>
>>
>>
>> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>>> Hi,
>>>
>>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>>> well yeah this is exactly the same except for locator.
>>>>
>>>> code like this
>>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>>> {
>>>> if (Date.class.isAssignableFrom(clazz))
>>>> {
>>>> return (IConverter<C>)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
>>>>
>>>> kamiseq@gmail.com
>>>> pkaminski.prv@gmail.com
>>>> ______________________
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by Martin Grigorov <mg...@apache.org>.
On Sun, Nov 27, 2011 at 4:11 PM, kamiseq <ka...@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
FormComponent<T> with IConverter<T> 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
>
> kamiseq@gmail.com
> pkaminski.prv@gmail.com
> ______________________
>
>
>
> On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>>> well yeah this is exactly the same except for locator.
>>>
>>> code like this
>>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>>> {
>>> if (Date.class.isAssignableFrom(clazz))
>>> {
>>> return (IConverter<C>)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
>>>
>>> kamiseq@gmail.com
>>> pkaminski.prv@gmail.com
>>> ______________________
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by kamiseq <ka...@gmail.com>.
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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
On 27 November 2011 15:55, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
>> well yeah this is exactly the same except for locator.
>>
>> code like this
>> public final <C> IConverter<C> getConverter(Class<C> clazz)
>> {
>> if (Date.class.isAssignableFrom(clazz))
>> {
>> return (IConverter<C>)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
>>
>> kamiseq@gmail.com
>> pkaminski.prv@gmail.com
>> ______________________
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sun, Nov 27, 2011 at 3:52 PM, kamiseq <ka...@gmail.com> wrote:
> well yeah this is exactly the same except for locator.
>
> code like this
> public final <C> IConverter<C> getConverter(Class<C> clazz)
> {
> if (Date.class.isAssignableFrom(clazz))
> {
> return (IConverter<C>)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
>
> kamiseq@gmail.com
> pkaminski.prv@gmail.com
> ______________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by kamiseq <ka...@gmail.com>.
well yeah this is exactly the same except for locator.
code like this
public final <C> IConverter<C> getConverter(Class<C> clazz)
{
if (Date.class.isAssignableFrom(clazz))
{
return (IConverter<C>)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
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by kamiseq <ka...@gmail.com>.
something like that, my google didnt show any result for getConverter 1.5 ;]
I will read that, thanks
pozdrawiam
Paweł Kamiński
kamiseq@gmail.com
pkaminski.prv@gmail.com
______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket migrating getConverter to 1.5
Posted by vineet semwal <vi...@gmail.com>.
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 <ka...@gmail.com> wrote:
> hi all,
> In 1.5 getConverter has new signature using generics : public <C>
> IConverter<C> getConverter(Class<C> 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 Link<L>
> {
> public Link(String id, IModel<L> model)
> {
> super(id, model);
> }
>
> @Override
> public IConverter<L> 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 IConverter<String>()
> {
> @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> IConverter<C>
> set(final Class<C> c, final IConverter<C> converter).
>
> how you deal with this things? maybe there is a better way
> thanks
>
> pozdrawiam
> Paweł Kamiński
>
> kamiseq@gmail.com
> pkaminski.prv@gmail.com
> ______________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
thank you,
regards,
Vineet Semwal
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org