Adrian Crum wrote: > --- On Wed, 2/10/10, Adam Heath <[email protected]> wrote: >> From: Adam Heath <[email protected]> >> Subject: Re: svn commit: r908713 - in >> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: >> CollectionConverters.java test/MiscTests.java >> To: [email protected] >> Date: Wednesday, February 10, 2010, 7:05 PM >> Adrian Crum wrote: >>> Every programmer has their own design style. This >> would be mine: >>> class JsonString { >>> public String toString() { >>> ... >>> } >>> } >>> >>> public static class ListToJsonString<T> extends >> AbstractConverter<List<T>, JsonString> { >>> public ListToJsonString() { >>> super(List.class, JsonString >> .class); >>> } >>> ... >>> } >>> >>> The problem I have with your approach is the fact that >> there is no way to know that converting object x to a String >> will result in a JSON string. In addition, I was hoping we >> could stick to this pattern: Converting any Java type to a >> String is the same as calling the object's toString() >> method. >>> -Adrian >> Yeah, I thought you would comment on this. >> >> Should ListToString and StringToList be reflective? >> As they used to >> be, they weren't. > > That's a good question. The original List conversions were copied from the > ObjectType code and I never looked into that code in detail - I just wanted > to maintain the original behavior. > > When I picture java types being converted to strings, I imagine them being > displayed - kind of like how they would appear if you did something like: > > String prompt = "The List is: " + someList; > > Making the converters reflective is a worthwhile goal - I just never > considered it. > > What you're trying to accomplish is great. We can take that concept even > further by having type x to XML converters - so that java objects can be > serialized to XML. > > So, that's why I commented on it. What if I wanted to convert a List to an > XML string? Or a [insert encoding method here] string?
Here's a summary of what you have said, and what I have been thinking: 1: I've got an object, I want to convert it for display. This could call to string, or something else, maybe multiple converters in series. 2: I want to change the format of an object; an object is nothing without the data it encapsulates, and there are different ways of encapsulating said data. So, converting a List<Map> to JSON, still ends up carrying the exact same set of data. This is simliar to serialization, but hopefully allows for a human to edit the converted state. 3: JSON kinda has a hard-coded registry; it can only handle very simple basic types. If it was made to use a large registry of converters, it would need to have the basic types use the internal json, but then all other types use the resolve() syntax. 4: XML output is similiar to JSON, but there are no intrinsic types, so there doesn't have to be any special casing. What this is saying to me, is we need a third parameter to this conversion framework; first is source class, second is target class, and third would be maybe 'flavor' or 'method'. Method as in request.METHOD, or output method, or some such.
