http://gwt-code-reviews.appspot.com/1799804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
This looks good, other than the corner case for a leaf that used to be a
parent.
http://gwt-code-reviews.appspot.com/1776803/diff/8001/user/src/com/google/gwt/user/cellview/client/CellTreeNodeView.java
File user/src/com/google/gwt/user/cellview/client/CellTreeNodeView.java
(right):
http://gwt-
Reviewers: atincheva,
Description:
Rename RoletypeRole to Role and improve the javadoc. Subtypes of Role
now
link to the ARIA specification.
Please review this at http://gwt-code-reviews.appspot.com/1799804/
Affected files:
M user/src/com/google/gwt/aria/client/AlertRole.java
M user/src/co
Reviewers: mdempsky,
Description:
Rename aria.Role to aria.RoleImpl and make private. (The next step will
be to
rename aria.RoletypeRole to aria.Role.)
Rationale: this hides the implemention so that it's not in the public
API,
and we can change the implementation more freely in future GWT releas
LGTM
http://gwt-code-reviews.appspot.com/1793806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: mdempsky,
Description:
Increase a test timeout to prevent testOldMethods() from failing when
run using emma, Firefox, and JDK 7.
(It would be interesting to know why this is slower, but I didn't track
down the root cause.)
Please review this at http://gwt-code-reviews.appspot.com/17
LGTM
http://gwt-code-reviews.appspot.com/1801803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/1800803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1800803/diff/1/user/test/com/google/gwt/core/public/script_injector_test_absolute.js
File
user/test/com/google/gwt/core/public/script_injector_test_absolute.js
(right):
http://gwt-code-reviews.appspot.com/1800803/diff/1/user/test/com/google/gwt/core/public/scr
Reviewers: cromwellian,
Description:
Increase a timeout in JsonpRequestSuite to see if it fixes a flaky test.
(It seems to help when running the tests by hand, but it's hard to
tell.)
Please review this at http://gwt-code-reviews.appspot.com/1798804/
Affected files:
M user/test/com/google/gw
On 2012/07/27 07:48:14, cromwellian wrote:
LGTM. Is this the only case? I would imagine there's probably many
tests that
were unknowingly dependent on the DOM being modified and left with
persistent
state between tests.
I don't know. My guess is that most tests don't care that there's other
Reviewers: cromwellian,
Description:
Fix UiSuite to pass when test methods are run in a different order.
The symptom was that many tests would fail, starting with
RootPanelTest.testGetById(). I don't know the root cause, but it seems
that
leaving a RichTextArea with focus in the RootPanel screwe
Thanks, that's gotten me reading the right code; before I couldn't even
find the SelectionChangeListener and now I see that it's in
HasDataPresenter.
So for this CL, I think we just assume rendering happens when it needs
to and update aria-selected (and other attributes) whenever a node gets
re-r
On 2012/07/26 07:02:08, tbroyer wrote:
I'm not against this kind of change but IMO any deviation from the
JSON and/or
ECMAScript specs should be documented, or we risk removing them at a
later time
and break things again (that being said, I don't understand what's
"broken" here
and how this
LGTM
http://gwt-code-reviews.appspot.com/1797803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: acleung,
Description:
Fix JSON escaping of unicode characters to work in JDK 7.
JDK 7 supports Unicode 6 and some characters changed:
- zero-width-space is no longer a whitespace character
- invisible-plus is new
This caused JSON encoding tests to fail in HTMLUnit somehow, so
escape
Reviewers: cromwellian,
Description:
Fix TestOracleMediatorFromByteCodeTest to work when run on JDK 7.
The issue is that java.lang.Throwable has nested classes in JDK 7 but
not JDK 6.
So, change the assertion to allow any nested classes.
Please review this at http://gwt-code-reviews.appspot.com
Thanks John.
On 2012/07/25 22:42:13, john.labanca wrote:
As far as issue 7480, it sounds like a bug. Updating the
SelectionModel should
update the CellTree's keyboard selection.
Well, the question is how to do this. I assume we install a
SelectionChangeHandler. However, we don't know how ma
Reviewers: cromwellian,
Description:
Fix TreeMap and TreeSet emulation tests to pass with JDK 7.
No changes to prod mode. In JavaScript, we will keep the somewhat more
lax
behavior of JDK 6. Developers moving to JDK 7 who rely on the JDK 6
TreeMap/TreeSet behavior will see new exceptions in dev
I'd like to get the untested tests into the test suite, but not if
they're broken or hanging. It sounds like a separate CL to me.
http://gwt-code-reviews.appspot.com/1786803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/07/24 23:19:54, cromwellian wrote:
I don't understand why the dual flags, but I would not make it a
proper
compiler flag because there are some static clinit inits in compiler
classes that need to know whether coverage is enabled when the classes
are
loaded.
I was thinking it would
http://gwt-code-reviews.appspot.com/1786805/diff/1/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
(right):
http://gwt-code-reviews.appspot.com/1786805/diff/1/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaSc
Thanks Alan.
http://gwt-code-reviews.appspot.com/1792803/diff/1/plugins/xpcom/JavaObject.h
File plugins/xpcom/JavaObject.h (right):
http://gwt-code-reviews.appspot.com/1792803/diff/1/plugins/xpcom/JavaObject.h#newcode55
plugins/xpcom/JavaObject.h:55: static void finalize(JSFreeOp* fop,
JSObjec
LGTM
http://gwt-code-reviews.appspot.com/1749803/diff/12001/dev/core/src/com/google/gwt/dev/javac/ProgressLogger.java
File dev/core/src/com/google/gwt/dev/javac/ProgressLogger.java (right):
http://gwt-code-reviews.appspot.com/1749803/diff/12001/dev/core/src/com/google/gwt/dev/javac/ProgressLog
Reviewers: mdempsky,
Description:
Super Dev Mode cleanup in preparation for doing more server-side HTML
rendering
(no user-visible changes)
- introduce HtmlWriter class
- change log file rendering to use it
- Move some code for handling generated file paths from SourceHandler to
ModuleState
Ple
http://gwt-code-reviews.appspot.com/1770804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java
File dev/codeserver/java/com/google/gwt/dev/codeserver/SourceMap.java
(right):
http://gwt-code-reviews.appspot.com/1770804/diff/1/dev/codeserver/java/com/google/gwt/dev/codeserver/
It looks like if you subclass DatePicker, you will be able to call this
method from your subclass. Will that work for you?
For an arbitrary DatePicker, making this method public won't help much
because the MonthSelector interface doesn't have any interesting
methods.
http://gwt-code-reviews.app
The code for CellTree is rather odd. There is a keyboard selection
policy with three values: DISABLED, ENABLED, and BOUND_TO_SELECTION.
If the policy is ENABLED or BOUND_TO_SELECTION then the CSS styles for
keyboard selection get updated, but the SelectionModel is only updated
when the policy is
On 2012/07/20 20:47:26, heinberg wrote:
Do you know how that works with unsupported attributes? Do they still
get set and just do nothing?
That's generally the case but I don't know about IE. I think think the
best way to find out is to run the tests.
There are four targets containing "DOMSuit
LGTM
http://gwt-code-reviews.appspot.com/1760804/diff/6001/user/src/com/google/gwt/user/cellview/client/CellTree.java
File user/src/com/google/gwt/user/cellview/client/CellTree.java (right):
http://gwt-code-reviews.appspot.com/1760804/diff/6001/user/src/com/google/gwt/user/cellview/client/Cell
On 2012/07/20 20:32:46, heinberg wrote:
Sweet, thanks! Do you know how I can exclude the tests from running
under IE9
and earlier?
Not offhand, but we don't need to exclude them unless they break. These
tests only check that the attribute gets set, right?
http://gwt-code-reviews.appspot.com
LGTM
(For the record, we're converting the cells from UIObject to Widget
because the keyboard events don't seem to be bubbling up for some
reason. If that's fixed then we can convert it back.)
http://gwt-code-reviews.appspot.com/1788803/diff/1/user/src/com/google/gwt/user/datepicker/client/Cal
Okay, if it doesn't break anything and single-file uploads still work, I
think we can add it with an appropriate warning. Something like:
"This setting has no effect in some browsers, including Internet
Explorer 9 and earlier."
- Brian
http://gwt-code-reviews.appspot.com/1786803/
--
http://gr
So one gotcha is that IE apparently doesn't support this attribute:
http://www.w3schools.com/html5/att_input_multiple.asp
I don't have a Windows box handy, but I did some web searches and
apparently that was still true in IE 9.
So I wonder if this is still useful for your use case? Historical
LGTM
http://gwt-code-reviews.appspot.com/1786803/diff/1/user/test/com/google/gwt/dom/DOMSuite.java
File user/test/com/google/gwt/dom/DOMSuite.java (right):
http://gwt-code-reviews.appspot.com/1786803/diff/1/user/test/com/google/gwt/dom/DOMSuite.java#newcode47
user/test/com/google/gwt/dom/DOMSu
Reviewers: mdempsky,
Description:
Fixes Super Dev Mode to work for a GWT app that uses the
PrecompileLinker
with precompress.leave.originals set to false. We look for a gzip file
and serve that instead. (Not implemented: uncompressing the file for
web clients that don't support gzip compression.)
LGTM
http://gwt-code-reviews.appspot.com/1765804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/1781803/diff/6001/user/test/com/google/gwt/user/client/ui/impl/ClippedImagePrototypeTest.java
File
user/test/com/google/gwt/user/client/ui/impl/ClippedImagePrototypeTest.java
(right):
http://gwt-code-reviews.appspot.com/1781803/diff/6001/user/test/com/g
Seems reasonable. Could you add a test in ClippedImagePrototypeTest?
http://gwt-code-reviews.appspot.com/1781803/diff/1/user/src/com/google/gwt/user/client/ui/impl/ClippedImagePrototype.java
File
user/src/com/google/gwt/user/client/ui/impl/ClippedImagePrototype.java
(right):
http://gwt-code-re
On 2012/07/16 20:04:42, isbadawi wrote:
Since merge is only called in merge_coverage and merge_coverage is
only called
in the handler, they can be local functions like this.
Oops! Somehow I misread this code. Sorry about that!
LGTM
http://gwt-code-reviews.appspot.com/1780803/
--
http://gr
LGTM
http://gwt-code-reviews.appspot.com/1735804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1780803/diff/1/dev/core/src/com/google/gwt/dev/js/coverage.js
File dev/core/src/com/google/gwt/dev/js/coverage.js (right):
http://gwt-code-reviews.appspot.com/1780803/diff/1/dev/core/src/com/google/gwt/dev/js/coverage.js#newcode17
dev/core/src/com/google/gwt/d
LGTM
http://gwt-code-reviews.appspot.com/1764803/diff/6003/dev/core/src/com/google/gwt/dev/js/BaselineCoverageGatherer.java
File dev/core/src/com/google/gwt/dev/js/BaselineCoverageGatherer.java
(right):
http://gwt-code-reviews.appspot.com/1764803/diff/6003/dev/core/src/com/google/gwt/dev/js/Bas
Seems reasonable. Could you write a test to make sure it continues to
work?
http://gwt-code-reviews.appspot.com/1765804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: acleung,
Description:
Adds directory listings for the source files served by Super Dev Mode.
This makes it easier to browse source code when you're not using the
Chrome debugger.
There are two new page types:
- A page for each module that lists all the directories containing at
least o
http://gwt-code-reviews.appspot.com/1776803/diff/1/user/src/com/google/gwt/user/cellview/client/CellTree.java
File user/src/com/google/gwt/user/cellview/client/CellTree.java (right):
http://gwt-code-reviews.appspot.com/1776803/diff/1/user/src/com/google/gwt/user/cellview/client/CellTree.java#new
Also, in the official documentation, we don't put doctypes on module
files.
https://gwt-code-reviews.appspot.com/1772803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
On 2012/07/09 15:30:02, tbroyer wrote:
A small one for your last day guys.
Seems fine to me. But I wonder if we're just hiding some underlying
issue with the XML parser we're using. There's no particular reason why
development mode should be downloading DTD's, even if users put them in
their gw
LGTM
http://gwt-code-reviews.appspot.com/1768804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1767803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: acleung,
Description:
Minor cleanup of Super Dev Mode: move some static methods to a separate
class.
Please review this at http://gwt-code-reviews.appspot.com/1767803/
Affected files:
A dev/codeserver/java/com/google/gwt/dev/codeserver/PageUtil.java
M dev/codeserver/java/com/goo
Reviewers: rdayal,
Description:
Convert dynatable sample to use GWT-RPC instead of DeRPC.
Workaround for issue 7453.
Please review this at http://gwt-code-reviews.appspot.com/1759803/
Affected files:
M samples/dynatable/src/com/google/gwt/sample/dynatable/DynaTable.gwt.xml
M
samples/dyn
I don't have time to try it out right now, but here are a few things.
http://gwt-code-reviews.appspot.com/1749803/diff/9001/dev/core/src/com/google/gwt/dev/javac/ProgressLogger.java
File dev/core/src/com/google/gwt/dev/javac/ProgressLogger.java (right):
http://gwt-code-reviews.appspot.com/1749
On 2012/06/21 19:58:13, acleung wrote:
LGTM. Could you also create a GWT Issue?
http://gwt-code-reviews.appspot.com/1754803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Seems fine in principle. What does this look like in context, when there
are also compile warnings or errors?
It might be nice to log the total compilation time as well.
http://gwt-code-reviews.appspot.com/1749803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM
http://gwt-code-reviews.appspot.com/1750803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Looks good as far as it goes.
http://gwt-code-reviews.appspot.com/1741804/diff/1/user/test/com/google/gwt/dev/jjs/test/CoverageTest.java
File user/test/com/google/gwt/dev/jjs/test/CoverageTest.java (right):
http://gwt-code-reviews.appspot.com/1741804/diff/1/user/test/com/google/gwt/dev/jjs/test
LGTM. It looks like this was already fixed for the google build, so it's
purely an open source change.
https://gwt-code-reviews.appspot.com/1741803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM. I commented on some issues to fix in later patches.
http://gwt-code-reviews.appspot.com/1727808/diff/16001/distro-source/build.xml
File distro-source/build.xml (right):
http://gwt-code-reviews.appspot.com/1727808/diff/16001/distro-source/build.xml#newcode39
distro-source/build.xml:39:
I
I verified that the ant build and google builds both work. The ant build
takes about 9 minutes with this change, versus about 5:30 before. Also,
elemental gets a full rebuild each time so a no-op build now takes about
4:30.
https://gwt-code-reviews.appspot.com/1727808/
--
http://groups.google.co
Reviewers: acleung,
Description:
Fix Super Dev Mode's code server to launch on localhost by default.
(There were comments about this but it wasn't actually true.)
Add -bindAddress option to override this. In particular, -bindAddress
0.0.0.0
restores previous behavior.
Please review this at http
https://gwt-code-reviews.appspot.com/1727808/diff/8001/build.xml
File build.xml (right):
https://gwt-code-reviews.appspot.com/1727808/diff/8001/build.xml#newcode41
build.xml:41:
I asked Ray about this. Elemental is experimental and its build process
is rather interesting (and probably not very
LGTM
http://gwt-code-reviews.appspot.com/1731806/diff/1/dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java
File dev/core/test/com/google/gwt/dev/jjs/impl/EnumOrdinalizerTest.java
(right):
http://gwt-code-reviews.appspot.com/1731806/diff/1/dev/core/test/com/google/gwt/dev/jjs/imp
LGTM. I'll submit this.
On 2012/06/14 07:32:40, tbroyer wrote:
because gwt-user
has no declared dependency on gwt-dev (this might be a mistake, or
not)
I'm guessing this is because we don't want GWT user code to have
dependencies on classes that should only be used in the compiler.
https://
Reviewers: cromwellian,
Description:
Include json-1.5.jar in gwt-dev.jar. JSON is needed by the Closure
compiler and also to generate source maps.
Fixes issue 7397
Please review this at http://gwt-code-reviews.appspot.com/1732804/
Affected files:
M dev/build.xml
M dev/codeserver/build.xml
LGTM
It seems like we should also change the web implementation to behave
like JDK 7. But that can wait.
http://gwt-code-reviews.appspot.com/1735805/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I'm getting failing tests because JSON is gone from gwt-user.jar and the
requestfactory jars. I could add the dependency internal to google, but
I think we might still be trying to do too much at once - this is
looking more like churn than an actual improvement.
To fix the compiler and close issu
LGTM. I can understand the code now and I'm basically okay with it; the
rest is nitpicks.
http://gwt-code-reviews.appspot.com/1727807/diff/15003/user/src/com/google/gwt/editor/client/impl/SimpleViolation.java
File user/src/com/google/gwt/editor/client/impl/SimpleViolation.java
(right):
http://
Okay, seems fine for now. I'm going to commit this.
https://gwt-code-reviews.appspot.com/1731804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I mostly looked over the build process. (Since this is experimental, I
suppose it can all be done later.)
http://gwt-code-reviews.appspot.com/1728806/diff/1/elemental/META-INF/MANIFEST.MF
File elemental/META-INF/MANIFEST.MF (right):
http://gwt-code-reviews.appspot.com/1728806/diff/1/elemental/M
http://gwt-code-reviews.appspot.com/1735804/diff/1/user/src/com/google/gwt/resources/css/SubstitutionReplacer.java
File user/src/com/google/gwt/resources/css/SubstitutionReplacer.java
(right):
http://gwt-code-reviews.appspot.com/1735804/diff/1/user/src/com/google/gwt/resources/css/SubstitutionRe
LGTM
https://gwt-code-reviews.appspot.com/1729805/diff/1/user/test/com/google/web/bindery/requestfactory/apt/EntityProxyCheckDomainMapping.java
File
user/test/com/google/web/bindery/requestfactory/apt/EntityProxyCheckDomainMapping.java
(right):
https://gwt-code-reviews.appspot.com/1729805/diff/
http://gwt-code-reviews.appspot.com/1727807/diff/7/user/src/com/google/gwt/editor/client/impl/SimpleViolation.java
File user/src/com/google/gwt/editor/client/impl/SimpleViolation.java
(right):
http://gwt-code-reviews.appspot.com/1727807/diff/7/user/src/com/google/gwt/editor/client/impl/SimpleVio
I don't understand this code, but I wonder if there is any way to write
a smoke test for soyc?
http://gwt-code-reviews.appspot.com/1726803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
http://gwt-code-reviews.appspot.com/1727807/diff/8001/user/src/com/google/gwt/editor/client/impl/DelegateMap.java
File user/src/com/google/gwt/editor/client/impl/DelegateMap.java
(right):
http://gwt-code-reviews.appspot.com/1727807/diff/8001/user/src/com/google/gwt/editor/client/impl/DelegateMap
http://gwt-code-reviews.appspot.com/1727807/diff/8001/user/src/com/google/gwt/editor/client/impl/DelegateMap.java
File user/src/com/google/gwt/editor/client/impl/DelegateMap.java
(right):
http://gwt-code-reviews.appspot.com/1727807/diff/8001/user/src/com/google/gwt/editor/client/impl/DelegateMap
http://gwt-code-reviews.appspot.com/1727803/diff/4003/user/src/com/google/gwt/resources/css/RtlVisitor.java
File user/src/com/google/gwt/resources/css/RtlVisitor.java (right):
http://gwt-code-reviews.appspot.com/1727803/diff/4003/user/src/com/google/gwt/resources/css/RtlVisitor.java#newcode46
us
Moving org.json into gwt-dev makes sense because the compiler actually
uses it. I'd like to see it repackaged, but perhaps we can wait until
someone complains?
I'm not sure about validation. Many people don't use it and I sorta
think GWT's validation support ought to be split out of gwt-user into
LGTM. Thanks!
https://gwt-code-reviews.appspot.com/1734803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Ray, you can see the diffs by looking at internal code review. I updated
a bunch of javadoc, tweaked Recompiler to deal with running with a
different linker, and changed the regexps in WebServer to be slightly
tighter and a bit more readable. But sure, basically the same.
http://gwt-code-review
http://gwt-code-reviews.appspot.com/1727804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Reviewers: cromwellian,
Description:
Move Super Dev Mode to the open source repository.
Includes a simple "demo" target that works with the "Hello" sample app.
I've also made some linker options configurable, as necessary to make
this work.
Review by: cromwell...@google.com
Please review this at
LGTM (assuming tests still pass)
http://gwt-code-reviews.appspot.com/1601806/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
I got this feedback from someone who requested a rollback but decided to
work around it instead. I wonder how widespread this sort of thing is?
"Our use of the editor/driver stuff assumed the editors would be
rebuilt when driver.edit(T) was invoked. This isn't true with this CL,
as the point of t
On 2012/05/26 15:20:15, tbroyer wrote:
On 2012/05/25 19:35:47, skybrian wrote:
> Having two levels of class nesting is rather confusing. Could you
move the
> Driver and other 4 inner classes up a level?
Done.
Do you think the Intern/Manager/Department should be moved to
top
On 2012/05/26 23:09:03, tbroyer wrote:
(the use OperationMessage here can already be seen as a "hack", kind
of, because all we need is a Map for the storage,
and a String for the version; so using another field in some "diverted"
way is not really a problem I think)
Oh yuck. Yeah, OperationMess
LGTM. (Some optional nitpicks.)
It seems a little odd that you'd want to do this. I'd expect that the
subtype (Manager or Intern) would have additional fields to edit, so you
wouldn't be able to just reuse the editor for the parent type. But it
should still be allowed.
http://gwt-code-reviews.
/bindery/requestfactory/server/SimpleBar.java#newcode95
user/test/com/google/web/bindery/requestfactory/server/SimpleBar.java:95:
public static SimpleBar returnFirst(List list) {
On 2012/05/24 00:28:11, tbroyer wrote:
On 2012/05/23 18:05:24, skybrian wrote:
> It's weird that this method isn't
LGTM
http://gwt-code-reviews.appspot.com/1712804/diff/1/samples/showcase/src/com/google/gwt/sample/showcase/client/content/lists/CwTree.java
File
samples/showcase/src/com/google/gwt/sample/showcase/client/content/lists/CwTree.java
(right):
http://gwt-code-reviews.appspot.com/1712804/diff/1/sam
http://gwt-code-reviews.appspot.com/1622803/diff/6001/user/src/com/google/web/bindery/requestfactory/shared/DefaultProxyStore.java
File
user/src/com/google/web/bindery/requestfactory/shared/DefaultProxyStore.java
(right):
http://gwt-code-reviews.appspot.com/1622803/diff/6001/user/src/com/google/
I'm fine with the production code. This is mostly nitpicks, except that
we need to make sure that the code in RequestPayloadTest is actually
run.
http://gwt-code-reviews.appspot.com/1601806/diff/45014/user/src/com/google/web/bindery/requestfactory/shared/impl/AbstractRequestContext.java
File
us
I've read about Places and PlaceTokenizers and I'm a bit confused. It
looks like the generated PlaceHistoryMapper does a bunch of instanceof
checks on a passed-in Place to figure out which tokenizer to use to
create the token. So if we have multiple PlaceTokenizers with the same
Place type paramet
LGTM
http://gwt-code-reviews.appspot.com/1707804/diff/1/user/src/com/google/gwt/cell/client/ButtonCellBase.java
File user/src/com/google/gwt/cell/client/ButtonCellBase.java (right):
http://gwt-code-reviews.appspot.com/1707804/diff/1/user/src/com/google/gwt/cell/client/ButtonCellBase.java#newco
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 p
Oops, I had started an email about the revert but apparently never sent
it. Sorry about that!
I might need some background about the editor framework...
https://gwt-code-reviews.appspot.com/1664803/diff/4002/user/src/com/google/gwt/editor/client/adapters/ListEditor.java
File user/src/com/googl
LGTM
http://gwt-code-reviews.appspot.com/1707803/diff/6001/user/src/com/google/gwt/view/client/OrderedMultiSelectionModel.java
File user/src/com/google/gwt/view/client/OrderedMultiSelectionModel.java
(right):
http://gwt-code-reviews.appspot.com/1707803/diff/6001/user/src/com/google/gwt/view/cli
https://gwt-code-reviews.appspot.com/1674804/diff/1/user/src/com/google/gwt/place/rebind/PlaceHistoryGeneratorContext.java
File
user/src/com/google/gwt/place/rebind/PlaceHistoryGeneratorContext.java
(right):
https://gwt-code-reviews.appspot.com/1674804/diff/1/user/src/com/google/gwt/place/rebind
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 ea
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
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 c
101 - 200 of 275 matches
Mail list logo
