On 2012/05/31 01:56:32, skybrian wrote:
LGTM (assuming tests still pass)
Because I must confess I didn't run them on the last few patch-sets, I
just ran ant clean testrf and then the RequestFactorySuite in both
prod and dev mode from within Eclipse, and I confirm everything's OK.
LGTM (assuming tests still pass)
http://gwt-code-reviews.appspot.com/1601806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/05/25 21:43:28, sjostrand.jonas wrote:
When a proxy is edit()ed not only sub ENTITY proxies but also sub
VALUE proxies
are automatically edit()ed and considered as changed by the auto bean
diff. Can
this be fixed by the same technique? I tried the patch and it didn't
solve the
http://gwt-code-reviews.appspot.com/1601806/diff/45014/user/test/com/google/web/bindery/requestfactory/server/SimpleBar.java
File
user/test/com/google/web/bindery/requestfactory/server/SimpleBar.java
(right):
http://gwt-code-reviews.appspot.com/1601806/diff/40003/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
On 2012/05/23 10:08:59, tbroyer wrote:
http://gwt-code-reviews.appspot.com/1601806/diff/40003/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
http://gwt-code-reviews.appspot.com/1601806/diff/45014/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
http://gwt-code-reviews.appspot.com/1601806/diff/45014/user/test/com/google/web/bindery/requestfactory/server/SimpleBar.java
File
user/test/com/google/web/bindery/requestfactory/server/SimpleBar.java
(right):
Just a minor nit; otherwise LGTM.
http://gwt-code-reviews.appspot.com/1601806/diff/40003/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
On Friday, May 18, 2012 7:32:15 PM UTC+2, Brian Slesinsky wrote:
On Thu, May 17, 2012 at 5:30 PM, t.bro...@gmail.com wrote:
On 2012/05/17 22:52:23, skybrian wrote:
(one of the difficulties is that the only way to get at properties of an
AutoBean is to visit it, so I think we'd still
On Thu, May 17, 2012 at 5:30 PM, t.bro...@gmail.com wrote:
On 2012/05/17 22:52:23, skybrian wrote:
(one of the difficulties is that the only way to get at properties of an
AutoBean is to visit it, so I think we'd still need some flag to turn
off auto-editing of proxies on property retrieval)
On 2012/05/15 19:31:41, skybrian wrote:
More naive questions:
It seems like instead of having EntityProxy.equals() work in two
different ways,
we should inline AutoBeanUtils.diff() and simplify it to do exactly
what we want
for this case, without relying on Object.equals() if possible? We
Brian - thanks for the detailed questions. Your questions, and Thomas'
replies, have made me understand RequestFactory much better than I did
before. I was also curious about why EntityProxies had associations with
RequestContexts in some cases but not others.
On 2012/05/17 12:59:25, tbroyer
Okay, yeah, a TODO is fine as it looks kind of difficult. I see now that
we are calling ValueProxy.equals() which calls deepEquals(). Worse, when
AutoBeanUtils.diff() is called with a ValueProxy, it looks like we will
be doing a deep equality check twice. (For the fast check and again
for each
On 2012/05/17 22:52:23, skybrian wrote:
Okay, yeah, a TODO is fine as it looks kind of difficult.
OK, I'll create an issue, add a TODO referencing it and update the CL.
(one of the difficulties is that the only way to get at properties of an
AutoBean is to visit it, so I think we'd still need
On 2012/05/14 22:34:17, skybrian wrote:
I tried reviewing this but I'm missing some things. When can an
EntityProxy have
a null RequestContext? Aren't all entities created from a
RequestContext?
Immutable EntityProxies don't have a context (see
AbstractRequestContext#makeImmutable); this
This may be a naive question, but how are immutable entities supposed to
work with the RequestContext lifecycle?
I think the more normal approach is something like this:
- fetch an entity using a RequestContext
- start editing it
- commit it back, using the same RequestContext
Alternately you
Le 15 mai 2012 20:24, skybr...@google.com a écrit :
This may be a naive question, but how are immutable entities supposed to
work with the RequestContext lifecycle?
I think the more normal approach is something like this:
- fetch an entity using a RequestContext
- start editing it
-
Okay, so immutable here just means not editable, aka not checked out
for edit, in a source control sense.
http://gwt-code-reviews.appspot.com/1601806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
More naive questions:
It seems like instead of having EntityProxy.equals() work in two
different ways, we should inline AutoBeanUtils.diff() and simplify it to
do exactly what we want for this case, without relying on
Object.equals() if possible? We don't care what the diffs are and can
return
I've fix the test (I thought it was environmental, but it happened to be
a 2-char-long mistake: .to() instead of .fire(): the request was never
sent, so finishTestAndReset was never called (from the response)).
That wasn't an issue in JRE tests, where everything runs
synchronously; so the
Woohoo! Finally, everything passes!
http://gwt-code-reviews.appspot.com/1601806/diff/35001/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
I tried reviewing this but I'm missing some things. When can an
EntityProxy have a null RequestContext? Aren't all entities created from
a RequestContext?
Ok, the original failure we were looking at is gone! Yay! Now, two more
to deal with:
1)
testChangedEdit(com.google.web.bindery.requestfactory.gwt.client.RequestFactoryTest)java.lang.RuntimeException:
Remote test failed at 127.0.0.1 / Mozilla/5.0 (X11; U; Linux i686
(x86_64); en-US; rv:1.9.1.2)
On 2012/05/04 22:05:23, rdayal wrote:
Ok, more information - I'm only getting the failure when I run the
entire
RequestFactorySuite. Still digging, but can you tell me if you see a
failure if you run the entire suite?
Reproduced :-(
I also have a timeout in
OK, found it: the issue in EditorTest is that the SimpleBar that the
setUserName is applied to and the one in the SimpleFoo's barField are
not the same instances!
The instances are initialized in response to the finishTestAndReset call
from RequestBatcherTest, which explains the differing
I regularly (if not always) have a timeout in
RequestFactorytest#testChangedEdit, so we might have to bump
DELAY_TEST_FINISH (or refactory the test), but otherwise everything's OK
(running RequestFactorySuite in Eclipse) with patch-set #7.
http://gwt-code-reviews.appspot.com/1601806/
--
Depending on which targets are failing, we also run with FF3, which Thomas
most likely doesn't
On Mon Apr 30 11:10:32 GMT-400 2012, Rajeev Dayal rda...@google.com
wrote:
Thanks, Thomas. I'll take a look and see what's going on in our
environment. I wonder if it's an order-of-execution
Not saying there is, only that you should include it in the list of
possibilities. I sounds like Broyer only tested against HTMLUnit, and if
you're doing the normal things, you'll have also tested with a real
browser.
On Mon Apr 30 13:49:50 GMT-400 2012, Rajeev Dayal rda...@google.com
wrote:
On 2012/04/27 16:11:29, rdayal wrote:
Hey Thomas,
When I ran the tests after applying your change, I saw a failure in
EditorTest.test:
aused by: junit.framework.AssertionFailedError:
expected=EditorBarTest
actual=FOO
at
On 2012/04/29 10:42:26, tbroyer wrote:
On 2012/04/27 16:11:29, rdayal wrote:
Hey Thomas,
When I ran the tests after applying your change, I saw a failure in
EditorTest.test:
aused by: junit.framework.AssertionFailedError:
expected=EditorBarTest
actual=FOO
at
LGTM.
http://gwt-code-reviews.appspot.com/1601806/diff/1015/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
http://gwt-code-reviews.appspot.com/1601806/diff/1015/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
Hey Thomas,
When I ran the tests after applying your change, I saw a failure in
EditorTest.test:
aused by: junit.framework.AssertionFailedError: expected=EditorBarTest
actual=FOO
at
com.google.web.bindery.requestfactory.gwt.client.ui.EditorTest.onSuccess(EditorTest.java:164)
at
http://gwt-code-reviews.appspot.com/1601806/diff/1015/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
(right):
Generally looks good, just a couple of suggestions. Let's go one more
round on this.
http://gwt-code-reviews.appspot.com/1601806/diff/1015/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
I've applied the same technique to makePayloadOperations to slightly
reduce the request payload size (by removing false-positives in property
changes), as it's causing issues in our app.
It still, IMO, sends too many things in a request (every proxy
referenced by another proxy, even if not
37 matches
Mail list logo
