Re: append a converter or coversion function
no, upper case string is not a special type, not unless you do not
use String to represent it...like i said, my suggestion is to do this
via a model decorator. further, something like this doesnt even sound
like it belongs in the web layer - sounds like a business requirement
which should be enforced by the setter of the bussiness pojo.
-igor
On Sun, Mar 9, 2008 at 7:57 PM, [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
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
I'd consider it a generic business component that applies
to so many apps/business pojos that would justify it to become a web component,
much like RequiredTextField or even PasswordTextField.
Could you illustrate how to do it better with model decorator
to use it like using RequiredTextField?
no, upper case string is not a special type, not unless you do not
use String to represent it...like i said, my suggestion is to do this
via a model decorator. further, something like this doesnt even sound
like it belongs in the web layer - sounds like a business requirement
which should be enforced by the setter of the bussiness pojo.
-igor
On Sun, Mar 9, 2008 at 7:57 PM, [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]
Re: append a converter or coversion function
We do call it
you only have to specify the type
And if the type can be resolved and is NOT String.class your converter is
called
The only issue is if we cant resolve the type or the type is String then we
do by default something else
You have to set the type yourself then then your converter is called
On Mon, Mar 10, 2008 at 11:25 AM, [EMAIL PROTECTED] wrote:
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,
Re: append a converter or coversion function
On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i thought we agreed converters were type converters... Did we? :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: append a converter or coversion function
yes, since the converter interface now has convertToObject(String value); convertToString(Object value); not just a single convertTo(Object object, Class type) it makes it rather explicit that the converter is meant to convert something to a string and back...no? -igor On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i thought we agreed converters were type converters... Did we? :-) Eelco - 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]
Re: append a converter or coversion function
On Mon, Mar 10, 2008 at 11:37 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: yes, since the converter interface now has convertToObject(String value); convertToString(Object value); not just a single convertTo(Object object, Class type) it makes it rather explicit that the converter is meant to convert something to a string and back...no? It does. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: append a converter or coversion function
But why cant converToObject(String) not return a string??
Thats up to the developer.
So
textfield = new TextField()
{
getConverter(Class clz)
{
}
}
textfield.setType(String.class)
that should work fine (and it does if i am not mistaken)
johan
On Mon, Mar 10, 2008 at 7:37 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
yes, since the converter interface now has
convertToObject(String value);
convertToString(Object value);
not just a single convertTo(Object object, Class type)
it makes it rather explicit that the converter is meant to convert
something to a string and back...no?
-igor
On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i thought we agreed converters were type converters...
Did we? :-)
Eelco
-
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]
Re: append a converter or coversion function
sure, it works. but it seems rather silly that a String type converter
is invoked to convert what already is a String to a String - seems
like a noop to me
-igor
On Mon, Mar 10, 2008 at 1:39 PM, Johan Compagner [EMAIL PROTECTED] wrote:
But why cant converToObject(String) not return a string??
Thats up to the developer.
So
textfield = new TextField()
{
getConverter(Class clz)
{
}
}
textfield.setType(String.class)
that should work fine (and it does if i am not mistaken)
johan
On Mon, Mar 10, 2008 at 7:37 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
yes, since the converter interface now has
convertToObject(String value);
convertToString(Object value);
not just a single convertTo(Object object, Class type)
it makes it rather explicit that the converter is meant to convert
something to a string and back...no?
-igor
On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i thought we agreed converters were type converters...
Did we? :-)
Eelco
-
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]
Re: append a converter or coversion function
Yes, but the issue I encountered that wicket first call getConverter method, yet not using what was returned as supposed to be. Class based converter is a way to write one default converter for one class, but if a special converter is provided for a subset of that class, then the special convert should be used yes, since the converter interface now has convertToObject(String value); convertToString(Object value); not just a single convertTo(Object object, Class type) it makes it rather explicit that the converter is meant to convert something to a string and back...no? -igor On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i thought we agreed converters were type converters... Did we? :-) Eelco - 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]
Re: append a converter or coversion function
Another level of indirection?
for compoundpropertymode Could I could do
add(new textfield(foo).setModel(new uppercasingmodel(this))) ?
if this is the webpage with the foo field.
Compared to
add(new UpperCaseTextfield(foo));
the latter would be more efficient and clean.
class uppercasingmodel implements imodel {
private final imodel delegate;
public void setobject(object) {
delegate.setobject(uppercase((string)object));
}
...
}
add(new textfield(foo, new uppercasingmodel(model)));
-igor
On Mon, Mar 10, 2008 at 3:31 AM, [EMAIL PROTECTED] wrote:
I'd consider it a generic business component that applies
to so many apps/business pojos that would justify it to become a web
component,
much like RequiredTextField or even PasswordTextField.
Could you illustrate how to do it better with model decorator
to use it like using RequiredTextField?
no, upper case string is not a special type, not unless you do not
use String to represent it...like i said, my suggestion is to do this
via a model decorator. further, something like this doesnt even sound
like it belongs in the web layer - sounds like a business requirement
which should be enforced by the setter of the bussiness pojo.
-igor
On Sun, Mar 9, 2008 at 7:57 PM, [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
Re: append a converter or coversion function
yes i think i explained that before the first call you see is the getConverter call that calls objectToString() on it but if type is not set on a field getConverter is not called for StringToObject johan On Mon, Mar 10, 2008 at 11:44 PM, [EMAIL PROTECTED] wrote: Yes, but the issue I encountered that wicket first call getConverter method, yet not using what was returned as supposed to be. Class based converter is a way to write one default converter for one class, but if a special converter is provided for a subset of that class, then the special convert should be used yes, since the converter interface now has convertToObject(String value); convertToString(Object value); not just a single convertTo(Object object, Class type) it makes it rather explicit that the converter is meant to convert something to a string and back...no? -igor On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i thought we agreed converters were type converters... Did we? :-) Eelco - 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]
Re: append a converter or coversion function
I missed this one. That explains what I just posted. I'd say the logic could be if a converter is provided, the its stringtoobject is called. otherwise, check the set type and use the types'registered converter. yes i think i explained that before the first call you see is the getConverter call that calls objectToString() on it but if type is not set on a field getConverter is not called for StringToObject johan On Mon, Mar 10, 2008 at 11:44 PM, [EMAIL PROTECTED] wrote: Yes, but the issue I encountered that wicket first call getConverter method, yet not using what was returned as supposed to be. Class based converter is a way to write one default converter for one class, but if a special converter is provided for a subset of that class, then the special convert should be used yes, since the converter interface now has convertToObject(String value); convertToString(Object value); not just a single convertTo(Object object, Class type) it makes it rather explicit that the converter is meant to convert something to a string and back...no? -igor On Mon, Mar 10, 2008 at 11:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Sun, Mar 9, 2008 at 9:45 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i thought we agreed converters were type converters... Did we? :-) Eelco - 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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
Thanks. I will give a try, although I wish there would be something like
component.add(IPostConverteToObject or IPostConverttoString) that would
not require subclass and also allow easy reuse of what is available.
A related question, after conversion is done, Can I do something like below
class MyTextField extend TextField{
@Override
setModel(model){
MySpeicalProcessing(model) // after this model object is changed to what I
want
super.setModel(model)
}
}
The javadoc said it
WARNING: DO NOT OVERRIDE THIS METHOD UNLESS YOU HAVE A VERY GOOD REASON FOR IT.
OVERRIDING THIS MIGHT OPEN UP SECURITY LEAKS AND BREAK BACK-BUTTON SUPPORT.
Also, would wicket gurantee that after the conversion, it would only call
setModel(model) instead of being able to use other means to update the model
value
such as setModelObject. If allowed, then the above method could fail
mysteriously.
Thanks
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]
Re: append a converter or coversion function
Such a method would waste memory space. The current way is fine to
chain converters you could do this globally if you want
SetModel is only called by you when you construct it. Not when the dat
is set from the browser the setModelObject is called or
getModel().setObject()
On 3/9/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Thanks. I will give a try, although I wish there would be something like
component.add(IPostConverteToObject or IPostConverttoString) that would
not require subclass and also allow easy reuse of what is available.
A related question, after conversion is done, Can I do something like below
class MyTextField extend TextField{
@Override
setModel(model){
MySpeicalProcessing(model) // after this model object is changed to
what I want
super.setModel(model)
}
}
The javadoc said it
WARNING: DO NOT OVERRIDE THIS METHOD UNLESS YOU HAVE A VERY GOOD REASON FOR
IT. OVERRIDING THIS MIGHT OPEN UP SECURITY LEAKS AND BREAK BACK-BUTTON
SUPPORT.
Also, would wicket gurantee that after the conversion, it would only call
setModel(model) instead of being able to use other means to update the
model value
such as setModelObject. If allowed, then the above method could fail
mysteriously.
Thanks
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
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]
Re: append a converter or coversion function
i think a model decorator is more appropriate here -igor On Sat, Mar 8, 2008 at 3:10 PM, [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]
Re: append a converter or coversion function
I could use both model or onSubmit to do what I mentioned. But this resulted in repeating coding. If I put the special conversion code in converter, it would be handily reusable by me or others without worring about the convertion logic for each model or form. Validator chaining is the example of what I meant i think a model decorator is more appropriate here -igor On Sat, Mar 8, 2008 at 3:10 PM, [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]
Re: append a converter or coversion function
a model decorator would not result in any repeated code -igor On Sat, Mar 8, 2008 at 4:30 PM, [EMAIL PROTECTED] wrote: I could use both model or onSubmit to do what I mentioned. But this resulted in repeating coding. If I put the special conversion code in converter, it would be handily reusable by me or others without worring about the convertion logic for each model or form. Validator chaining is the example of what I meant i think a model decorator is more appropriate here -igor On Sat, Mar 8, 2008 at 3:10 PM, [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]
