History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: XSTR-211
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Joe Walnes
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
XStream

Generic fromStringConverter()

Created: 03/Apr/05 06:36 AM   Updated: 07/Aug/06 09:27 PM
Component/s: None
Affects Version/s: None
Fix Version/s: 1.2

File Attachments: 1. Text File FromStringConverterPatch.patch (291 kb)
2. Text File FromStringConverterPatch2.patch (291 kb)
3. Text File patch.txt (10 kb)
4. Text File patch.txt (8 kb)



 Description  « Hide
--- Suggested by Mark Helmstetter ---

A converter that provides functionality such
that if an object has a method such as "public Object fromString(String str)". It
seems that such a converter could be very valuable to avoid writing a special
converter for lots of relatively simple objects that require special handling that
the packaged converters don't address.

--- Additional notes by Joe ---

I think this is a good idea.

An interface could be introduced for this that objects can implement if they want to be handled by the converter:

package com.thoughtworks.xstream;

public interface StringSerializable {
  String toString(); // implicit from Object anyway, but in the interface for clarity
  void fromString(String string);
}

Any objects implementing this method would also require a default constructor - similar to the contract of java.io.Externalizable.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Mark Helmstetter - 04/Apr/05 11:55 PM
Joe,

I took a crack at this, let me know what you think.

I'm thinking that it's really not necessary to impose constraints that classes must implement a particular interface to take advantage of the FromStringConverter, and that they have a public default constructor. Feel free to disagree... :-)

I've used Spring's BeanUtils as a helper here, that could potentially be factored out, but I don't see any harm in including it. I think the same can be easily applied to the BeanConverter, and this should solve the Applet security issue as well.

Mark Helmstetter - 05/Apr/05 12:09 AM
Please ignore the first patch

Guilherme Silveira - 10/Mar/06 12:42 PM
here is a simple patch with 3 changes and 3 new classes: the interface, the converter class, the test case

now here is the conversion order:

1. field conversion overriding
2. implements interface overriding
3. converter lookup

we can change it, just decide one order and change the lookup process... (but any choice will have its pro/cons)

Guilherme Silveira - 10/Mar/06 12:45 PM
this is the real one...

Guilherme Silveira - 10/Mar/06 01:45 PM
another way is to implement a converter... tried but did not get it right at first.

Joerg Schaible - 16/Mar/06 06:31 PM
This is implemented now with the SingleValueConverter. Please have a look at the version in the repository and report back, if it covers your expectation.