You could resolve the type because a converted is already registered
for that type. I could make a special class called UpperCaseString
and register a converter and new TextField( . UpperCaseString.class).
>From this perspective, if I override getConverter to provide my own,
wicket should use it directly instead of infer the type and what to do
since I have give a definite converter. As I had observed,
the custom getConverter was actually called, so all that takes
is to call its methods instead of using builtin rules. The provider
of the custom converter would be responsible for the outcome.
>A converter is only called when type is set for converting from string
>to object. Maybe we should document this a bit better.
>
>The type is tried to be resolved for you, but if it is a string then
>it is ignored so that normal convert() processing happens. This is a
>bit weird but dont know how we can make this easier
>
>On 3/10/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I used the trick it worked great. Thanks very much.
>> Should it be considered a bug?
>> What is interesting before using setType is that getConverter is actually
>> called (from my simple tracing), but after that its methods were
>> not called (I guess somewhere it learned the modelobject was a String so
>> it simply call the built-in converter.
>> I'd think if the getConverter is overriden, its methods should be called
>> regardless of what type was it. Besides, UppercaseString is
>> a special "Type" so it does not conflict with the rules.
>> (Any custom converter could be considered to target a special type
>> even though it could be just uppercasing or prepend a * to the string)
>> Built-in converter might follow the default rules but
>> if custom converter is provided, wicket should totally depend
>> on the custom converter to do whatever it does.
>>
>> Anyway, thanks again.
>>
>> >if you set the type yourself by hand then getConverter() will be called
>and
>> >you can do what ever you want
>> >We dont do that automatic yes (resolveType doesn't set it to the
>> >String.class)
>> >
>> >johan
>> >
>> >
>> >
>> >On Sun, Mar 9, 2008 at 5:45 PM, Igor Vaynberg <[EMAIL PROTECTED]>
>> >wrote:
>> >
>> >> i thought we agreed converters were type converters...so they shouldnt
>> >> be invoked if you are doing string->string :|
>> >>
>> >> -igor
>> >>
>> >>
>> >> On Sun, Mar 9, 2008 at 5:47 AM, Johan Compagner <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > call setTYpe(String.class) on the textfield
>> >> > or use that constructor with the type param
>> >> >
>> >> > does that help?
>> >> >
>> >> >
>> >> >
>> >> > On Sun, Mar 9, 2008 at 1:35 PM, <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > > Below is a custom component with overrding the getConverter
>> >> > > for testing purpose. As you could see, it is plain simple one
>> >> > > with simple output debugging. But it is not working.
>> >> > > the getConverter is called (output "here")
>> >> > > but the convertToObject never called (no "there")
>> >> > > I basically cut and paste the WicketinAction example.
>> >> > > What I am doing wrong here?
>> >> > >
>> >> > >
>> >> > > public class RequiredUppperCaseTextField extends TextField {
>> >> > >
>> >> > > public RequiredUppperCaseTextField(String id) {
>> >> > > super(id);
>> >> > > setRequired(true);
>> >> > >
>> >> > > }
>> >> > > @Override
>> >> > > public final IConverter getConverter(Class arg000){
>> >> > > System.out.println("here"+ arg0);
>> >> > > IConverter icAppend = new IConverter(){
>> >> > >
>> >> > > public Object convertToObject(String arg0, Locale arg1)
>{
>> >> > > System.out.println("there"+ arg0);
>> >> > > String s = "sss";
>> >> > > return s;
>> >> > > }
>> >> > >
>> >> > > public String convertToString(Object arg0, Locale arg1)
>{
>> >> > > return (String)arg0;
>> >> > > }
>> >> > >
>> >> > > };
>> >> > > return icAppend;
>> >> > > }
>> >> > >
>> >> > > }
>> >> > >
>> >> > >
>> >> > > >Override the getConverter() method. First call super and with that
>> >> > > >result call the special one (camel casing?)
>> >> > > >
>> >> > > >On 3/9/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >> > > >> Hello:
>> >> > > >> I wonder how to "append" a converter or java method to a
>> component
>> >> so
>> >> > > that
>> >> > > >I
>> >> > > >> would affect what is already defined. For example, I want
>> >> "camelize" a
>> >> > > >> TextField(or some customized subclass) so that after the
>> converter
>> >> > > already
>> >> > > >> defined completes the conversion (regardless what has been done
>> in
>> >> the
>> >> > > >> chain) , I could use the added converted/method to make the
>final
>> >> > > >conversion
>> >> > > >> to my need. The example I am seeing appears to "overide" and
>only
>> >> one
>> >> > > can
>> >> > > >be
>> >> > > >> defined for a component, unlike validators, that I could add a
>> >> chain of
>> >> > > >> them. Let me know if I am wrong about this.
>> >> > > >> Thanks
>> >> > > >
>> >> > >
>> >> >---------------------------------------------------------------------
>> >> > > >To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > > >For additional commands, e-mail: [EMAIL PROTECTED]
>> >> > > >
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> >> > >
>> >> > >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
