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]
