;] 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> 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
> >>
> >>
> >
> >
> >
> > --
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
