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 <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
>>> 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
>>>>
>>>> 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> 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
>>>>>>
>>>>>> 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
