i think it would need class because getConverter itself needs class gettype() resolves class from the class name afaik ..
On Mon, Sep 5, 2011 at 5:17 PM, Fabio Cechinel Veronez <[email protected]> wrote: > why getFCConverter would need a Class as parameter? > > I mean, FormComponent whould be already known whether by getType or by > T type... wouldn't it? > > > > On Mon, Sep 5, 2011 at 8:24 AM, vineet semwal > <[email protected]> wrote: >> In FormComponent class >> >> /** >> * subclasses would override it instead of getConverter(Class) >> so no cast is necessary >> */ >> public IConverter<T> getFCConverter(Class<T>type) >> { >> // -- returns converter for FormComponent's type >> return super.getConverter(type); >> } >> >> >> @Override >> public <C> IConverter<C> getConverter(Class<C> type) { >> Class<T> c = (Class<T>) type; >> IConverter<C> converter = (IConverter<C>) getFCConverter(type); >> return converter; >> } >> >> >> >> i have only made some small changes here without using IDE so there >> can be silly errors ,let me know if you think it shouldnt >> be done this way or there is something wrong in code.. >> >> also i think its very late for 1.5 at least .. >> >> thank you ! >> >> On Mon, Sep 5, 2011 at 6:48 AM, Fabio Cechinel Veronez >> <[email protected]> wrote: >>> do you mean something like ( in FormComponent class or one subclass ) : >>> >>> .... >>> /** >>> * subclasses would override it instead of getConverter(Class) >>> so no cast is necessary >>> */ >>> protected IConverter<T> getConverter() >>> { >>> // -- returns converter for FormComponent's type >>> return super.getConverter(getType()); >>> } >>> >>> @Override >>> public final <C> IConverter<C> getConverter(Class<C> type) >>> { >>> Class<T> fcType = getType(); >>> // -- if type is a superclass of form component's type them >>> use its >>> converter... otherwise uses default one >>> if (fcType != null && type.isAssignableFrom(fcType)) >>> { >>> @SuppressWarnings("unchecked") >>> IConverter<C> converter = >>> (IConverter<C>)getConverter(); >>> return converter; >>> } >>> else >>> { >>> return super.getConverter(type); >>> } >>> } >>> .... >>> ?? >>> >>> On Mon, Aug 15, 2011 at 1:27 PM, vineet semwal >>> <[email protected]> wrote: >>>> The real problem is that Component has no generics. >>>> i agree with that so type parameter has to be used on the method >>>> currently unless a new method is added in the FormComponent ,the older >>>> method can just call the new method based on some conditional logic so >>>> nothings get broken in core..,the users will just have to override the >>>> new method but yeah i agree not very important .. >>>> >>>> thanks for the discussion in IRC too ! ;) >>>> >>>> >>>> On Mon, Aug 15, 2011 at 8:56 PM, Martin Grigorov <[email protected]> >>>> wrote: >>>>> The real problem is that Component has no generics. >>>>> The tradeoff is that the library (FormComponents) do cast but all >>>>> users of them benefit without seeing this casting >>>>> >>>>> On Mon, Aug 15, 2011 at 6:21 PM, vineet semwal >>>>> <[email protected]> wrote: >>>>>> the signature of method is public final <C> IConverter<C> >>>>>> getConverter(Class<C> clazz) ; >>>>>> >>>>>> public IConverter<String> getConverter(Class<String> type) >>>>>> ^^ means not overriding correctly as method signature is not the same >>>>>> >>>>>> public <String> IConverter<String>getConverter(Class<String> type) >>>>>> now you have declared <String> as your type parameter but you will >>>>>> not be able to use String as class in method now as the >>>>>> declared <String> will now hide the String java data type.. >>>>>> >>>>>> martin has already told you the way,currently casting appears to be >>>>>> the only way.. >>>>>> >>>>>> On Mon, Aug 15, 2011 at 5:35 PM, Fabio Cechinel Veronez >>>>>> <[email protected]> wrote: >>>>>>> Sorry for previews post, wrong combinations of pressed keys =/ >>>>>>> >>>>>>> I, will continue: >>>>>>> >>>>>>> Hello everybody, >>>>>>> >>>>>>> I'm using wicket 1.5-RC5.1 and I'm having problem to override >>>>>>> getConverter method of in a FormCompont subclass. >>>>>>> >>>>>>> Well, lets say I have a TextField<Date> (I'm using j.u.Date here just >>>>>>> as example, could be any type) when I try to to provide a specific >>>>>>> converter for my instance I'm implementing like that: >>>>>>> >>>>>>> TextField<String> tf = new TextField<String>("id") { >>>>>>> >>>>>>> @Override >>>>>>> public IConverter<String> getConverter(Class<String> type) { >>>>>>> // ... >>>>>>> return converter; >>>>>>> } >>>>>>> }; >>>>>>> >>>>>>> But if I do like I get a compiler error saying: >>>>>>> >>>>>>> "Name clash: The method getConverter(Class<String>) of type new >>>>>>> TextField<String>(){} has the same erasure as getConverter(Class<C>) >>>>>>> of type Component but does not override it" >>>>>>> "The method getConverter(Class<String>) of type new >>>>>>> TextField<String>(){} must override or implement a supertype method" >>>>>>> >>>>>>> And when I try >>>>>>> >>>>>>> TextField<String> tf = new TextField<String>("id") { >>>>>>> >>>>>>> @Override >>>>>>> public <String> IConverter<String> >>>>>>> getConverter(Class<String> type) { >>>>>>> // ... >>>>>>> return converter; >>>>>>> } >>>>>>> }; >>>>>>> >>>>>>> I get a compilation warn saying: >>>>>>> >>>>>>> "The type parameter String is hiding the type String" >>>>>>> >>>>>>> >>>>>>> I guess it happens 'cause getConverter uses a generic type C defined >>>>>>> at method level that is not the same generic type T defined at >>>>>>> TextField class level. >>>>>>> >>>>>>> What is the proper way to overwrite getConverter method? >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 15, 2011 at 8:57 AM, Fabio Cechinel Veronez >>>>>>> <[email protected]> wrote: >>>>>>>> Hello everybody, >>>>>>>> >>>>>>>> I'm using wicket 1.5-RC5.1 and I'm having problem to override >>>>>>>> getConverter method of in a FormCompont subclass. >>>>>>>> >>>>>>>> Well, lets say I have a TextField<Date> (I'm using j.u.Date here just >>>>>>>> as example, could be any type) when I try to to provide a specific >>>>>>>> converter for my instance I >>>>>>>> >>>>>>>> -- >>>>>>>> Fabio Cechinel Veronez >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Fabio Cechinel Veronez >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> thank you, >>>>>> >>>>>> regards, >>>>>> Vineet Semwal >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Martin Grigorov >>>>> jWeekend >>>>> Training, Consulting, Development >>>>> http://jWeekend.com >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> thank you, >>>> >>>> regards, >>>> Vineet Semwal >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> >>> -- >>> Fabio Cechinel Veronez >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> >> -- >> thank you, >> >> regards, >> Vineet Semwal >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > -- > Fabio Cechinel Veronez > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- thank you, regards, Vineet Semwal --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
