Just had a discussion/ brain storm session about the whole conversion
business with Jonathan. We have a few new idea's of solving this both
generally (like Maurice wants) and easy (like everyone wants). When
we've progressed more tonight or tomorrow, I'll check back with this
list about the proposed changes.
Eelco
Jonathan Carlson wrote:
I agree. Having the scope limited helps make it more intuitive
and prevents some usage mistakes. If it becomes necessary, you can
widen the scope to Object later without breaking anybody's existing code.
My 2 cents,
Jonathan
>>> [EMAIL PROTECTED] 2005-02-02 1:08:48 PM >>>
I prefer the Strings methods, as this would keep things easy and clear.
Also, I really though hard the last couple of hours of use cases (not
hacks) where having these methods with Objects instead of Strings would
be an advantage, but couln't think of one.
Eelco
Maurice Marrink wrote:
>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.
>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 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