You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ofbiz.apache.org by do...@apache.org on 2010/02/10 23:48:07 UTC
svn commit: r908713 - in
/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Author: doogie
Date: Wed Feb 10 22:48:07 2010
New Revision: 908713
URL: http://svn.apache.org/viewvc?rev=908713&view=rev
Log:
Switch the collection/string converters to the json parser.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
Modified: ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java?rev=908713&r1=908712&r2=908713&view=diff
==============================================================================
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java (original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java Wed Feb 10 22:48:07 2010
@@ -18,13 +18,17 @@
*******************************************************************************/
package org.ofbiz.base.conversion;
+import java.io.IOException;
+import java.io.StringReader;
+import java.io.StringWriter;
import java.util.Arrays;
import java.util.List;
import java.util.Map;
import java.util.Set;
import org.ofbiz.base.util.ObjectType;
-import org.ofbiz.base.util.StringUtil;
+import org.ofbiz.base.json.JSON;
+import org.ofbiz.base.json.JSONWriter;
import javolution.util.FastList;
import javolution.util.FastSet;
@@ -52,7 +56,13 @@
}
public String convert(List<T> obj) throws ConversionException {
- return obj.toString();
+ StringWriter sw = new StringWriter();
+ try {
+ new JSONWriter(sw).write(obj);
+ } catch (IOException e) {
+ throw new ConversionException(e);
+ }
+ return sw.toString();
}
}
@@ -86,51 +96,62 @@
}
public String convert(Map<K, V> obj) throws ConversionException {
- return obj.toString();
+ StringWriter sw = new StringWriter();
+ try {
+ new JSONWriter(sw).write(obj);
+ } catch (IOException e) {
+ throw new ConversionException(e);
+ }
+ return sw.toString();
}
}
- public static class StringToList extends AbstractConverter<String, List<String>> {
+ public static class StringToList extends AbstractConverter<String, List<Object>> {
public StringToList() {
super(String.class, List.class);
}
- public List<String> convert(String obj) throws ConversionException {
- if (obj.startsWith("[") && obj.endsWith("]")) {
- return StringUtil.toList(obj);
- } else {
- List<String> tempList = FastList.newInstance();
- tempList.add(obj);
- return tempList;
+ public List<Object> convert(String obj) throws ConversionException {
+ try {
+ return new JSON(new StringReader(obj)).JSONArray();
+ } catch (RuntimeException e) {
+ throw e;
+ } catch (Exception e) {
+ throw new ConversionException(e);
}
}
}
- public static class StringToMap extends AbstractConverter<String, Map<String, String>> {
+ public static class StringToMap extends AbstractConverter<String, Map<String, Object>> {
public StringToMap() {
super(String.class, Map.class);
}
- public Map<String, String> convert(String obj) throws ConversionException {
- if (obj.startsWith("{") && obj.endsWith("}")) {
- return StringUtil.toMap(obj);
+ public Map<String, Object> convert(String obj) throws ConversionException {
+ try {
+ return new JSON(new StringReader(obj)).JSONObject();
+ } catch (RuntimeException e) {
+ throw e;
+ } catch (Exception e) {
+ throw new ConversionException(e);
}
- throw new ConversionException("Could not convert " + obj + " to Map: ");
}
}
- public static class StringToSet extends AbstractConverter<String, Set<String>> {
+ public static class StringToSet extends AbstractConverter<String, Set<Object>> {
public StringToSet() {
super(String.class, Set.class);
}
- public Set<String> convert(String obj) throws ConversionException {
- if (obj.startsWith("[") && obj.endsWith("]")) {
- return StringUtil.toSet(obj);
- } else {
- Set<String> tempSet = FastSet.newInstance();
- tempSet.add(obj);
- return tempSet;
+ public Set<Object> convert(String obj) throws ConversionException {
+ try {
+ Set<Object> set = FastSet.newInstance();
+ set.addAll(new JSON(new StringReader(obj)).JSONArray());
+ return set;
+ } catch (RuntimeException e) {
+ throw e;
+ } catch (Exception e) {
+ throw new ConversionException(e);
}
}
}
Modified: ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java?rev=908713&r1=908712&r2=908713&view=diff
==============================================================================
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java (original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java Wed Feb 10 22:48:07 2010
@@ -47,7 +47,7 @@
public void testExtendsImplements() throws Exception {
List<String> arraysList = Arrays.asList("a", "b", "c");
Converter converter = Converters.getConverter(arraysList.getClass(), String.class);
- assertEquals("", "[a, b, c]", converter.convert(arraysList));
+ assertEquals("", "[\n \"a\",\n \"b\",\n \"c\"\n]", converter.convert(arraysList));
Exception caught = null;
try {
Converters.getConverter(MiscTests.class, String.class);
@@ -59,7 +59,7 @@
LRUMap<String, String> map = new LRUMap<String, String>();
map.put("a", "1");
converter = Converters.getConverter(LRUMap.class, String.class);
- assertEquals("", "{a=1}", converter.convert(map));
+ assertEquals("", "{\n \"a\": \"1\"\n}", converter.convert(map));
}
public void testPassthru() throws Exception {
Re: svn commit: r908713 - in
/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by David E Jones <de...@me.com>.
On Feb 10, 2010, at 11:53 PM, Adam Heath wrote:
> Adrian Crum wrote:
>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
>>> From: Adam Heath <do...@brainfood.com>
>>> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
>>> To: dev@ofbiz.apache.org
>>> Date: Wednesday, February 10, 2010, 9:19 PM
>>> Adrian Crum wrote:
>>>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
>>> wrote:
>>>>> From: Adam Heath <do...@brainfood.com>
>>>>> Subject: Re: svn commit: r908713 - in
>>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>>> CollectionConverters.java test/MiscTests.java
>>>>> To: dev@ofbiz.apache.org
>>>>> 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.
>>
>> Nope, we need separate converters:
>>
>> <set field="listAsJsonString" from-field="someList" type="JsonString"/>
>> <set field="listAsXmlString" from-field="someList" type="XmlString"/>
>> <set field="listAsFooString" from-field="someList" type="FooString"/>
>
> Stop thinking top level.
>
> (borrowing json syntax)
>
> {"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
>
> In your example, "someList" is equal to the above example object. But
> then the method that is doing the encoding(JsonString, XmlString,
> FooString) will *itself* call *back* into Converters, asking for a
> conversion for the embed String keys, the embeded list, and the
> embedded map. Then, for the list and map, they too will have to again
> call into Converters, asking for each number and String to be encoded.
>
> What I am suggesting is getting rid of the else if block in
> JSONWriter, *and* the hard-coded xml serialization stuff, and just
> making that *all* use Converters as it's registry.
>
> Hmm, I was going to write more here, but then I realized something
> else. While keeping the above 2 paragraphs is useful, what I am about
> to suggest is an even more radical approach.
>
> If the supposed xml converter existed, how would it actually function?
> Would it have each nested object get converted to a *string*, then
> parse that string back into DOM, and append it to the current
> document? Of course not. So, the next way to do that might be to
> have a FooToElement type converter. This is better. However, each
> FooToElement converter would end up creating a dummy document, just to
> create the singleton element that would be representing of it's data.
> So, maybe we need to be able to pass down a 'context' variable, in
> this specific case, a 'node', to which the converter can attach it's
> element.
>
> This would also work well for JSON output, because the IndentingWriter
> class could be the context variable that is passed to child converters.
>
> Even doing a normal FooToString converter could make use of this, by
> passing a StringBuilder around.
Keep in mind that Adrian's goal is to do all conversions through polymorphism.
Whether or not that's the best approach is another question (I obviously don't agree, or I would have written in that way in the first place, or rewritten it that way, or at least responded to Adrian's commits with a high-five email). Of course, I'm not convinced I'm always right, so I'll let Adrian have his fun with this one and see how it goes... either way I hope he "finishes" it soon so we can get rid of certain error messages that didn't used to be there and such.
-David
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 2/13/10, Adrian Crum <ad...@yahoo.com> wrote:
> I'm working on the same concept here only with XML. I'm
> created an XML class that represents and XML object. If you
> want an XML string, you call XML.toString(). If you want a
> DOM object, you call XML.toDOM(). If you want to deserialize
> an object, you call XML.toObject().
Ack. I really should proofread before clicking Send.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Sat, 2/13/10, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
> To: dev@ofbiz.apache.org
> Date: Saturday, February 13, 2010, 10:26 PM
> Adrian Crum wrote:
> > --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> wrote:
> >> From: Adam Heath <do...@brainfood.com>
> >> Subject: Re: svn commit: r908713 - in
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> CollectionConverters.java test/MiscTests.java
> >> To: dev@ofbiz.apache.org
> >> Date: Wednesday, February 10, 2010, 9:53 PM
> >> Adrian Crum wrote:
> >>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> >> wrote:
> >>>> From: Adam Heath <do...@brainfood.com>
> >>>> Subject: Re: svn commit: r908713 - in
> >>
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> >> CollectionConverters.java test/MiscTests.java
> >>>> To: dev@ofbiz.apache.org
> >>>> Date: Wednesday, February 10, 2010, 9:19
> PM
> >>>> Adrian Crum wrote:
> >>>>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> >>>> wrote:
> >>>>>> From: Adam Heath <do...@brainfood.com>
> >>>>>> Subject: Re: svn commit: r908713 -
> in
> >>
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> >>>> CollectionConverters.java
> test/MiscTests.java
> >>>>>> To: dev@ofbiz.apache.org
> >>>>>> 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.
> >>> Nope, we need separate converters:
> >>>
> >>> <set field="listAsJsonString"
> from-field="someList"
> >> type="JsonString"/>
> >>> <set field="listAsXmlString"
> from-field="someList"
> >> type="XmlString"/>
> >>> <set field="listAsFooString"
> from-field="someList"
> >> type="FooString"/>
> >>
> >> Stop thinking top level.
> >
> > I call it "Imagine the possibilities..."
> >
> >> (borrowing json syntax)
> >>
> >> {"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
> >>
> >> In your example, "someList" is equal to the above
> example
> >> object. But
> >> then the method that is doing the
> encoding(JsonString,
> >> XmlString,
> >> FooString) will *itself* call *back* into
> Converters,
> >> asking for a
> >> conversion for the embed String keys, the embeded
> list, and
> >> the
> >> embedded map. Then, for the list and map,
> they too
> >> will have to again
> >> call into Converters, asking for each number and
> String to
> >> be encoded.
> >>
> >> What I am suggesting is getting rid of the else if
> block
> >> in
> >> JSONWriter, *and* the hard-coded xml serialization
> stuff,
> >> and just
> >> making that *all* use Converters as it's
> registry.
> >>
> >> Hmm, I was going to write more here, but then I
> realized
> >> something
> >> else. While keeping the above 2 paragraphs
> is useful,
> >> what I am about
> >> to suggest is an even more radical approach.
> >>
> >> If the supposed xml converter existed, how would
> it
> >> actually function?
> >
> > Probably by using an existing Java object to XML
> conversion library.
> >
> >> Would it have each nested object get
> converted to a
> >> *string*, then
> >> parse that string back into DOM, and append it to
> the
> >> current
> >> document? Of course not. So, the next
> way to do
> >> that might be to
> >> have a FooToElement type converter. This is
> >> better. However, each
> >> FooToElement converter would end up creating a
> dummy
> >> document, just to
> >> create the singleton element that would be
> representing of
> >> it's data.
> >> So, maybe we need to be able to pass down a
> 'context'
> >> variable, in
> >> this specific case, a 'node', to which the
> converter can
> >> attach it's
> >> element.
> >>
> >> This would also work well for JSON output, because
> the
> >> IndentingWriter
> >> class could be the context variable that is passed
> to child
> >> converters.
> >
> > If it was me I would design a JsonString class that
> hides all of those implementation details from the
> conversion framework. I try to avoid feature envy.
>
> Hmm, I've just done this locally. I've changed the
> ListToString and
> MapToString converters back to calling toString.
>
> I finally decided to do this, when I noticed exceptions in
> a test run;
> they didn't fail the test, as the code just ended up
> falling back into
> ObjectType, but it didn't sit well with me.
>
> I still need to do a JSONString->Foo converter, but at
> least I'm happy
> with this, and it's what you suggested.
>
> Currently, I have 15 separate patches queued, mostly all
> going to the
> conversion system, almost all ready to go, implementing
> what we have
> discussesd the pass 2 days. All while maintaining 13
> other patches
> from the commons-vfs/cow stuff, that I am importing from
> webslinger.
I'm working on the same concept here only with XML. I'm created an XML class that represents and XML object. If you want an XML string, you call XML.toString(). If you want a DOM object, you call XML.toDOM(). If you want to deserialize an object, you call XML.toObject().
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
>> From: Adam Heath <do...@brainfood.com>
>> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
>> To: dev@ofbiz.apache.org
>> Date: Wednesday, February 10, 2010, 9:53 PM
>> Adrian Crum wrote:
>>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
>> wrote:
>>>> From: Adam Heath <do...@brainfood.com>
>>>> Subject: Re: svn commit: r908713 - in
>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>> CollectionConverters.java test/MiscTests.java
>>>> To: dev@ofbiz.apache.org
>>>> Date: Wednesday, February 10, 2010, 9:19 PM
>>>> Adrian Crum wrote:
>>>>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
>>>> wrote:
>>>>>> From: Adam Heath <do...@brainfood.com>
>>>>>> Subject: Re: svn commit: r908713 - in
>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>>>> CollectionConverters.java test/MiscTests.java
>>>>>> To: dev@ofbiz.apache.org
>>>>>> 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.
>>> Nope, we need separate converters:
>>>
>>> <set field="listAsJsonString" from-field="someList"
>> type="JsonString"/>
>>> <set field="listAsXmlString" from-field="someList"
>> type="XmlString"/>
>>> <set field="listAsFooString" from-field="someList"
>> type="FooString"/>
>>
>> Stop thinking top level.
>
> I call it "Imagine the possibilities..."
>
>> (borrowing json syntax)
>>
>> {"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
>>
>> In your example, "someList" is equal to the above example
>> object. But
>> then the method that is doing the encoding(JsonString,
>> XmlString,
>> FooString) will *itself* call *back* into Converters,
>> asking for a
>> conversion for the embed String keys, the embeded list, and
>> the
>> embedded map. Then, for the list and map, they too
>> will have to again
>> call into Converters, asking for each number and String to
>> be encoded.
>>
>> What I am suggesting is getting rid of the else if block
>> in
>> JSONWriter, *and* the hard-coded xml serialization stuff,
>> and just
>> making that *all* use Converters as it's registry.
>>
>> Hmm, I was going to write more here, but then I realized
>> something
>> else. While keeping the above 2 paragraphs is useful,
>> what I am about
>> to suggest is an even more radical approach.
>>
>> If the supposed xml converter existed, how would it
>> actually function?
>
> Probably by using an existing Java object to XML conversion library.
>
>> Would it have each nested object get converted to a
>> *string*, then
>> parse that string back into DOM, and append it to the
>> current
>> document? Of course not. So, the next way to do
>> that might be to
>> have a FooToElement type converter. This is
>> better. However, each
>> FooToElement converter would end up creating a dummy
>> document, just to
>> create the singleton element that would be representing of
>> it's data.
>> So, maybe we need to be able to pass down a 'context'
>> variable, in
>> this specific case, a 'node', to which the converter can
>> attach it's
>> element.
>>
>> This would also work well for JSON output, because the
>> IndentingWriter
>> class could be the context variable that is passed to child
>> converters.
>
> If it was me I would design a JsonString class that hides all of those implementation details from the conversion framework. I try to avoid feature envy.
Hmm, I've just done this locally. I've changed the ListToString and
MapToString converters back to calling toString.
I finally decided to do this, when I noticed exceptions in a test run;
they didn't fail the test, as the code just ended up falling back into
ObjectType, but it didn't sit well with me.
I still need to do a JSONString->Foo converter, but at least I'm happy
with this, and it's what you suggested.
Currently, I have 15 separate patches queued, mostly all going to the
conversion system, almost all ready to go, implementing what we have
discussesd the pass 2 days. All while maintaining 13 other patches
from the commons-vfs/cow stuff, that I am importing from webslinger.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> Adam Heath wrote:
>> Adrian Crum wrote:
>>> Adrian Crum wrote:
>>>> Adam Heath wrote:
>>>>> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
>>>>> to implement. However, I still need to do my 'resolve' feature.
>>>>> Possibily an ObjectToJSONResolveString, or some such.
>>>>>
>>>>> And, I could get rid of the UtilIO.readObject stuff, by implementing
>>>>> an ObjectToFlatAttribute system.
>>>> When you were evaluating JSON libraries, did you take a look at
>>>> XStream?
>>>>
>>>> http://xstream.codehaus.org/index.html
>>
>> Maybe. Looking at it now, makes me not want to use it for JSON work,
>> as JSON has such limited raw object support. Plus, serializing the
>> internal state of objects is a bit icky, if the object knows there is
>> a more compact way to represent itself.
>>
>>> I just integrated that library into OFBiz and created List and Map
>>> to/from XMLString converters. It was pretty easy and they are
>>> reflective. The library also supports JSON.
>>
>> You did? I don't see a commit with any changes.
>
> I meant on my local copy. I didn't commit it because I don't want to
> interfere with what you're doing.
Don't you worry your pretty little head about that, little
grasshopper, I can deal with it.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@hlmksw.com>.
Adam Heath wrote:
> Adrian Crum wrote:
>> Adrian Crum wrote:
>>> Adam Heath wrote:
>>>> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
>>>> to implement. However, I still need to do my 'resolve' feature.
>>>> Possibily an ObjectToJSONResolveString, or some such.
>>>>
>>>> And, I could get rid of the UtilIO.readObject stuff, by implementing
>>>> an ObjectToFlatAttribute system.
>>> When you were evaluating JSON libraries, did you take a look at XStream?
>>>
>>> http://xstream.codehaus.org/index.html
>
> Maybe. Looking at it now, makes me not want to use it for JSON work,
> as JSON has such limited raw object support. Plus, serializing the
> internal state of objects is a bit icky, if the object knows there is
> a more compact way to represent itself.
>
>> I just integrated that library into OFBiz and created List and Map
>> to/from XMLString converters. It was pretty easy and they are
>> reflective. The library also supports JSON.
>
> You did? I don't see a commit with any changes.
I meant on my local copy. I didn't commit it because I don't want to
interfere with what you're doing.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> Adrian Crum wrote:
>> Adam Heath wrote:
>>> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
>>> to implement. However, I still need to do my 'resolve' feature.
>>> Possibily an ObjectToJSONResolveString, or some such.
>>>
>>> And, I could get rid of the UtilIO.readObject stuff, by implementing
>>> an ObjectToFlatAttribute system.
>>
>> When you were evaluating JSON libraries, did you take a look at XStream?
>>
>> http://xstream.codehaus.org/index.html
Maybe. Looking at it now, makes me not want to use it for JSON work,
as JSON has such limited raw object support. Plus, serializing the
internal state of objects is a bit icky, if the object knows there is
a more compact way to represent itself.
> I just integrated that library into OFBiz and created List and Map
> to/from XMLString converters. It was pretty easy and they are
> reflective. The library also supports JSON.
You did? I don't see a commit with any changes.
>
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@hlmksw.com>.
Adrian Crum wrote:
> Adam Heath wrote:
>> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
>> to implement. However, I still need to do my 'resolve' feature.
>> Possibily an ObjectToJSONResolveString, or some such.
>>
>> And, I could get rid of the UtilIO.readObject stuff, by implementing
>> an ObjectToFlatAttribute system.
>
> When you were evaluating JSON libraries, did you take a look at XStream?
>
> http://xstream.codehaus.org/index.html
I just integrated that library into OFBiz and created List and Map
to/from XMLString converters. It was pretty easy and they are
reflective. The library also supports JSON.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@hlmksw.com>.
Adam Heath wrote:
> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
> to implement. However, I still need to do my 'resolve' feature.
> Possibily an ObjectToJSONResolveString, or some such.
>
> And, I could get rid of the UtilIO.readObject stuff, by implementing
> an ObjectToFlatAttribute system.
When you were evaluating JSON libraries, did you take a look at XStream?
http://xstream.codehaus.org/index.html
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> Adam Heath wrote:
>> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
>> to implement. However, I still need to do my 'resolve' feature.
>> Possibily an ObjectToJSONResolveString, or some such.
>
> What does the resolve feature do?
>
JSON only supports String, booleans, numbers(Long or Double),
arrays(List), and object(Map).
The resolve feature extends that, by parsing this pattern:
resolve("java.net.URL:http:\/\/ofbiz.apache.org")
That becomes a raw token in the markup. It allows me to embed any
other object that has a String representation into a json output
string. I don't want to have to write separate ToJSONString
converters for *every* non-standard object, I'd like to have just one.
But, to do that, I have to be able to get a bi-directional string
representation of whatever object. Calling .toString in such cases
doesn't work(which is what your original ListToString converter did).
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@hlmksw.com>.
Adam Heath wrote:
> ObjectToJSONString, and JSONStringToObject, is fairly straight forward
> to implement. However, I still need to do my 'resolve' feature.
> Possibily an ObjectToJSONResolveString, or some such.
What does the resolve feature do?
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> [snip], it had gotten to large, and if anyone needs to refer
> back, they can check the list archives, or some such
>> Would it have each nested object get converted to a
>> *string*, then
>> parse that string back into DOM, and append it to the
>> current
>> document? Of course not. So, the next way to do
>> that might be to
>> have a FooToElement type converter. This is
>> better. However, each
>> FooToElement converter would end up creating a dummy
>> document, just to
>> create the singleton element that would be representing of
>> it's data.
>> So, maybe we need to be able to pass down a 'context'
>> variable, in
>> this specific case, a 'node', to which the converter can
>> attach it's
>> element.
>>
>> This would also work well for JSON output, because the
>> IndentingWriter
>> class could be the context variable that is passed to child
>> converters.
>
> If it was me I would design a JsonString class that hides all of those implementation details from the conversion framework. I try to avoid feature envy.
ObjectToJSONString, and JSONStringToObject, is fairly straight forward
to implement. However, I still need to do my 'resolve' feature.
Possibily an ObjectToJSONResolveString, or some such.
And, I could get rid of the UtilIO.readObject stuff, by implementing
an ObjectToFlatAttribute system.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
> To: dev@ofbiz.apache.org
> Date: Wednesday, February 10, 2010, 9:53 PM
> Adrian Crum wrote:
> > --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> wrote:
> >> From: Adam Heath <do...@brainfood.com>
> >> Subject: Re: svn commit: r908713 - in
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> CollectionConverters.java test/MiscTests.java
> >> To: dev@ofbiz.apache.org
> >> Date: Wednesday, February 10, 2010, 9:19 PM
> >> Adrian Crum wrote:
> >>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> >> wrote:
> >>>> From: Adam Heath <do...@brainfood.com>
> >>>> Subject: Re: svn commit: r908713 - in
> >>
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> >> CollectionConverters.java test/MiscTests.java
> >>>> To: dev@ofbiz.apache.org
> >>>> 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.
> >
> > Nope, we need separate converters:
> >
> > <set field="listAsJsonString" from-field="someList"
> type="JsonString"/>
> > <set field="listAsXmlString" from-field="someList"
> type="XmlString"/>
> > <set field="listAsFooString" from-field="someList"
> type="FooString"/>
>
> Stop thinking top level.
I call it "Imagine the possibilities..."
>
> (borrowing json syntax)
>
> {"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
>
> In your example, "someList" is equal to the above example
> object. But
> then the method that is doing the encoding(JsonString,
> XmlString,
> FooString) will *itself* call *back* into Converters,
> asking for a
> conversion for the embed String keys, the embeded list, and
> the
> embedded map. Then, for the list and map, they too
> will have to again
> call into Converters, asking for each number and String to
> be encoded.
>
> What I am suggesting is getting rid of the else if block
> in
> JSONWriter, *and* the hard-coded xml serialization stuff,
> and just
> making that *all* use Converters as it's registry.
>
> Hmm, I was going to write more here, but then I realized
> something
> else. While keeping the above 2 paragraphs is useful,
> what I am about
> to suggest is an even more radical approach.
>
> If the supposed xml converter existed, how would it
> actually function?
Probably by using an existing Java object to XML conversion library.
> Would it have each nested object get converted to a
> *string*, then
> parse that string back into DOM, and append it to the
> current
> document? Of course not. So, the next way to do
> that might be to
> have a FooToElement type converter. This is
> better. However, each
> FooToElement converter would end up creating a dummy
> document, just to
> create the singleton element that would be representing of
> it's data.
> So, maybe we need to be able to pass down a 'context'
> variable, in
> this specific case, a 'node', to which the converter can
> attach it's
> element.
>
> This would also work well for JSON output, because the
> IndentingWriter
> class could be the context variable that is passed to child
> converters.
If it was me I would design a JsonString class that hides all of those implementation details from the conversion framework. I try to avoid feature envy.
-Adrian
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
>> From: Adam Heath <do...@brainfood.com>
>> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
>> To: dev@ofbiz.apache.org
>> Date: Wednesday, February 10, 2010, 9:19 PM
>> Adrian Crum wrote:
>>> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
>> wrote:
>>>> From: Adam Heath <do...@brainfood.com>
>>>> Subject: Re: svn commit: r908713 - in
>> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
>> CollectionConverters.java test/MiscTests.java
>>>> To: dev@ofbiz.apache.org
>>>> 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.
>
> Nope, we need separate converters:
>
> <set field="listAsJsonString" from-field="someList" type="JsonString"/>
> <set field="listAsXmlString" from-field="someList" type="XmlString"/>
> <set field="listAsFooString" from-field="someList" type="FooString"/>
Stop thinking top level.
(borrowing json syntax)
{"numbers": [1, 2, 3, 4], "map": {"a": "b"}}
In your example, "someList" is equal to the above example object. But
then the method that is doing the encoding(JsonString, XmlString,
FooString) will *itself* call *back* into Converters, asking for a
conversion for the embed String keys, the embeded list, and the
embedded map. Then, for the list and map, they too will have to again
call into Converters, asking for each number and String to be encoded.
What I am suggesting is getting rid of the else if block in
JSONWriter, *and* the hard-coded xml serialization stuff, and just
making that *all* use Converters as it's registry.
Hmm, I was going to write more here, but then I realized something
else. While keeping the above 2 paragraphs is useful, what I am about
to suggest is an even more radical approach.
If the supposed xml converter existed, how would it actually function?
Would it have each nested object get converted to a *string*, then
parse that string back into DOM, and append it to the current
document? Of course not. So, the next way to do that might be to
have a FooToElement type converter. This is better. However, each
FooToElement converter would end up creating a dummy document, just to
create the singleton element that would be representing of it's data.
So, maybe we need to be able to pass down a 'context' variable, in
this specific case, a 'node', to which the converter can attach it's
element.
This would also work well for JSON output, because the IndentingWriter
class could be the context variable that is passed to child converters.
Even doing a normal FooToString converter could make use of this, by
passing a StringBuilder around.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
> To: dev@ofbiz.apache.org
> Date: Wednesday, February 10, 2010, 9:19 PM
> Adrian Crum wrote:
> > --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com>
> wrote:
> >> From: Adam Heath <do...@brainfood.com>
> >> Subject: Re: svn commit: r908713 - in
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
> CollectionConverters.java test/MiscTests.java
> >> To: dev@ofbiz.apache.org
> >> 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.
Nope, we need separate converters:
<set field="listAsJsonString" from-field="someList" type="JsonString"/>
<set field="listAsXmlString" from-field="someList" type="XmlString"/>
<set field="listAsFooString" from-field="someList" type="FooString"/>
-Adrian
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
Adrian Crum wrote:
> --- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
>> From: Adam Heath <do...@brainfood.com>
>> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
>> To: dev@ofbiz.apache.org
>> 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.
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
--- On Wed, 2/10/10, Adam Heath <do...@brainfood.com> wrote:
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
> To: dev@ofbiz.apache.org
> 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?
-Adrian
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion:
CollectionConverters.java test/MiscTests.java
Posted by Adam Heath <do...@brainfood.com>.
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. If I stuffed something else into the list,
ListToString would handle it, by calling toString on the object. But,
then, StringToList wouldn't handle it correctly. What if I put a
string into the original list that had a comma in it, or some other
special character?
I think the conversion framework should be conscise.
Another option is to have a non-static Converters registry; this way,
I could override some converters with a json compatible way. If you
so desire, I can do this.
>
>
> --- On Wed, 2/10/10, doogie@apache.org <do...@apache.org> wrote:
>
>> From: doogie@apache.org <do...@apache.org>
>> Subject: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
>> To: commits@ofbiz.apache.org
>> Date: Wednesday, February 10, 2010, 2:48 PM
>> Author: doogie
>> Date: Wed Feb 10 22:48:07 2010
>> New Revision: 908713
>>
>> URL: http://svn.apache.org/viewvc?rev=908713&view=rev
>> Log:
>> Switch the collection/string converters to the json
>> parser.
>>
>> Modified:
>>
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
>>
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
>>
>> Modified:
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java?rev=908713&r1=908712&r2=908713&view=diff
>> ==============================================================================
>> ---
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
>> (original)
>> +++
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
>> Wed Feb 10 22:48:07 2010
>> @@ -18,13 +18,17 @@
>>
>> *******************************************************************************/
>> package org.ofbiz.base.conversion;
>>
>> +import java.io.IOException;
>> +import java.io.StringReader;
>> +import java.io.StringWriter;
>> import java.util.Arrays;
>> import java.util.List;
>> import java.util.Map;
>> import java.util.Set;
>>
>> import org.ofbiz.base.util.ObjectType;
>> -import org.ofbiz.base.util.StringUtil;
>> +import org.ofbiz.base.json.JSON;
>> +import org.ofbiz.base.json.JSONWriter;
>>
>> import javolution.util.FastList;
>> import javolution.util.FastSet;
>> @@ -52,7 +56,13 @@
>> }
>>
>> public String
>> convert(List<T> obj) throws ConversionException {
>> - return
>> obj.toString();
>> + StringWriter sw
>> = new StringWriter();
>> + try {
>> +
>> new JSONWriter(sw).write(obj);
>> + } catch
>> (IOException e) {
>> +
>> throw new ConversionException(e);
>> + }
>> + return
>> sw.toString();
>> }
>> }
>>
>> @@ -86,51 +96,62 @@
>> }
>>
>> public String
>> convert(Map<K, V> obj) throws ConversionException {
>> - return
>> obj.toString();
>> + StringWriter sw
>> = new StringWriter();
>> + try {
>> +
>> new JSONWriter(sw).write(obj);
>> + } catch
>> (IOException e) {
>> +
>> throw new ConversionException(e);
>> + }
>> + return
>> sw.toString();
>> }
>> }
>>
>> - public static class StringToList extends
>> AbstractConverter<String, List<String>> {
>> + public static class StringToList extends
>> AbstractConverter<String, List<Object>> {
>> public
>> StringToList() {
>>
>> super(String.class, List.class);
>> }
>>
>> - public List<String>
>> convert(String obj) throws ConversionException {
>> - if
>> (obj.startsWith("[") && obj.endsWith("]")) {
>> -
>> return StringUtil.toList(obj);
>> - } else {
>> -
>> List<String> tempList = FastList.newInstance();
>> -
>> tempList.add(obj);
>> -
>> return tempList;
>> + public List<Object>
>> convert(String obj) throws ConversionException {
>> + try {
>> +
>> return new JSON(new StringReader(obj)).JSONArray();
>> + } catch
>> (RuntimeException e) {
>> +
>> throw e;
>> + } catch
>> (Exception e) {
>> +
>> throw new ConversionException(e);
>> }
>> }
>> }
>>
>> - public static class StringToMap extends
>> AbstractConverter<String, Map<String, String>>
>> {
>> + public static class StringToMap extends
>> AbstractConverter<String, Map<String, Object>>
>> {
>> public StringToMap()
>> {
>>
>> super(String.class, Map.class);
>> }
>>
>> - public Map<String,
>> String> convert(String obj) throws ConversionException {
>> - if
>> (obj.startsWith("{") && obj.endsWith("}")) {
>> -
>> return StringUtil.toMap(obj);
>> + public Map<String,
>> Object> convert(String obj) throws ConversionException {
>> + try {
>> +
>> return new JSON(new StringReader(obj)).JSONObject();
>> + } catch
>> (RuntimeException e) {
>> +
>> throw e;
>> + } catch
>> (Exception e) {
>> +
>> throw new ConversionException(e);
>> }
>> - throw new
>> ConversionException("Could not convert " + obj + " to Map:
>> ");
>> }
>> }
>>
>> - public static class StringToSet extends
>> AbstractConverter<String, Set<String>> {
>> + public static class StringToSet extends
>> AbstractConverter<String, Set<Object>> {
>> public StringToSet()
>> {
>>
>> super(String.class, Set.class);
>> }
>>
>> - public Set<String>
>> convert(String obj) throws ConversionException {
>> - if
>> (obj.startsWith("[") && obj.endsWith("]")) {
>> -
>> return StringUtil.toSet(obj);
>> - } else {
>> -
>> Set<String> tempSet = FastSet.newInstance();
>> -
>> tempSet.add(obj);
>> -
>> return tempSet;
>> + public Set<Object>
>> convert(String obj) throws ConversionException {
>> + try {
>> +
>> Set<Object> set = FastSet.newInstance();
>> +
>> set.addAll(new JSON(new StringReader(obj)).JSONArray());
>> +
>> return set;
>> + } catch
>> (RuntimeException e) {
>> +
>> throw e;
>> + } catch
>> (Exception e) {
>> +
>> throw new ConversionException(e);
>> }
>> }
>> }
>>
>> Modified:
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java?rev=908713&r1=908712&r2=908713&view=diff
>> ==============================================================================
>> ---
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
>> (original)
>> +++
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
>> Wed Feb 10 22:48:07 2010
>> @@ -47,7 +47,7 @@
>> public void
>> testExtendsImplements() throws Exception {
>> List<String>
>> arraysList = Arrays.asList("a", "b", "c");
>> Converter converter
>> = Converters.getConverter(arraysList.getClass(),
>> String.class);
>> - assertEquals("", "[a, b, c]",
>> converter.convert(arraysList));
>> + assertEquals("", "[\n \"a\",\n
>> \"b\",\n \"c\"\n]", converter.convert(arraysList));
>> Exception caught =
>> null;
>> try {
>>
>> Converters.getConverter(MiscTests.class,
>> String.class);
>> @@ -59,7 +59,7 @@
>> LRUMap<String,
>> String> map = new LRUMap<String, String>();
>> map.put("a", "1");
>> converter =
>> Converters.getConverter(LRUMap.class, String.class);
>> - assertEquals("", "{a=1}",
>> converter.convert(map));
>> + assertEquals("", "{\n \"a\":
>> \"1\"\n}", converter.convert(map));
>> }
>>
>> public void testPassthru() throws
>> Exception {
>>
>>
>>
>
>
>
Re: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
Posted by Adrian Crum <ad...@yahoo.com>.
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
--- On Wed, 2/10/10, doogie@apache.org <do...@apache.org> wrote:
> From: doogie@apache.org <do...@apache.org>
> Subject: svn commit: r908713 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion: CollectionConverters.java test/MiscTests.java
> To: commits@ofbiz.apache.org
> Date: Wednesday, February 10, 2010, 2:48 PM
> Author: doogie
> Date: Wed Feb 10 22:48:07 2010
> New Revision: 908713
>
> URL: http://svn.apache.org/viewvc?rev=908713&view=rev
> Log:
> Switch the collection/string converters to the json
> parser.
>
> Modified:
>
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
>
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
>
> Modified:
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java?rev=908713&r1=908712&r2=908713&view=diff
> ==============================================================================
> ---
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
> (original)
> +++
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/CollectionConverters.java
> Wed Feb 10 22:48:07 2010
> @@ -18,13 +18,17 @@
>
> *******************************************************************************/
> package org.ofbiz.base.conversion;
>
> +import java.io.IOException;
> +import java.io.StringReader;
> +import java.io.StringWriter;
> import java.util.Arrays;
> import java.util.List;
> import java.util.Map;
> import java.util.Set;
>
> import org.ofbiz.base.util.ObjectType;
> -import org.ofbiz.base.util.StringUtil;
> +import org.ofbiz.base.json.JSON;
> +import org.ofbiz.base.json.JSONWriter;
>
> import javolution.util.FastList;
> import javolution.util.FastSet;
> @@ -52,7 +56,13 @@
> }
>
> public String
> convert(List<T> obj) throws ConversionException {
> - return
> obj.toString();
> + StringWriter sw
> = new StringWriter();
> + try {
> +
> new JSONWriter(sw).write(obj);
> + } catch
> (IOException e) {
> +
> throw new ConversionException(e);
> + }
> + return
> sw.toString();
> }
> }
>
> @@ -86,51 +96,62 @@
> }
>
> public String
> convert(Map<K, V> obj) throws ConversionException {
> - return
> obj.toString();
> + StringWriter sw
> = new StringWriter();
> + try {
> +
> new JSONWriter(sw).write(obj);
> + } catch
> (IOException e) {
> +
> throw new ConversionException(e);
> + }
> + return
> sw.toString();
> }
> }
>
> - public static class StringToList extends
> AbstractConverter<String, List<String>> {
> + public static class StringToList extends
> AbstractConverter<String, List<Object>> {
> public
> StringToList() {
>
> super(String.class, List.class);
> }
>
> - public List<String>
> convert(String obj) throws ConversionException {
> - if
> (obj.startsWith("[") && obj.endsWith("]")) {
> -
> return StringUtil.toList(obj);
> - } else {
> -
> List<String> tempList = FastList.newInstance();
> -
> tempList.add(obj);
> -
> return tempList;
> + public List<Object>
> convert(String obj) throws ConversionException {
> + try {
> +
> return new JSON(new StringReader(obj)).JSONArray();
> + } catch
> (RuntimeException e) {
> +
> throw e;
> + } catch
> (Exception e) {
> +
> throw new ConversionException(e);
> }
> }
> }
>
> - public static class StringToMap extends
> AbstractConverter<String, Map<String, String>>
> {
> + public static class StringToMap extends
> AbstractConverter<String, Map<String, Object>>
> {
> public StringToMap()
> {
>
> super(String.class, Map.class);
> }
>
> - public Map<String,
> String> convert(String obj) throws ConversionException {
> - if
> (obj.startsWith("{") && obj.endsWith("}")) {
> -
> return StringUtil.toMap(obj);
> + public Map<String,
> Object> convert(String obj) throws ConversionException {
> + try {
> +
> return new JSON(new StringReader(obj)).JSONObject();
> + } catch
> (RuntimeException e) {
> +
> throw e;
> + } catch
> (Exception e) {
> +
> throw new ConversionException(e);
> }
> - throw new
> ConversionException("Could not convert " + obj + " to Map:
> ");
> }
> }
>
> - public static class StringToSet extends
> AbstractConverter<String, Set<String>> {
> + public static class StringToSet extends
> AbstractConverter<String, Set<Object>> {
> public StringToSet()
> {
>
> super(String.class, Set.class);
> }
>
> - public Set<String>
> convert(String obj) throws ConversionException {
> - if
> (obj.startsWith("[") && obj.endsWith("]")) {
> -
> return StringUtil.toSet(obj);
> - } else {
> -
> Set<String> tempSet = FastSet.newInstance();
> -
> tempSet.add(obj);
> -
> return tempSet;
> + public Set<Object>
> convert(String obj) throws ConversionException {
> + try {
> +
> Set<Object> set = FastSet.newInstance();
> +
> set.addAll(new JSON(new StringReader(obj)).JSONArray());
> +
> return set;
> + } catch
> (RuntimeException e) {
> +
> throw e;
> + } catch
> (Exception e) {
> +
> throw new ConversionException(e);
> }
> }
> }
>
> Modified:
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java?rev=908713&r1=908712&r2=908713&view=diff
> ==============================================================================
> ---
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
> (original)
> +++
> ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/test/MiscTests.java
> Wed Feb 10 22:48:07 2010
> @@ -47,7 +47,7 @@
> public void
> testExtendsImplements() throws Exception {
> List<String>
> arraysList = Arrays.asList("a", "b", "c");
> Converter converter
> = Converters.getConverter(arraysList.getClass(),
> String.class);
> - assertEquals("", "[a, b, c]",
> converter.convert(arraysList));
> + assertEquals("", "[\n \"a\",\n
> \"b\",\n \"c\"\n]", converter.convert(arraysList));
> Exception caught =
> null;
> try {
>
> Converters.getConverter(MiscTests.class,
> String.class);
> @@ -59,7 +59,7 @@
> LRUMap<String,
> String> map = new LRUMap<String, String>();
> map.put("a", "1");
> converter =
> Converters.getConverter(LRUMap.class, String.class);
> - assertEquals("", "{a=1}",
> converter.convert(map));
> + assertEquals("", "{\n \"a\":
> \"1\"\n}", converter.convert(map));
> }
>
> public void testPassthru() throws
> Exception {
>
>
>