RE: [Wicket-user] is this approach correct?
Nice, just one little suggestion:
Change
Object getAsObject(ConversionContext ctx, String value)
To
Object getAsObject(ConversionContext ctx, Object value)
You will still need a null check for value in your implementation, so
why not combine that with a little more generic code like
If(value instanceof String){...}else if(value instanceof
Object){...}else return null;
Maybe you will never need the Object, but if you do you will be sorry if
you only got a string to work with.
Just my 2 cents.
Maurice
-Oorspronkelijk bericht-
Van: Eelco Hillenius
Verzonden: woensdag 2 februari 2005 11:37
Aan: wicket-user@lists.sourceforge.net
Onderwerp: Re: [Wicket-user] is this approach correct?
No, what I meant is that the converters were initially copied (and
slightly altered) from the BeanUtils package. As they lacked the
possibility of formatting (BeanUtils uses one-way converters only), I
added support for formatting whilst not breaking the compatibility with
BeanUtils by adding an optional interface for formatting. Now, this was
for Baritus/ Maverick. For a large part I copied that into Wicket, as it
was one of the things in Baritus that allways functioned well. However,
for Wicket it would be best to have a clearer interface, thus having -
just like JSF - converters for both ways.
This is the JSF interface:
public interface Converter
{
Object getAsObject(FacesContext context,
UIComponent component,
String value) throws ConverterException;
String getAsString(FacesContext context,
UIComponent component,
Object value) throws ConverterException;
}
Which is tightly coupled to JSF. Furthermore, I think (by doing a quick
code scan of MyFaces) that locales are not supported in JSF as well as
we support it.
Currently in Wicket, these are the interfaces:
public interface IConverter
{
public Object convert(Object value);
}
and
public interface IFormatter
{
public String format(Object value, String pattern);
}
Now, that I have a closer look to it, I think the pattern should be
omitted, and the interface should look like:
public interface IConverter
{
Object getAsObject(String value) throws ConversionException;
String getAsString(Object value) throws ConversionException;
}
However, I know from experience that use of a pattern can be very
convenient, I am have never been very happy with the way localization is
implemented (which is again a legacy issue as I copied that from
BeanUtils.
There are several ways to tackle this. I think the most elegant - and
future safe - option is to introduce a context object, like:
public interface IConverter
{
Object getAsObject(ConversionContext ctx, String value) throws
ConversionException;
String getAsString(ConversionContext ctx, Object value) throws
ConversionException;
}
Where ConversionContext would at least have a reference to the optional
locale object to use (note that besides the user's locale, this can be
explicitly set in the PropertyModel) and the optional conversion
pattern. I think if the API looked like this, the writing of custom
converters would be much simpler/ clearer and the lookup process would
be drastically simplified and thus more transparent to our framework
users.
What do you think?
Eelco
Juergen Donnerstag wrote:
So, as that's a legacy thing
now, we could just as well loose the difference.
Sorry, it is probably only my english. Our current implementation
isn't better nore worse than what JSF (and may be others) offer. And
because there are standard packages out there to that job, the idea
is to move towards this package. Correct?
Juergen
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc
Re: [Wicket-user] is this approach correct?
Yep. That's the nicest way to do it. You probably want to use this setting (false by default): settings.setPropertyModelDefaultApplyFormatting(true); as then the converting works both ways. If you take a look at the forminput example (CVS HEAD), you'll see: TextField dateInput = new TextField(dateInput, input, dateProperty); dateInput.add(new TypeValidator(Date.class)); where the input object has property 'dateProperty' of type java.util.Date. Because I added a type converter, before any model update, the type is checked first using the registered type converter. If that validates, the actual converting will be done using again that registered converter by the property model. That's how I use most forms. A form has a target object, say a person object. For the properties I want to have edited, I create input fields with property models so the converting and updating go semi-automatic. In form submit, all I have to do is to update/ save my altered object. Furthermore, when you use a framework like Hibernate or a JDO variant, it is probably sensible to work with detachable models a lot. Take a look the stuff that's in contrib for making this easier. Eelco Jonathan Carlson wrote: I want to have a text form field that converts to a Date attribute on a bean (using the -MM-DD string format). It looks like I would create a DateConverter implementation of IConverter and register it with the ConverterRepository so that the PropertyModel instance can convert it appropriately. Is that the right approach for both directions (String to Date, and Date to String)? - Jonathan ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. www.katun.com ** --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] is this approach correct?
Ooops: 'Because I added a type converter, ...' should have been: 'Because I added a TypeValidator, ...'. Eelco Eelco Hillenius wrote: Yep. That's the nicest way to do it. You probably want to use this setting (false by default): settings.setPropertyModelDefaultApplyFormatting(true); as then the converting works both ways. If you take a look at the forminput example (CVS HEAD), you'll see: TextField dateInput = new TextField(dateInput, input, dateProperty); dateInput.add(new TypeValidator(Date.class)); where the input object has property 'dateProperty' of type java.util.Date. Because I added a type converter, before any model update, the type is checked first using the registered type converter. If that validates, the actual converting will be done using again that registered converter by the property model. That's how I use most forms. A form has a target object, say a person object. For the properties I want to have edited, I create input fields with property models so the converting and updating go semi-automatic. In form submit, all I have to do is to update/ save my altered object. Furthermore, when you use a framework like Hibernate or a JDO variant, it is probably sensible to work with detachable models a lot. Take a look the stuff that's in contrib for making this easier. Eelco Jonathan Carlson wrote: I want to have a text form field that converts to a Date attribute on a bean (using the -MM-DD string format). It looks like I would create a DateConverter implementation of IConverter and register it with the ConverterRepository so that the PropertyModel instance can convert it appropriately. Is that the right approach for both directions (String to Date, and Date to String)? - Jonathan ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. www.katun.com ** --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] is this approach correct?
Thanks Eelco. It was not clear to me that a Formatter is the opposite
of a Converter but your infohelps.
I wonder if this could all be more intuitive. My first reaction is
thatit might be less confusing if Converters did both directions and
theFormatter concept went away. Maybe IConverter could have
#toString(Object o) and #toObject(String s) methods. Converters that only
need to go one direction could just No-Op the method they don't need.
It looks like I should use DateLocaleConverter (with '-MM-DD' as the
pattern and no Locale) because that's an IFormatter as well. This too
seems like it could bemore intuitive.
Do I have a valid point? I won't be hurt if you tell me that I don't
know what I'm talking about. :-)
- Jonathan
[EMAIL PROTECTED] 2005-02-01 3:33:01 PM
Ooops: 'Because I added a type converter, ...' should have been:
'Because I added a TypeValidator, ...'.EelcoEelco
Hillenius wrote: Yep. That's the nicest way to do
it. You probably want to use this setting (false by
default):
settings.setPropertyModelDefaultApplyFormatting(true); as then
the converting works both ways. If you take a look at the
forminput example (CVS HEAD), you'll
see:
TextField dateInput = new TextField("dateInput", input,
"dateProperty");
dateInput.add(new TypeValidator(Date.class)); where the input
object has property 'dateProperty' of type java.util.Date. Because I
added a type converter, before any model update, the type is checked
first using the registered type converter. If that validates, the
actual converting will be done using again that registered converter by
the property model. That's how I use most forms. A form has a
target object, say a person object. For the properties I want to have
edited, I create input fields with property models so the converting
and updating go semi-automatic. In form submit, all I have to do is to
update/ save my altered object. Furthermore, when you
use a framework like Hibernate or a JDO variant, it is probably
sensible to work with detachable models a lot. Take a look the stuff
that's in contrib for making this easier.
Eelco Jonathan Carlson wrote: I want
to have a text form field that converts to a Date attribute on a
bean (using the -MM-DD string format). It
looks like I would create a DateConverter implementation of
IConverter and register it with the ConverterRepository so that the
PropertyModel instance can convert it appropriately. Is that
the right approach for both directions (String to Date, and Date to
String)? -
Jonathan
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify the system manager. www.katun.com
**
--- This SF.Net
email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for
open source databases. Create drag--drop reports. Save time by over
75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download
a FREE copy at http://www.intelliview.com/go/osdn_nl
___ Wicket-user mailing
list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user---This
SF.Net email is sponsored by: IntelliVIEW -- Interactive ReportingTool for
open source databases. Create drag--drop reports. Save timeby over 75%!
Publish reports on the web. Export to DOC, XLS, RTF, etc.Download a FREE
copy at http://www.intelliview.com/go/osdn_nl___Wicket-user
mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
