Add Map support to RequestFactory

Add Map support to RequestFactory (Issue 5524)

I tested it with a simple requestfactory web app in the same eclipse workspace.

[james.horsley, 2012-05-01 22:54:26]

Thomas, I put you as the reviewer as I believe bobv, whose name was on the
issue, is no longer on the GWT team and I'd noticed you're very well versed in
requestfactory based on your community activity. Please let me know if I should
add/change reviewers.

Thanks!

[t.broyer, 2012-05-02 13:59:05]

Adding Rajeev as a reviewer.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java
(right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java:86:
DeclaredType asCollection =
Rename to asMap ?

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File src/com/google/web/bindery/requestfactory/server/Resolver.java (right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/server/Resolver.java:505:
accumulator.put(resolveDomainValue(entry.getKey(), detectDeadEntities),
resolveDomainValue(entry.getValue(), detectDeadEntities));
Line too long.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/server/Resolver.java:702:
accumulator.put(resolveClientValue(entry.getKey(),entryTypes[0]).getClientObject(),
resolveClientValue(entry.getValue(),entryTypes[1]).getClientObject());
Line too long.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
(right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:
if (ctx instanceof MapPropertyContext && ((MapPropertyContext)ctx).getKeyType()
!= null) {
Why is this null-check necessary? (or useful)

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
(right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:25:
import com.google.web.bindery.autobean.vm.impl.TypeUtils;
We're in 'shared', so we can't use 'vm' here (unless there's a super-source
version of the class, which is not the case here).

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:29:
import java.nio.charset.CoderMalfunctionError;
We're in 'shared' and java.nio is not emulated (and EntityCodex has no
super-source version)

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135: if
(ValueCodex.canDecode(keyType)) {
So, if the key is a "value type", serialization would use a JSON object; and
otherwise it'd use two lists?

Can't we have a single serialization for maps? And how about a list of key-value
pairs rather than a pair of lists (list of keys and list of values)?
Or wouldn't it be easier to simply restrict keys to value types? (like AutoBean
does already)

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:141:
Object key = ValueCodex.decode(keyType, StringQuoter.create(propertyKey));
StringQuoter.create() always creates a String Splittable (isString() == true,
asString() != null), so ValueCodex won't be able to decode booleans, numbers or
enums.

=> add a unit test using either an Integer or enum as key.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:208:
boolean isSimpleMap = (map.isEmpty() ||
ValueCodex.canDecode(map.keySet().iterator().next().getClass()));
Serialization handling does not seem to be symmetric for an empty map with
reference-type'd key: it'd be serialized as a "simple map" (i.e. JSON object)
but would be tentatively parsed as a pair of lists (and would fail at the
split.size()!=2 check)
=> add a unit test for such a map.

How about deferring to the collection (de)serialization, using the map's
entrySet() (and probably special-handling for Map.Entry).
That would encode a map as a list of key-value pairs, and would provide an easy
migration path for those people already doing so with sets of key-value
ValueProxies.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:226:
sb.append(encode(source, mapKey).getPayload());
JSON object keys must be (quoted) strings (per RFC 4627), so either we limit
keys to strings only, or we StringQuoter.quote() them.

That again weighs for a non-JSON-object serialization, and thus probably a
unique one, independent of the type of keys.
...or we use the JSON-object serialization only when keys are strings.

http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
File test/com/google/web/bindery/requestfactory/server/SimpleFoo.java (right):

http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:500: private
Map<String,Integer> valueMap;
How about a Map<String,SimpleBar> to test reference-types as values?

http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:537:
valueMap.put("foo", 3);
How about some 'null' as value?

http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:699: return
simpleValueMap;
indentation.

http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:960: for
(Map.Entry<SimpleBar, Integer> entry : simpleValueMap.entrySet()) {
Why not simply use keySet() here?

[james.horsley, 2012-05-02 21:12:20]

Will follow shortly with a patch taking into account the following feedback but
wanted to get yours and Rajeev's feedback on some points before fixing others.

On 2012/05/02 13:59:05, t.broyer wrote:
> Adding Rajeev as a reviewer.
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File
src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java
> (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
>
src/com/google/web/bindery/requestfactory/apt/TransportableTypeVisitor.java:86:
> DeclaredType asCollection =
> Rename to asMap ?
Fixed.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File src/com/google/web/bindery/requestfactory/server/Resolver.java (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/server/Resolver.java:505:
> accumulator.put(resolveDomainValue(entry.getKey(), detectDeadEntities),
> resolveDomainValue(entry.getValue(), detectDeadEntities));
> Line too long.
Fixed

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/server/Resolver.java:702:
>
accumulator.put(resolveClientValue(entry.getKey(),entryTypes[0]).getClientObject(),
> resolveClientValue(entry.getValue(),entryTypes[1]).getClientObject());
> Line too long.
Fixed

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File
> src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
> (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
>
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:
> if (ctx instanceof MapPropertyContext &&
((MapPropertyContext)ctx).getKeyType()
> != null) {
> Why is this null-check necessary? (or useful)
This method is called by both AutoBeanVisitor.visitCollectionProperty and
AutoBeanVisitor.visitMapProperty since some of the ctx's implemented both
MapPropertyContext and CollectionPropertyContext. The null checked seemed to
safely (as best as I could tell) distinguish the cases.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
> (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:25:
> import com.google.web.bindery.autobean.vm.impl.TypeUtils;
> We're in 'shared', so we can't use 'vm' here (unless there's a super-source
> version of the class, which is not the case here).
Unused import that I've removed now.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:29:
> import java.nio.charset.CoderMalfunctionError;
> We're in 'shared' and java.nio is not emulated (and EntityCodex has no
> super-source version)
Unused import that I've removed now.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135: if
> (ValueCodex.canDecode(keyType)) {
> So, if the key is a "value type", serialization would use a JSON object; and
> otherwise it'd use two lists?
> 
> Can't we have a single serialization for maps? And how about a list of
key-value
> pairs rather than a pair of lists (list of keys and list of values)?
> Or wouldn't it be easier to simply restrict keys to value types? (like
AutoBean
> does already)
I originally did as you're suggesting but switched after digging into what
AutoBean is doing. From what I could tell from AutoBeanCodexImpl.MapCoder and
http://code.google.com/p/google-web-toolkit/wiki/AutoBean#JSON_structures
AutoBean has been updated to allow non-value type keys; as such I just followed
what AutoBean's doing.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:141:
> Object key = ValueCodex.decode(keyType, StringQuoter.create(propertyKey));
> StringQuoter.create() always creates a String Splittable (isString() == true,
> asString() != null), so ValueCodex won't be able to decode booleans, numbers
or
> enums.
> 
> => add a unit test using either an Integer or enum as key.
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:208:
> boolean isSimpleMap = (map.isEmpty() ||
> ValueCodex.canDecode(map.keySet().iterator().next().getClass()));
> Serialization handling does not seem to be symmetric for an empty map with
> reference-type'd key: it'd be serialized as a "simple map" (i.e. JSON object)
> but would be tentatively parsed as a pair of lists (and would fail at the
> split.size()!=2 check)
> => add a unit test for such a map.
Will add and fix accordingly.

> 
> How about deferring to the collection (de)serialization, using the map's
> entrySet() (and probably special-handling for Map.Entry).
> That would encode a map as a list of key-value pairs, and would provide an
easy
> migration path for those people already doing so with sets of key-value
> ValueProxies.
As above, I'd actually started with something like this but switched based on
what I'd perceived AutoBean to be doing with Map's.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:226:
> sb.append(encode(source, mapKey).getPayload());
> JSON object keys must be (quoted) strings (per RFC 4627), so either we limit
> keys to strings only, or we StringQuoter.quote() them.
> 
> That again weighs for a non-JSON-object serialization, and thus probably a
> unique one, independent of the type of keys.
> ...or we use the JSON-object serialization only when keys are strings.
Went with the StringQuoter.quote() suggestion.

> 
>
http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
> File test/com/google/web/bindery/requestfactory/server/SimpleFoo.java (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
> test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:500: private
> Map<String,Integer> valueMap;
> How about a Map<String,SimpleBar> to test reference-types as values?
I tested this with a local sample app but will add an equivalent unit test.

> 
>
http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
> test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:537:
> valueMap.put("foo", 3);
> How about some 'null' as value?
Will add.

> 
>
http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
> test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:699: return
> simpleValueMap;
> indentation.
Fixed

> 
>
http://codereview.appspot.com/6132056/diff/5012/test/com/google/web/bindery/r...
> test/com/google/web/bindery/requestfactory/server/SimpleFoo.java:960: for
> (Map.Entry<SimpleBar, Integer> entry : simpleValueMap.entrySet()) {
> Why not simply use keySet() here?
Very good point! Fixed.

[t.broyer, 2012-05-03 00:10:56]

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
(right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:
if (ctx instanceof MapPropertyContext && ((MapPropertyContext)ctx).getKeyType()
!= null) {
> This method is called by both AutoBeanVisitor.visitCollectionProperty
> and AutoBeanVisitor.visitMapProperty since some of the ctx's implemented
> both MapPropertyContext and CollectionPropertyContext. The null checked
> seemed to safely (as best as I could tell) distinguish the cases.

I haven't looked whether there'd be an alternate approach, but it might at least
be worth a comment in the code.

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
File src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
(right):

http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135: if
(ValueCodex.canDecode(keyType)) {
> I originally did as you're suggesting but switched after digging into
> what AutoBean is doing. From what I could tell from
> AutoBeanCodexImpl.MapCoder and
> http://code.google.com/p/google-web-toolkit/wiki/AutoBean#JSON_structures
> AutoBean has been updated to allow non-value type keys; as such I just
> followed what AutoBean's doing.

Oh, I'm more than OK to mimick AutoBean then!

[james.horsley, 2012-05-03 23:13:16]

The latest patch should incorporate all relevant feedback. Including adding
suggested tests and fixing where things when the tests failed.

On 2012/05/03 00:10:56, t.broyer wrote:
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File
> src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java
> (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
>
src/com/google/web/bindery/requestfactory/server/SimpleRequestProcessor.java:523:
> if (ctx instanceof MapPropertyContext &&
((MapPropertyContext)ctx).getKeyType()
> != null) {
> > This method is called by both AutoBeanVisitor.visitCollectionProperty
> > and AutoBeanVisitor.visitMapProperty since some of the ctx's implemented
> > both MapPropertyContext and CollectionPropertyContext. The null checked
> > seemed to safely (as best as I could tell) distinguish the cases.
> 
> I haven't looked whether there'd be an alternate approach, but it might at
least
> be worth a comment in the code.
Added.

> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> File src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java
> (right):
> 
>
http://codereview.appspot.com/6132056/diff/5012/src/com/google/web/bindery/re...
> src/com/google/web/bindery/requestfactory/shared/impl/EntityCodex.java:135: if
> (ValueCodex.canDecode(keyType)) {
> > I originally did as you're suggesting but switched after digging into
> > what AutoBean is doing. From what I could tell from
> > AutoBeanCodexImpl.MapCoder and
> > http://code.google.com/p/google-web-toolkit/wiki/AutoBean#JSON_structures
> > AutoBean has been updated to allow non-value type keys; as such I just
> > followed what AutoBean's doing.
> 
> Oh, I'm more than OK to mimick AutoBean then!

[james.horsley, 2012-05-07 20:28:44]

The instructions at
https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches say
to add this patch to the issue
(http://code.google.com/p/google-web-toolkit/issues/detail?id=5524) but I don't
see how to do that. Is there a permission I'm missing?

[james.horsley, 2012-05-10 20:15:15]

Rajeev, did you get a chance to look the patch over?

I have no clue on what the turnaround is on submitted patches so hopefully am
not being too pushy. I saw that GWT 2.5 is close to being released and I'd love
to have this functionality available in it.

Thanks!

On 2012/05/07 20:28:44, james.horsley wrote:
> The instructions at
> https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
say
> to add this patch to the issue
> (http://code.google.com/p/google-web-toolkit/issues/detail?id=5524) but I
don't
> see how to do that. Is there a permission I'm missing?

[rdayal, 2012-05-14 17:04:47]

Hey James,

Sorry, I have not had a chance to look this one over, but I am planning to.
The turnaround on patches has been pretty bad for the past while, and we're
actively going to make some changes soon that will result in big
improvements (I hope).

In the meantime, we're trying to review and land patches as fast as we can.
No, you're not being pushy :).


Rajeev


On Thu May 10 16:15:15 GMT-400 2012, <james.horsley@gmail.com> wrote:

> Rajeev, did you get a chance to look the patch over?
>
> I have no clue on what the turnaround is on submitted patches so
> hopefully am not being too pushy. I saw that GWT 2.5 is close to being
> released and I'd love to have this functionality available in it.
>
> Thanks!
>
> On 2012/05/07 20:28:44, james.horsley wrote:
> > The instructions at
>
> https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
> say
> > to add this patch to the issue
> > (http://code.google.com/p/google-web-toolkit/issues/detail?id=5524)
> but I don't
> > see how to do that. Is there a permission I'm missing?
>
>
>
>
http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http...
>

[james.horsley, 2012-05-15 22:19:51]

Thanks for the update Rajeev. Look forward to hearing back on the patch.

Cheers,
James

On 2012/05/14 17:04:47, rdayal wrote:
> Hey James,
> 
> Sorry, I have not had a chance to look this one over, but I am planning to.
> The turnaround on patches has been pretty bad for the past while, and we're
> actively going to make some changes soon that will result in big
> improvements (I hope).
> 
> In the meantime, we're trying to review and land patches as fast as we can.
> No, you're not being pushy :).
> 
> 
> Rajeev
> 
> 
> On Thu May 10 16:15:15 GMT-400 2012, <mailto:james.horsley@gmail.com> wrote:
> 
> > Rajeev, did you get a chance to look the patch over?
> >
> > I have no clue on what the turnaround is on submitted patches so
> > hopefully am not being too pushy. I saw that GWT 2.5 is close to being
> > released and I'd love to have this functionality available in it.
> >
> > Thanks!
> >
> > On 2012/05/07 20:28:44, james.horsley wrote:
> > > The instructions at
> >
> > https://developers.google.com/web-toolkit/makinggwtbetter#submittingpatches
> > say
> > > to add this patch to the issue
> > > (http://code.google.com/p/google-web-toolkit/issues/detail?id=5524)
> > but I don't
> > > see how to do that. Is there a permission I'm missing?
> >
> >
> >
> >
>
http://codereview.appspot.com/6132056/%3Chttps://www.google.com/url?sa=D&q=ht...>
> >

[alexisnouvel, 2012-05-25 16:01:32]

Hello
With your patch, does the function .with() works for a map for example
in an entity:

Map(String,ServiceParam) params;

requestContext.find(id).with("params.ServiceParam.Reader");

ServiceParam and Reader are also Entity.
Will it work?

thanks,

[james.horsley, 2012-05-25 17:09:32]

I added tests for complex keys and complex values which're passing so it
should do yes.

On 25 May 2012 17:01, <alexisnouvel@gmail.com> wrote:

> Hello
> With your patch, does the function .with() works for a map for example
> in an entity:
>
> Map(String,ServiceParam) params;
>
> requestContext.find(id).with("**params.ServiceParam.Reader");
>
> ServiceParam and Reader are also Entity.
> Will it work?
>
> thanks,
>
>
>
>
>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>

[t.broyer, 2012-05-25 18:38:45]

On 2012/05/25 17:09:32, james.horsley wrote:
> I added tests for complex keys and complex values which're passing so it
> should do yes.

I don't see any change to addPathsToResolution...
Also, how would it work? Say I have a Map<A,B>, A has a reference "c" to a proxy
C, and B has a reference "d" to a proxy D. What should I pass to Request#with()
to get the Ds of B without the Cs of A? with("theMap.d") ? Now what if A and B
both have a property "e" referencing a proxy E, I want B's Es but not A's Es,
with("theMap.e") wouldn't work here.
I think maybe there should be special subproperties "keys" and "values", so one
can say: with("myMap.keys.c", "myMap.values.d", "myMap.values.e") to get A's Cs,
and B's Ds and Es (without A's Es!)

[james.horsley, 2012-05-25 19:06:50]

I read Alexis's email too hastily and hadn't noted he was asking about
nested complex types. I'll add some tests to see how it behaves. I'll be
interested to dig into what AutoBean's behaviour is here as that's what I
based on, mimicked, and leveraged for this patch.

On 25 May 2012 19:38, <t.broyer@gmail.com> wrote:

> On 2012/05/25 17:09:32, james.horsley wrote:
>
>> I added tests for complex keys and complex values which're passing so
>>
> it
>
>> should do yes.
>>
>
> I don't see any change to addPathsToResolution...
> Also, how would it work? Say I have a Map<A,B>, A has a reference "c" to
> a proxy C, and B has a reference "d" to a proxy D. What should I pass to
> Request#with() to get the Ds of B without the Cs of A? with("theMap.d")
> ? Now what if A and B both have a property "e" referencing a proxy E, I
> want B's Es but not A's Es, with("theMap.e") wouldn't work here.
> I think maybe there should be special subproperties "keys" and "values",
> so one can say: with("myMap.keys.c", "myMap.values.d", "myMap.values.e")
> to get A's Cs, and B's Ds and Es (without A's Es!)
>
>
>
>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>

[t.broyer, 2012-05-25 21:06:27]

AutoBean has no equivalent to these "partial loading"; just like a POJO has
no notion of lazy loading, compared to JPA entities.
Le 25 mai 2012 21:06, "James Horsley" <james.horsley@gmail.com> a écrit :

> I read Alexis's email too hastily and hadn't noted he was asking about
> nested complex types. I'll add some tests to see how it behaves. I'll be
> interested to dig into what AutoBean's behaviour is here as that's what I
> based on, mimicked, and leveraged for this patch.
>
> On 25 May 2012 19:38, <t.broyer@gmail.com> wrote:
>
>> On 2012/05/25 17:09:32, james.horsley wrote:
>>
>>> I added tests for complex keys and complex values which're passing so
>>>
>> it
>>
>>> should do yes.
>>>
>>
>> I don't see any change to addPathsToResolution...
>> Also, how would it work? Say I have a Map<A,B>, A has a reference "c" to
>> a proxy C, and B has a reference "d" to a proxy D. What should I pass to
>> Request#with() to get the Ds of B without the Cs of A? with("theMap.d")
>> ? Now what if A and B both have a property "e" referencing a proxy E, I
>> want B's Es but not A's Es, with("theMap.e") wouldn't work here.
>> I think maybe there should be special subproperties "keys" and "values",
>> so one can say: with("myMap.keys.c", "myMap.values.d", "myMap.values.e")
>> to get A's Cs, and B's Ds and Es (without A's Es!)
>>
>>
>>
>>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>>
>
>

[james.horsley, 2012-06-04 12:08:34]

I finally managed to get time to look at this. I added tests to answer to
Alexis's original question and my current patch out for review would not
work with his supplied case. Luckily, it was a fairly easy change to
addPathsToResolution to have it add the child resolutions without handling
the edge case Thomas pointed out.

I really Thomas's ".keys." and ".values." suggestion for disambiguation of
a common property name between the key and value types so, unless anyone
prefers "theMap.e" pulling in both the key's E's and values's E's,
I'll take a stab at that change.

Let me know if there're any other suggestions.

Cheers,
James

On 25 May 2012 22:06, Thomas Broyer <t.broyer@gmail.com> wrote:

> AutoBean has no equivalent to these "partial loading"; just like a POJO
> has no notion of lazy loading, compared to JPA entities.
> Le 25 mai 2012 21:06, "James Horsley" <james.horsley@gmail.com> a écrit :
>
> I read Alexis's email too hastily and hadn't noted he was asking about
>> nested complex types. I'll add some tests to see how it behaves. I'll be
>> interested to dig into what AutoBean's behaviour is here as that's what I
>> based on, mimicked, and leveraged for this patch.
>>
>> On 25 May 2012 19:38, <t.broyer@gmail.com> wrote:
>>
>>> On 2012/05/25 17:09:32, james.horsley wrote:
>>>
>>>> I added tests for complex keys and complex values which're passing so
>>>>
>>> it
>>>
>>>> should do yes.
>>>>
>>>
>>> I don't see any change to addPathsToResolution...
>>> Also, how would it work? Say I have a Map<A,B>, A has a reference "c" to
>>> a proxy C, and B has a reference "d" to a proxy D. What should I pass to
>>> Request#with() to get the Ds of B without the Cs of A? with("theMap.d")
>>> ? Now what if A and B both have a property "e" referencing a proxy E, I
>>> want B's Es but not A's Es, with("theMap.e") wouldn't work here.
>>> I think maybe there should be special subproperties "keys" and "values",
>>> so one can say: with("myMap.keys.c", "myMap.values.d", "myMap.values.e")
>>> to get A's Cs, and B's Ds and Es (without A's Es!)
>>>
>>>
>>>
>>>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>>>
>>
>>

[james.horsley, 2012-06-04 12:19:00]

Adding the ".keys." and ".values." disambiguation was much much simpler
than I'd thought thanks to the prefix variable being passed down so can
have the codereview updated with this change very shortly.

On 4 June 2012 13:07, James Horsley <james.horsley@gmail.com> wrote:

> I finally managed to get time to look at this. I added tests to answer to
> Alexis's original question and my current patch out for review would not
> work with his supplied case. Luckily, it was a fairly easy change to
> addPathsToResolution to have it add the child resolutions without handling
> the edge case Thomas pointed out.
>
> I really Thomas's ".keys." and ".values." suggestion for disambiguation of
> a common property name between the key and value types so, unless anyone
> prefers "theMap.e" pulling in both the key's E's and values's E's,
> I'll take a stab at that change.
>
> Let me know if there're any other suggestions.
>
> Cheers,
> James
>
> On 25 May 2012 22:06, Thomas Broyer <t.broyer@gmail.com> wrote:
>
>> AutoBean has no equivalent to these "partial loading"; just like a POJO
>> has no notion of lazy loading, compared to JPA entities.
>> Le 25 mai 2012 21:06, "James Horsley" <james.horsley@gmail.com> a écrit :
>>
>> I read Alexis's email too hastily and hadn't noted he was asking about
>>> nested complex types. I'll add some tests to see how it behaves. I'll be
>>> interested to dig into what AutoBean's behaviour is here as that's what I
>>> based on, mimicked, and leveraged for this patch.
>>>
>>> On 25 May 2012 19:38, <t.broyer@gmail.com> wrote:
>>>
>>>> On 2012/05/25 17:09:32, james.horsley wrote:
>>>>
>>>>> I added tests for complex keys and complex values which're passing so
>>>>>
>>>> it
>>>>
>>>>> should do yes.
>>>>>
>>>>
>>>> I don't see any change to addPathsToResolution...
>>>> Also, how would it work? Say I have a Map<A,B>, A has a reference "c" to
>>>> a proxy C, and B has a reference "d" to a proxy D. What should I pass to
>>>> Request#with() to get the Ds of B without the Cs of A? with("theMap.d")
>>>> ? Now what if A and B both have a property "e" referencing a proxy E, I
>>>> want B's Es but not A's Es, with("theMap.e") wouldn't work here.
>>>> I think maybe there should be special subproperties "keys" and "values",
>>>> so one can say: with("myMap.keys.c", "myMap.values.d", "myMap.values.e")
>>>> to get A's Cs, and B's Ds and Es (without A's Es!)
>>>>
>>>>
>>>>
>>>>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>>>>
>>>
>>>
>

[james.horsley, 2012-06-05 10:50:18]

Based on the email thread with Alexis and Thomas I've fixed the handling of
nested entities along with adding the appropriate tests to verify the behaviour.
To retrieve nested entities in a Map using .with() the syntax is
theMap.keys.nestedProp and theMap.values.nestedProp.

[james.horsley, 2012-06-07 08:20:34]

Rajeev, get a chance to look at this yet?

On 2012/06/05 10:50:18, james.horsley wrote:
> Based on the email thread with Alexis and Thomas I've fixed the handling of
> nested entities along with adding the appropriate tests to verify the
behaviour.
> To retrieve nested entities in a Map using .with() the syntax is
> theMap.keys.nestedProp and theMap.values.nestedProp.

[t.broyer, 2012-06-07 09:04:23]

On 2012/06/07 08:20:34, james.horsley wrote:
> Rajeev, get a chance to look at this yet?

We're cutting out GWT 2.5 soon; we decided to postpone this change to the next
version.

BTW, sorry for being picky, could you please:
 - make your patch at the trunk/ level (rather than trunk/user/)
 - post it at http://gwt-code-reviews.appspot.com

Also, have you signed a CLA?
See https://developers.google.com/web-toolkit/makinggwtbetter#contributingcode
> 
> On 2012/06/05 10:50:18, james.horsley wrote:
> > Based on the email thread with Alexis and Thomas I've fixed the handling of
> > nested entities along with adding the appropriate tests to verify the
> behaviour.
> > To retrieve nested entities in a Map using .with() the syntax is
> > theMap.keys.nestedProp and theMap.values.nestedProp.

[james.horsley, 2012-06-07 09:22:24]

Thanks for all your help with the patch Thomas. Sad to hear it won't make it
into GWT 2.5 as we were really looking to use RF with Maps without having to use
a patched version of GWT built from source internally.

Certainly can switch to the patch being at the trunk/ level and post it at the
url you gave though.

Also, I signed the CLA via the online form a while back but never heard anything
back from it. Was I supposed to get a confirmation?

On 2012/06/07 09:04:23, t.broyer wrote:
> On 2012/06/07 08:20:34, james.horsley wrote:
> > Rajeev, get a chance to look at this yet?
> 
> We're cutting out GWT 2.5 soon; we decided to postpone this change to the next
> version.
> 
> BTW, sorry for being picky, could you please:
>  - make your patch at the trunk/ level (rather than trunk/user/)
>  - post it at http://gwt-code-reviews.appspot.com
> 
> Also, have you signed a CLA?
> See https://developers.google.com/web-toolkit/makinggwtbetter#contributingcode
> > 
> > On 2012/06/05 10:50:18, james.horsley wrote:
> > > Based on the email thread with Alexis and Thomas I've fixed the handling
of
> > > nested entities along with adding the appropriate tests to verify the
> > behaviour.
> > > To retrieve nested entities in a Map using .with() the syntax is
> > > theMap.keys.nestedProp and theMap.values.nestedProp.

[james.horsley, 2012-06-07 09:55:00]

Thomas, I've created http://gwt-code-reviews.appspot.com/1735803/ as you
requested. Everything look okay with how I set the code review up?

On 7 June 2012 10:22, <james.horsley@gmail.com> wrote:

> Thanks for all your help with the patch Thomas. Sad to hear it won't
> make it into GWT 2.5 as we were really looking to use RF with Maps
> without having to use a patched version of GWT built from source
> internally.
>
> Certainly can switch to the patch being at the trunk/ level and post it
> at the url you gave though.
>
> Also, I signed the CLA via the online form a while back but never heard
> anything back from it. Was I supposed to get a confirmation?
>
>
> On 2012/06/07 09:04:23, t.broyer wrote:
>
>> On 2012/06/07 08:20:34, james.horsley wrote:
>> > Rajeev, get a chance to look at this yet?
>>
>
>  We're cutting out GWT 2.5 soon; we decided to postpone this change to
>>
> the next
>
>> version.
>>
>
>  BTW, sorry for being picky, could you please:
>>  - make your patch at the trunk/ level (rather than trunk/user/)
>>  - post it at
http://gwt-code-reviews.**appspot.com<http://gwt-code-reviews.appspot.com>
>>
>
>  Also, have you signed a CLA?
>> See
>>
> https://developers.google.com/**web-toolkit/makinggwtbetter#**
>
contributingcode<https://developers.google.com/web-toolkit/makinggwtbetter#contributingcode>
>
>> >
>> > On 2012/06/05 10:50:18, james.horsley wrote:
>> > > Based on the email thread with Alexis and Thomas I've fixed the
>>
> handling of
>
>> > > nested entities along with adding the appropriate tests to verify
>>
> the
>
>> > behaviour.
>> > > To retrieve nested entities in a Map using .with() the syntax is
>> > > theMap.keys.nestedProp and theMap.values.nestedProp.
>>
>
>
>
>
http://codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/>
>

[t.broyer, 2012-06-07 09:56:52]

On 2012/06/07 09:22:24, james.horsley wrote:
> Thanks for all your help with the patch Thomas. Sad to hear it won't make it
> into GWT 2.5 as we were really looking to use RF with Maps without having to
use
> a patched version of GWT built from source internally.

We're planning a 2.5.1 soon after 2.5.
There are also several issues with Map support in AutoBeans (reported only
recently) which I'd like to get fixed at the same time (some of them are related
to how maps are encoded/decoded, so I'd like to have it the same in both
AutoBeans and RF; see
http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for instance,
which you seem to have avoided by using a slightly different serialization path
for keys, where String keys are encoded as "\"foo\"", vs. "foo" in AutoBean's
serialization).
Finally, to be honest, I think we need at least one more round here: I need some
more time to wrap my head around it.

[james.horsley, 2012-06-07 10:23:58]

Totally agree on this needing another round. Also, hearing about the plans for a
2.5.1 release which this could potentially be a candidate for is great.

Thanks again.

On 2012/06/07 09:56:52, t.broyer wrote:
> On 2012/06/07 09:22:24, james.horsley wrote:
> > Thanks for all your help with the patch Thomas. Sad to hear it won't make it
> > into GWT 2.5 as we were really looking to use RF with Maps without having to
> use
> > a patched version of GWT built from source internally.
> 
> We're planning a 2.5.1 soon after 2.5.
> There are also several issues with Map support in AutoBeans (reported only
> recently) which I'd like to get fixed at the same time (some of them are
related
> to how maps are encoded/decoded, so I'd like to have it the same in both
> AutoBeans and RF; see
> http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
instance,
> which you seem to have avoided by using a slightly different serialization
path
> for keys, where String keys are encoded as "\"foo\"", vs. "foo" in AutoBean's
> serialization).
> Finally, to be honest, I think we need at least one more round here: I need
some
> more time to wrap my head around it.

[rdayal, 2012-06-07 15:18:26]

Thomas, thanks for jumping in.

James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
to get it in there, as it's an important patch. We just didn't want to
force this patch in 2.5.0, which is what we would have to do with the
current workload.

Thanks so much for working on this.


On Thu Jun 07 06:23:58 GMT-400 2012, <james.horsley@gmail.com> wrote:

> Totally agree on this needing another round. Also, hearing about the
> plans for a 2.5.1 release which this could potentially be a candidate
> for is great.
>
> Thanks again.
>
> On 2012/06/07 09:56:52, t.broyer wrote:
> > On 2012/06/07 09:22:24, james.horsley wrote:
> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> make it
> > > into GWT 2.5 as we were really looking to use RF with Maps without
> having to
> > use
> > > a patched version of GWT built from source internally.
>
> > We're planning a 2.5.1 soon after 2.5.
> > There are also several issues with Map support in AutoBeans (reported
> only
> > recently) which I'd like to get fixed at the same time (some of them
> are related
> > to how maps are encoded/decoded, so I'd like to have it the same in
> both
> > AutoBeans and RF; see
> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> instance,
> > which you seem to have avoided by using a slightly different
> serialization path
> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> AutoBean's
> > serialization).
> > Finally, to be honest, I think we need at least one more round here: I
> need some
> > more time to wrap my head around it.
>
>
>
>
http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http...
>

[james.horsley, 2012-06-07 15:57:17]

Thanks Rajeev. Let me know if there's anything else you need with it.

On 7 June 2012 16:18, Rajeev Dayal <rdayal@google.com> wrote:

> Thomas, thanks for jumping in.
>
> James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
> to get it in there, as it's an important patch. We just didn't want to
> force this patch in 2.5.0, which is what we would have to do with the
> current workload.
>
> Thanks so much for working on this.
>
>
> On Thu Jun 07 06:23:58 GMT-400 2012, <james.horsley@gmail.com> wrote:
>
>> Totally agree on this needing another round. Also, hearing about the
>> plans for a 2.5.1 release which this could potentially be a candidate
>> for is great.
>>
>> Thanks again.
>>
>> On 2012/06/07 09:56:52, t.broyer wrote:
>> > On 2012/06/07 09:22:24, james.horsley wrote:
>> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
>> make it
>> > > into GWT 2.5 as we were really looking to use RF with Maps without
>> having to
>> > use
>> > > a patched version of GWT built from source internally.
>>
>> > We're planning a 2.5.1 soon after 2.5.
>> > There are also several issues with Map support in AutoBeans (reported
>> only
>> > recently) which I'd like to get fixed at the same time (some of them
>> are related
>> > to how maps are encoded/decoded, so I'd like to have it the same in
>> both
>> > AutoBeans and RF; see
>> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
>> instance,
>> > which you seem to have avoided by using a slightly different
>> serialization path
>> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
>> AutoBean's
>> > serialization).
>> > Finally, to be honest, I think we need at least one more round here: I
>> need some
>> > more time to wrap my head around it.
>>
>>
>>
>>
http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http...
>>
>

[james.horsley, 2012-06-08 09:16:26]

Just to check, was everything okay with the CLA I signed?

On 7 June 2012 16:56, James Horsley <james.horsley@gmail.com> wrote:

> Thanks Rajeev. Let me know if there's anything else you need with it.
>
>
> On 7 June 2012 16:18, Rajeev Dayal <rdayal@google.com> wrote:
>
>> Thomas, thanks for jumping in.
>>
>> James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely
>> like to get it in there, as it's an important patch. We just didn't want to
>> force this patch in 2.5.0, which is what we would have to do with the
>> current workload.
>>
>> Thanks so much for working on this.
>>
>>
>> On Thu Jun 07 06:23:58 GMT-400 2012, <james.horsley@gmail.com> wrote:
>>
>>> Totally agree on this needing another round. Also, hearing about the
>>> plans for a 2.5.1 release which this could potentially be a candidate
>>> for is great.
>>>
>>> Thanks again.
>>>
>>> On 2012/06/07 09:56:52, t.broyer wrote:
>>> > On 2012/06/07 09:22:24, james.horsley wrote:
>>> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
>>> make it
>>> > > into GWT 2.5 as we were really looking to use RF with Maps without
>>> having to
>>> > use
>>> > > a patched version of GWT built from source internally.
>>>
>>> > We're planning a 2.5.1 soon after 2.5.
>>> > There are also several issues with Map support in AutoBeans (reported
>>> only
>>> > recently) which I'd like to get fixed at the same time (some of them
>>> are related
>>> > to how maps are encoded/decoded, so I'd like to have it the same in
>>> both
>>> > AutoBeans and RF; see
>>> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
>>> instance,
>>> > which you seem to have avoided by using a slightly different
>>> serialization path
>>> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
>>> AutoBean's
>>> > serialization).
>>> > Finally, to be honest, I think we need at least one more round here: I
>>> need some
>>> > more time to wrap my head around it.
>>>
>>>
>>>
>>>
http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http...
>>>
>>
>

[rdayal, 2012-06-08 17:20:06]

Yep, you're on the CLA list.

On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley <james.horsley@gmail.com>
wrote:

> Just to check, was everything okay with the CLA I signed?
>
> On 7 June 2012 16:56, James Horsley <james.horsley@gmail.com> wrote:
>
> Thanks Rajeev. Let me know if there's anything else you need with it.
>
>
> On 7 June 2012 16:18, Rajeev Dayal <rdayal@google.com> wrote:
>
> Thomas, thanks for jumping in.
>
> James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
> to get it in there, as it's an important patch. We just didn't want to
> force this patch in 2.5.0, which is what we would have to do with the
> current workload.
>
> Thanks so much for working on this.
>
>
> On Thu Jun 07 06:23:58 GMT-400 2012, <james.horsley@gmail.com> wrote:
>
> Totally agree on this needing another round. Also, hearing about the
> plans for a 2.5.1 release which this could potentially be a candidate
> for is great.
>
> Thanks again.
>
> On 2012/06/07 09:56:52, t.broyer wrote:
> > On 2012/06/07 09:22:24, james.horsley wrote:
> > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> make it
> > > into GWT 2.5 as we were really looking to use RF with Maps without
> having to
> > use
> > > a patched version of GWT built from source internally.
>
> > We're planning a 2.5.1 soon after 2.5.
> > There are also several issues with Map support in AutoBeans (reported
> only
> > recently) which I'd like to get fixed at the same time (some of them
> are related
> > to how maps are encoded/decoded, so I'd like to have it the same in
> both
> > AutoBeans and RF; see
> > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> instance,
> > which you seem to have avoided by using a slightly different
> serialization path
> > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> AutoBean's
> > serialization).
> > Finally, to be honest, I think we need at least one more round here: I
> need some
> > more time to wrap my head around it.
>
>
>
>
http://codereview.appspot.com/6132056/<https://www.google.com/url?sa=D&q=http...
>
>
>
>

[james.horsley, 2012-10-30 08:28:07]

On 2012/06/08 17:20:06, rdayal wrote:
> Yep, you're on the CLA list.
> 
> On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley
<mailto:james.horsley@gmail.com>
> wrote:
> 
> > Just to check, was everything okay with the CLA I signed?
> >
> > On 7 June 2012 16:56, James Horsley <mailto:james.horsley@gmail.com> wrote:
> >
> > Thanks Rajeev. Let me know if there's anything else you need with it.
> >
> >
> > On 7 June 2012 16:18, Rajeev Dayal <mailto:rdayal@google.com> wrote:
> >
> > Thomas, thanks for jumping in.
> >
> > James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
> > to get it in there, as it's an important patch. We just didn't want to
> > force this patch in 2.5.0, which is what we would have to do with the
> > current workload.
> >
> > Thanks so much for working on this.
> >
> >
> > On Thu Jun 07 06:23:58 GMT-400 2012, <mailto:james.horsley@gmail.com> wrote:
> >
> > Totally agree on this needing another round. Also, hearing about the
> > plans for a 2.5.1 release which this could potentially be a candidate
> > for is great.
> >
> > Thanks again.
> >
> > On 2012/06/07 09:56:52, t.broyer wrote:
> > > On 2012/06/07 09:22:24, james.horsley wrote:
> > > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> > make it
> > > > into GWT 2.5 as we were really looking to use RF with Maps without
> > having to
> > > use
> > > > a patched version of GWT built from source internally.
> >
> > > We're planning a 2.5.1 soon after 2.5.
> > > There are also several issues with Map support in AutoBeans (reported
> > only
> > > recently) which I'd like to get fixed at the same time (some of them
> > are related
> > > to how maps are encoded/decoded, so I'd like to have it the same in
> > both
> > > AutoBeans and RF; see
> > > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> > instance,
> > > which you seem to have avoided by using a slightly different
> > serialization path
> > > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> > AutoBean's
> > > serialization).
> > > Finally, to be honest, I think we need at least one more round here: I
> > need some
> > > more time to wrap my head around it.
> >
> >
> >
> >
>
http://codereview.appspot.com/6132056/%3Chttps://www.google.com/url?sa=D&q=ht...>
> >
> >
> >
> >

I'm possibly being a bit eager given 2.5 GA only just went out but thought I'd
just ping on this with regards to the 2.5.1 release that had been mentioned.

[mfetzer, 2013-07-29 15:27:33]

On 2012/10/30 08:28:07, james.horsley wrote:
> On 2012/06/08 17:20:06, rdayal wrote:
> > Yep, you're on the CLA list.
> > 
> > On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley
> <mailto:james.horsley@gmail.com>
> > wrote:
> > 
> > > Just to check, was everything okay with the CLA I signed?
> > >
> > > On 7 June 2012 16:56, James Horsley <mailto:james.horsley@gmail.com>
wrote:
> > >
> > > Thanks Rajeev. Let me know if there's anything else you need with it.
> > >
> > >
> > > On 7 June 2012 16:18, Rajeev Dayal <mailto:rdayal@google.com> wrote:
> > >
> > > Thomas, thanks for jumping in.
> > >
> > > James, as Thomas said, we'll defer this to 2.5.1, but we'd definitely like
> > > to get it in there, as it's an important patch. We just didn't want to
> > > force this patch in 2.5.0, which is what we would have to do with the
> > > current workload.
> > >
> > > Thanks so much for working on this.
> > >
> > >
> > > On Thu Jun 07 06:23:58 GMT-400 2012, <mailto:james.horsley@gmail.com>
wrote:
> > >
> > > Totally agree on this needing another round. Also, hearing about the
> > > plans for a 2.5.1 release which this could potentially be a candidate
> > > for is great.
> > >
> > > Thanks again.
> > >
> > > On 2012/06/07 09:56:52, t.broyer wrote:
> > > > On 2012/06/07 09:22:24, james.horsley wrote:
> > > > > Thanks for all your help with the patch Thomas. Sad to hear it won't
> > > make it
> > > > > into GWT 2.5 as we were really looking to use RF with Maps without
> > > having to
> > > > use
> > > > > a patched version of GWT built from source internally.
> > >
> > > > We're planning a 2.5.1 soon after 2.5.
> > > > There are also several issues with Map support in AutoBeans (reported
> > > only
> > > > recently) which I'd like to get fixed at the same time (some of them
> > > are related
> > > > to how maps are encoded/decoded, so I'd like to have it the same in
> > > both
> > > > AutoBeans and RF; see
> > > > http://code.google.com/p/google-web-toolkit/issues/detail?id=7395 for
> > > instance,
> > > > which you seem to have avoided by using a slightly different
> > > serialization path
> > > > for keys, where String keys are encoded as "\"foo\"", vs. "foo" in
> > > AutoBean's
> > > > serialization).
> > > > Finally, to be honest, I think we need at least one more round here: I
> > > need some
> > > > more time to wrap my head around it.
> > >
> > >
> > >
> > >
> >
>
http://codereview.appspot.com/6132056/%253Chttps://www.google.com/url?sa=D&q=...>
> > >
> > >
> > >
> > >
> 
> I'm possibly being a bit eager given 2.5 GA only just went out but thought I'd
> just ping on this with regards to the 2.5.1 release that had been mentioned.

Anything new on this?

[james.horsley, 2013-07-29 16:09:04]

I ported the CR to gerrit a couple of months back
https://gwt-review.googlesource.com/#/c/3186/

Last update I got was that it's pending further review by Thomas Broyer
who's currently tied up with modularization and mavenization. I'm seeing
other RF changes going on though so hopefully it won't require too much
reworking of my original commit.

<rant>
I totally understand there are limited resources for reviewing this stuff
but it would be quite frustrating if many changes were necessary to my
patch due to underlying changes. I submitted the patch over a year ago and
it's the 6th highest starred issue on the issue tracker from what I can
tell.
</rant>


On 29 July 2013 16:27, <mfetzer@tchepa.com> wrote:

> On 2012/10/30 08:28:07, james.horsley wrote:
>
>> On 2012/06/08 17:20:06, rdayal wrote:
>> > Yep, you're on the CLA list.
>> >
>> > On Fri Jun 08 05:15:45 GMT-400 2012, James Horsley
>> <mailto:james.horsley@gmail.**com <james.horsley@gmail.com>>
>> > wrote:
>> >
>> > > Just to check, was everything okay with the CLA I signed?
>> > >
>> > > On 7 June 2012 16:56, James Horsley
>>
> <mailto:james.horsley@gmail.**com <james.horsley@gmail.com>> wrote:
>
>> > >
>> > > Thanks Rajeev. Let me know if there's anything else you need with
>>
> it.
>
>> > >
>> > >
>> > > On 7 June 2012 16:18, Rajeev Dayal <mailto:rdayal@google.com>
>>
> wrote:
>
>> > >
>> > > Thomas, thanks for jumping in.
>> > >
>> > > James, as Thomas said, we'll defer this to 2.5.1, but we'd
>>
> definitely like
>
>> > > to get it in there, as it's an important patch. We just didn't
>>
> want to
>
>> > > force this patch in 2.5.0, which is what we would have to do with
>>
> the
>
>> > > current workload.
>> > >
>> > > Thanks so much for working on this.
>> > >
>> > >
>> > > On Thu Jun 07 06:23:58 GMT-400 2012,
>>
> <mailto:james.horsley@gmail.**com <james.horsley@gmail.com>> wrote:
>
>> > >
>> > > Totally agree on this needing another round. Also, hearing about
>>
> the
>
>> > > plans for a 2.5.1 release which this could potentially be a
>>
> candidate
>
>> > > for is great.
>> > >
>> > > Thanks again.
>> > >
>> > > On 2012/06/07 09:56:52, t.broyer wrote:
>> > > > On 2012/06/07 09:22:24, james.horsley wrote:
>> > > > > Thanks for all your help with the patch Thomas. Sad to hear it
>>
> won't
>
>> > > make it
>> > > > > into GWT 2.5 as we were really looking to use RF with Maps
>>
> without
>
>> > > having to
>> > > > use
>> > > > > a patched version of GWT built from source internally.
>> > >
>> > > > We're planning a 2.5.1 soon after 2.5.
>> > > > There are also several issues with Map support in AutoBeans
>>
> (reported
>
>> > > only
>> > > > recently) which I'd like to get fixed at the same time (some of
>>
> them
>
>> > > are related
>> > > > to how maps are encoded/decoded, so I'd like to have it the same
>>
> in
>
>> > > both
>> > > > AutoBeans and RF; see
>> > > >
>>
>
http://code.google.com/p/**google-web-toolkit/issues/**detail?id=7395<http://...
>
>> > > instance,
>> > > > which you seem to have avoided by using a slightly different
>> > > serialization path
>> > > > for keys, where String keys are encoded as "\"foo\"", vs. "foo"
>>
> in
>
>> > > AutoBean's
>> > > > serialization).
>> > > > Finally, to be honest, I think we need at least one more round
>>
> here: I
>
>> > > need some
>> > > > more time to wrap my head around it.
>> > >
>> > >
>> > >
>> > >
>> >
>>
>
> http://codereview.appspot.com/**6132056/%253Chttps://www.**
>
google.com/url?sa=D&q=http://**codereview.appspot.com/**6132056/<http://codereview.appspot.com/6132056/%253Chttps://www.google.com/url?sa=D&q=http://codereview.appspot.com/6132056/>
> >
>
>> > >
>> > >
>> > >
>> > >
>>
>
>  I'm possibly being a bit eager given 2.5 GA only just went out but
>>
> thought I'd
>
>> just ping on this with regards to the 2.5.1 release that had been
>>
> mentioned.
>
> Anything new on this?
>
>
https://codereview.appspot.**com/6132056/<https://codereview.appspot.com/6132...
>