[gwt-contrib] Re: A couple more small tweaks to the gwt-incubator build target
LGTM.
One other change that we might want to make is to filter out the -aux
dirs from compiled-demo when building the zip. They're harmless but
extraneous.
On Tue, Dec 16, 2008 at 10:01 AM, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review these small extra changes to the gwt-incubator build
file?
Moving demo output to be a sibling of the generated javadocs. Both should
eventually be automatically posted on gwt-incubator's app engine demo site.
Adding a dependency on build.demos to dist, as we want the sanity check that
building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com wrote:
Good enough for me. Here's the patch for building demos off of the jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar /
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably should)
If project.src or project.bin was overridden, those changes should be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Will runAsync() be a right choice for modular projects?
On Tue, Dec 16, 2008 at 7:19 AM, Andrés Testi andres.a.te...@gmail.comwrote: I know this thread should be posted in the GWT developer group, but since runAsync() is planned for future releases, I think this group is a better place to post my question. I'm involved in a modular project, distributed as a core with dependencies, where the customer pays for aditional features (modules). Modules have UI interface and server logic, and are distributed as individual jars. I know the need to compile all modules in the same compilation process, but I want to know if is this a right architectural choice. One thing to note is that all the application will be available to the end user, and conceivably they could hack the generate JS code to remove any checks you might put in the client. Therefore, to be sure users don't run code for services they aren't paying for, you will either need to have every RPC call check to validate they should have access or figure out some way to restrict loading of fragments to only those users who have paid for it. I'm not sure how the code would map fragments to split points and split points to paid-for modules (especially if you might want to have runAsync inside a module as well as the main interface to the module), but it should be feasible. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A couple more small tweaks to the gwt-incubator build target
Can you add an issue for that? As it seems like we should probably sweep
through both jars and check for extraneous output.
Committed at r1323.
Cheers,
Emily
On Tue, Dec 16, 2008 at 10:26 AM, Isaac Truett itru...@gmail.com wrote:
LGTM.
One other change that we might want to make is to filter out the -aux
dirs from compiled-demo when building the zip. They're harmless but
extraneous.
On Tue, Dec 16, 2008 at 10:01 AM, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review these small extra changes to the gwt-incubator
build
file?
Moving demo output to be a sibling of the generated javadocs. Both
should
eventually be automatically posted on gwt-incubator's app engine demo
site.
Adding a dependency on build.demos to dist, as we want the sanity check
that
building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com
wrote:
Good enough for me. Here's the patch for building demos off of the
jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar
/
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com
wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is
actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably
should)
If project.src or project.bin was overridden, those changes should
be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running
first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Update to slider bar.
Daniel, Could you review this change? Focus Panel no longer sinks Focus, Key, or Mouse events by default. Therefore, adding a sink events call to SliderBar itself. Code: http://code.google.com/p/google-web-toolkit-incubator/source/detail?r=1322 Thanks, Emily -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: A couple more small tweaks to the gwt-incubator build target
Opened issue 209.
On Tue, Dec 16, 2008 at 10:52 AM, Emily Crutcher e...@google.com wrote:
Can you add an issue for that? As it seems like we should probably sweep
through both jars and check for extraneous output.
Committed at r1323.
Cheers,
Emily
On Tue, Dec 16, 2008 at 10:26 AM, Isaac Truett itru...@gmail.com wrote:
LGTM.
One other change that we might want to make is to filter out the -aux
dirs from compiled-demo when building the zip. They're harmless but
extraneous.
On Tue, Dec 16, 2008 at 10:01 AM, Emily Crutcher e...@google.com wrote:
Isaac,
Could you review these small extra changes to the gwt-incubator
build
file?
Moving demo output to be a sibling of the generated javadocs. Both
should
eventually be automatically posted on gwt-incubator's app engine demo
site.
Adding a dependency on build.demos to dist, as we want the sanity check
that
building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com
wrote:
Good enough for me. Here's the patch for building demos off of the
jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar
/
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com
wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is
actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired
(super
could be overridden if it used a variable, which it probably
should)
If project.src or project.bin was overridden, those changes should
be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running
first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
In answer to your question, yes, runAsync works, but no, there's no
test case. It would be great if there were, but I don't know how to
fit it into the JUnit infrastructure. It requires testing that an
async event eventually happens.
Can we talk some about the more general design of this feature,
though, before delving into the implementation? From what I
understand, it provides a way to do something that looks like a method
call but actually might run asynchronously. The implementation looks
like a clever way to work within what Java allows, by taking advantage
of compiler help.
My concern is that there were high hopes that the vast majority of
method calls in a program could actually be known-synchronous. The
problem is that for any operation that might happen asynchronously,
the developer needs to deal with both the lag before it happens and
the possibility it will fail. Doesn't this patch make these issues
hard to address? If you do a.b().c().d(), it is initially compact,
but how do you keep it compact once you add error handling and lag
handling? You seem to end up needing a callback for b(), c(), and d()
anyway.
The older thinking was that people would put async calls in just a few
places and arrange their code so that most of the code really is
synchronous. Those few places would then handle errors and lag.
Let me describe a coding pattern that achieves this, and then two
enhancements of it. I would love to know if you have tried these
patterns and what went wrong in practice. At the very least I'd like
to muse about updating the coding patterns to do better.
The basic idea is that the module provides its own async interface for
any caller that might be reached before the module has been loaded.
There are two parts to this async interface: an actual Java interface,
and a method that takes one as an argument.
In the simplest case, the Java interface is simply a subinterface of
RunAsyncCallback:
interface MyModuleCallback extends RunAsyncCallback { }
You can devise an alternative callback just as well, e.g. that passes
some objects back in the onSuccess handler. Assuming you use
RunAsyncCallback as is, the module would provide a method like this to
actually submit a callback:
class MyModule {
public void runAsync(MyModuleCallback callback) {
GWT.runAsync(callback);
}
}
That should be all that is needed. I would be very interested in how
this arrangement works out in practice.
The main issue I expect people to run into is that they might call the
async interface way more than necessary. They will see a lot of
coding contexts where it is unclear whether or not MyModule has ben
loaded, so they'll use the async interface just in case. If this is a
problem, I believe the underlying cause is not so much that the async
call is awkward, but that in too few cases the programmer has managed
to be sure that the module actually is already loaded. So the
question is, how do we help programmers prove to themselves that when
they think a module has loaded, it actually has?
One way would be to use an instance of class MyModule as exactly
equivalent to the module has been loaded. This is easily
implemented by only instantiating MyModule behind a runAsync. This is
easily reasoned about, too: any code that has an instance of MyModule
in scope is free to assume that MyModule has been loaded. It can then
make synchronous calls into MyModule.
Using this strategy, the code base will shift in the following ways:
1. Many classes take a MyModule as a constructor parameter. This lets
them call into MyModule synchronously, and it lets them instantiate
other classes that need a MyModule as a constructor parameter.
2. Likewise, many methods take a MyModule as a method parameter.
3. Entry points to the module become instance methods of MyModule.
This helps prevent accidents, because it's absolutely impossible to
call an instance method without an instance.
Note that 1 and 2 are not as wasteful as they might appear. The
pruner will remove the extra parameters if you don't use them.
Further, note that this coding style has the side benefit of making
code more modular: more stuff is on the instance side, and more code
is parameterized instead of grabbing stuff from global scope.
The second enhancement is to generalize to multiple classes instead of
just MyModule. If classes A, B, and C are all only instantiated once
MyModule is loaded, then you can also use an instance of A, B, or C as
a license to call synchronously into MyModule. Someone who
understands the module can document which classes are only
instantiated once the module is loaded.
Overall, I agree that runAsync is a bit low level. It requires that
people develop some sort of design patterns to use it effectively.
Let's do try and figure out some good coding patterns or some
higher-level wrappers that make it more accessible. As much as
possible, though, let's strive to make most method calls be
synchronous.
[gwt-contrib] Tree alignment issues
Reviewers: ecc, Description: Description: This patch addresses a bunch of Tree alignment issues: 1. RadioButtons and CheckBoxes do not align with other tree nodes because the GWT style sheet adds padding to them, AND because the browser adds a margin to these elements. 2. In RTL mode, leaf items do not have correct padding because we always set the padding on the left. 3. In RTL mode in IE, the focus element does not line up with the TreeItem because IE does not position the span correctly. Fixes: == 1. We now remove the padding of RadioButtons and Checkboxes when they are in a TreeItem. Also, we remove the browser margins added to the native input elements. In IE, the spacing around the native input is not a margin, so we use a negative margin to offset it. 2. We now check for RTL mode when adding the padding to the TreeItem. 3. I added zoom:1 to TreeItems in the RTL GWT theme style sheets, which corrects the problem in IE but doesn't affect other browsers. Testing: I updated VisualsForTree to include a TreeItem with a RadioButton and a TreeItem with a CheckBox, and verified alignment in all browsers, for all themes, in RTL and LTR mode. I also manually verified that the Showcase is unaffected by the change. I modified SingleIssue.gwt.xml to inherit all style theme resources, and I added the ar locale to make it easier to test RTL mode in general. Please review this at http://gwt-code-reviews.appspot.com/609 Affected files: reference/code-museum/src/com/google/gwt/museum/SingleIssue.gwt.xml reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForTree.java user/src/com/google/gwt/user/client/ui/Tree.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Tree alignment issues
Associated issues: http://code.google.com/p/google-web-toolkit/issues/detail?id=2854 http://code.google.com/p/google-web-toolkit/issues/detail?id=2859 http://gwt-code-reviews.appspot.com/609 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] A couple more small tweaks to the gwt-incubator build target
Isaac,
Could you review these small extra changes to the gwt-incubator build
file?
1. Moving demo output to be a sibling of the generated javadocs. Both
should eventually be automatically posted on gwt-incubator's app engine demo
site.
2. Adding a dependency on build.demos to dist, as we want the sanity
check that building the demos provides when we do a full distribution.
On Mon, Dec 15, 2008 at 5:21 PM, Isaac Truett itru...@gmail.com wrote:
Thanks. Committed as r1319.
On Mon, Dec 15, 2008 at 5:14 PM, Emily Crutcher e...@google.com wrote:
LGTM.
On Mon, Dec 15, 2008 at 4:51 PM, Isaac Truett itru...@gmail.com wrote:
Good enough for me. Here's the patch for building demos off of the jar:
Index: build.xml
===
--- build.xml (revision 1316)
+++ build.xml (working copy)
@@ -371,8 +371,7 @@
vmMaxMemory=${gwtc.vm.maxMemory}
classpath
path path=${gwtc.src.dir} /
-path path=${project.src} /
-path path=${project.bin} /
+path path=${project.jar} /
pathelement location=${gwt.user.jar} /
pathelement location=${gwt.dev.jar} /
pathelement location=${gwt.tools}/lib/w3c/sac/sac-1.3.jar /
Any objections?
On Mon, Dec 15, 2008 at 4:43 PM, Emily Crutcher e...@google.com wrote:
The reasons I would prefer to use the gwt-incubator.jar is because
that
gives us a quick sanity check that the gwt-incubator jar is actually
including everything needed to run the demos!
+ project.src and project.bin can be overridden, if desired (super
could be overridden if it used a variable, which it probably should)
If project.src or project.bin was overridden, those changes should be
reflected in the gwt-incubator jar, if they are not, that is
definitely
a
problem we would want to catch sooner rather then later.
+ build-demos doesn't depend on building a jar first
The gwt-incubator jar currently takes 12 seconds to compile on my
relatively
slow laptop, so depending upon the gwt-incubator build running first
does
not seem like it introduces an undue burden on the developer.
cheers,
Emily
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--
There are only 10 types of people in the world: Those who understand
binary, and those who don't
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
demobuild.patch
Description: Binary data
[gwt-contrib] Re: Tree alignment issues
Should we, in general, be adding padding to RadioButtons and CheckBoxes, as won't other users have the same problems? On Tue, Dec 16, 2008 at 11:40 AM, jlaba...@google.com wrote: Reviewers: ecc, Description: Description: This patch addresses a bunch of Tree alignment issues: 1. RadioButtons and CheckBoxes do not align with other tree nodes because the GWT style sheet adds padding to them, AND because the browser adds a margin to these elements. 2. In RTL mode, leaf items do not have correct padding because we always set the padding on the left. 3. In RTL mode in IE, the focus element does not line up with the TreeItem because IE does not position the span correctly. Fixes: == 1. We now remove the padding of RadioButtons and Checkboxes when they are in a TreeItem. Also, we remove the browser margins added to the native input elements. In IE, the spacing around the native input is not a margin, so we use a negative margin to offset it. 2. We now check for RTL mode when adding the padding to the TreeItem. 3. I added zoom:1 to TreeItems in the RTL GWT theme style sheets, which corrects the problem in IE but doesn't affect other browsers. Testing: I updated VisualsForTree to include a TreeItem with a RadioButton and a TreeItem with a CheckBox, and verified alignment in all browsers, for all themes, in RTL and LTR mode. I also manually verified that the Showcase is unaffected by the change. I modified SingleIssue.gwt.xml to inherit all style theme resources, and I added the ar locale to make it easier to test RTL mode in general. Please review this at http://gwt-code-reviews.appspot.com/609 Affected files: reference/code-museum/src/com/google/gwt/museum/SingleIssue.gwt.xml reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForTree.java user/src/com/google/gwt/user/client/ui/Tree.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Making show range fire on initial show.
Reviewers: jlabanca,
Description:
Fixes issue 3181
(http://code.google.com/p/google-web-toolkit/issues/detail?id=3181q=owner:ecc%20DatePicker)
by making the show range event fire at the correct time.
Please review this at http://gwt-code-reviews.appspot.com/610
Affected files:
user/src/com/google/gwt/event/logical/shared/ShowRangeEvent.java
user/src/com/google/gwt/user/datepicker/client/DatePicker.java
Index: user/src/com/google/gwt/event/logical/shared/ShowRangeEvent.java
===
--- user/src/com/google/gwt/event/logical/shared/ShowRangeEvent.java
(revision 4333)
+++ user/src/com/google/gwt/event/logical/shared/ShowRangeEvent.java
(working copy)
@@ -20,7 +20,8 @@
import com.google.gwt.event.shared.HasHandlers;
/**
- * Represents a show range event.
+ * Represents a show range event. This logical event should be used when a
+ * widget displays a range of values to the user.
*
* @param V the type of range
*/
Index: user/src/com/google/gwt/user/datepicker/client/DatePicker.java
===
--- user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(revision 4331)
+++ user/src/com/google/gwt/user/datepicker/client/DatePicker.java
(working
copy)
@@ -307,7 +307,7 @@
}
/**
- * Add a style name to the given dates.
+ * Add a style name to the given dates.
*/
public void addStyleToDates(String styleName, Date date) {
styler.setStyleName(date, styleName, true);
@@ -357,7 +357,7 @@
}
/**
- * Adds the given style name to the specified dates, which must be
visible.
+ * Adds the given style name to the specified dates, which must be
visible.
* This is only set until the next time the DatePicker is refreshed.
*/
public final void addTransientStyleToDates(String styleName,
@@ -459,6 +459,11 @@
return (date != null (first.equals(date) || last.equals(date) ||
(first.before(date) last.after(date;
}
+ @Override
+ public void onLoad() {
+ShowRangeEvent.fire(this, getFirstDate(), getLastDate());
+ }
+
/**
* Removes the styleName from the given dates (even if it is transient).
*/
@@ -605,13 +610,15 @@
/**
* Refreshes all components of this date picker.
- */
+ **/
protected final void refreshAll() {
highlighted = null;
getModel().refresh();
getView().refresh();
getMonthSelector().refresh();
-ShowRangeEvent.fire(this, getFirstDate(), getLastDate());
+if (isAttached()) {
+ ShowRangeEvent.fire(this, getFirstDate(), getLastDate());
+}
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Tree alignment issues
I don't know why I added the padding to begin with, so I'm fine with removing it after I try some common use cases to verify there isn't an obvious style issue. The padding has been in there since GWT 1.5, so I'm not sure we can just take it out as that would break existing styles. I can open a separate issue to track that, as it would take some time to test it and I'd like to get this patch in. Thanks, John LaBanca jlaba...@google.com On Tue, Dec 16, 2008 at 11:59 AM, Emily Crutcher e...@google.com wrote: Should we, in general, be adding padding to RadioButtons and CheckBoxes, as won't other users have the same problems? On Tue, Dec 16, 2008 at 11:40 AM, jlaba...@google.com wrote: Reviewers: ecc, Description: Description: This patch addresses a bunch of Tree alignment issues: 1. RadioButtons and CheckBoxes do not align with other tree nodes because the GWT style sheet adds padding to them, AND because the browser adds a margin to these elements. 2. In RTL mode, leaf items do not have correct padding because we always set the padding on the left. 3. In RTL mode in IE, the focus element does not line up with the TreeItem because IE does not position the span correctly. Fixes: == 1. We now remove the padding of RadioButtons and Checkboxes when they are in a TreeItem. Also, we remove the browser margins added to the native input elements. In IE, the spacing around the native input is not a margin, so we use a negative margin to offset it. 2. We now check for RTL mode when adding the padding to the TreeItem. 3. I added zoom:1 to TreeItems in the RTL GWT theme style sheets, which corrects the problem in IE but doesn't affect other browsers. Testing: I updated VisualsForTree to include a TreeItem with a RadioButton and a TreeItem with a CheckBox, and verified alignment in all browsers, for all themes, in RTL and LTR mode. I also manually verified that the Showcase is unaffected by the change. I modified SingleIssue.gwt.xml to inherit all style theme resources, and I added the ar locale to make it easier to test RTL mode in general. Please review this at http://gwt-code-reviews.appspot.com/609 Affected files: reference/code-museum/src/com/google/gwt/museum/SingleIssue.gwt.xml reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForTree.java user/src/com/google/gwt/user/client/ui/Tree.java user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- There are only 10 types of people in the world: Those who understand binary, and those who don't --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Making show range fire on initial show.
LGTM - but fix the Javadoc comment before submitting http://gwt-code-reviews.appspot.com/610/diff/1/3 File user/src/com/google/gwt/user/datepicker/client/DatePicker.java (right): http://gwt-code-reviews.appspot.com/610/diff/1/3#newcode613 Line 613: **/ Extra * in the JavaDoc? http://gwt-code-reviews.appspot.com/610 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
This patch adds an interface and a generator to build a thing called an AsyncProxy. What this allows you to do is to use a command-oriented API with runAsync and not have to have your calling code necessarily be aware of how or when the underlying implementation gets loaded with runAsync. It's designed for the case where you want something to happen at some point, but you don't really care about the exact timing, loading the implementation yourself, or managing a queue of outstanding calls to the implementation. The attached Hello.java and javadoc on AsyncProxy should cover most of the details, but the idea is that we can automatically generate an implementation of an interface that will lazily instantiate a concrete implementation via runAsync. Method calls on the proxy return immediately, but are queued up to pass onto the concrete instance. See @AllowNonVoid for the flag that makes non-void return types not-a-compile-error at the cost of your sanity, because they'll always return a default value. You have to opt into the strangeness of getters and setters maybe not quite working the way you think they should. This pattern would be even more awesome if Widget/Panel were factored out into an interface. @spoon: I'm having trouble getting the test to pass in web mode and there don't appear to be any test in user that use runAsync. Is this working yet? @koz: - I took our pair-programmed code from earlier today and addressed the outstanding TODOs in the generator, but it's basically the same. - Double-check that this still meets your requirements (note this is cc'd to the external list). Diffstat: src/com/google/gwt/user/AsyncProxy.gwt.xml | 18 18 + 0 - 0 ! src/com/google/gwt/user/User.gwt.xml|1 1 + 0 - 0 ! src/com/google/gwt/user/client/AsyncProxy.java | 137 137 + 0 - 0 ! src/com/google/gwt/user/client/impl/AsyncProxyBase.java | 126 126 + 0 - 0 ! src/com/google/gwt/user/rebind/AsyncProxyGenerator.java | 311 311 + 0 - 0 ! test/com/google/gwt/user/UISuite.java |2 2 + 0 - 0 ! test/com/google/gwt/user/client/AsyncProxyTest.java | 103 103 + 0 - 0 ! 7 files changed, 698 insertions(+) -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- async_proxy_r4303_r2.patch Description: Binary data Hello.java Description: Binary data
[gwt-contrib] Will runAsync() be a right choice for modular projects?
I know this thread should be posted in the GWT developer group, but since runAsync() is planned for future releases, I think this group is a better place to post my question. I'm involved in a modular project, distributed as a core with dependencies, where the customer pays for aditional features (modules). Modules have UI interface and server logic, and are distributed as individual jars. I know the need to compile all modules in the same compilation process, but I want to know if is this a right architectural choice. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
On Mon, Dec 15, 2008 at 4:09 AM, BobV b...@google.com wrote: I was trying to demonstrate the practical difference that runAsync would make when compared to a monolithic deployment to someone today, and there was no simple way to turn off runAsync that wasn't the -disableAggressiveOptimizations flag. This patch adds an undocumented flag -disableRunAsync that just disables code-splitting when compiling an app. FWIW, the *implementation* LGTM. The open question is about whether to keep it as a command-line option or go to a module-file solution. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: skip runAsync cruft when there is no call to runAsync
LGTM and the cruft is gone from my trivial app. thanks, /kel On Mon, Dec 8, 2008 at 5:32 PM, Lex Spoon sp...@google.com wrote: Kelly, Can you review the patch I attached to issue 3121? http://code.google.com/p/google-web-toolkit/issues/detail?id=3121 In particular, does it eliminate the cruft in the trivial app you initially tried with, and still leave the app working? Lex -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
[Redacted summary] AsyncProxy: - Less boilerplate code at the call sites and on the thing being async-loaded. - Centralized error handling while the concrete type is outstanding. - Better isolation of concrete types from calling environment, to give CodeSplitter more room to work. - Method invocation in a before-load situation is async / deferred either way; in a command-style API the return type is irrelevant to the caller. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: i faced a Serious problem in Gauge when using with GWT and Timer Concepts
Hello,
Hi saran,
The right place for this question would be the Visualization API Group.
There's a link here:
http://code.google.com/docreader/#p=gwt-google-apiss=gwt-google-apist=VisualizationFAQ
On Tue, Dec 16, 2008 at 4:52 AM, saran saranpa...@gmail.com wrote:
hi everyone
i am using GWT in my current project i have to display some values
using Gauge periodically . for that i used Timer class to get the
actual value from my database to be displayed in gauge and i created
a gauge by using the visualization plug-in for GWT(gwt-
visualization.jar 1.0) and i call that gauge creation method within
the timer
initially gauge is displaying the values by getting the values from
database. after for few seconds(10-15 sec) the gauge is invisible and
not displayed inside the tabpanel. But i steadily get the value from
the database .
i dont know the reasonplease send me the feedback and the
comments
here is my code
(Gauge creation method)
private Widget createGauge(int s) {
DataTable data = DataTable.create();
data.addColumn(ColumnType.STRING, Label);
data.addColumn(ColumnType.NUMBER, Value);
data.addRows(1);
data.setValue(0, 0, CPU(%));
data.setValue(0, 1, s);
Gauge.Options option = Gauge.Options.create();
option.setHeight(500);
option.setWidth(400);
option.setGreenRange(71, 80);
option.setMinorTicks(10);
option.setRedRange(81, 100);
option.setYellowRange(61, 70);
return new Gauge(data, option);
}
within the run method in timer class i call gauge creation method for
a period of seconds
--
Eric Z. Ayers - GWT Team - Atlanta, GA USA
http://code.google.com/webtoolkit/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
What's the reasoning for preferring deferred binding properties? I would think that a option to disable sharding globally is more appropriate as a compiler flag than as a module property. My thinking is that since a module encapsulates functionality, it should avoid causing global program changes, such as disabling sharding in other modules. I understand that linkers, which are configured as module properties, affect global program changes, but I'm not sure that is sufficient reason for further breaking encapsulation. Will adding this as a module property make it more difficult to drop XML module files in favor of annotations in the future? Regards, Sam On Tue, Dec 16, 2008 at 3:09 PM, Lex Spoon sp...@google.com wrote: On Mon, Dec 15, 2008 at 4:09 AM, BobV b...@google.com wrote: I was trying to demonstrate the practical difference that runAsync would make when compared to a monolithic deployment to someone today, and there was no simple way to turn off runAsync that wasn't the -disableAggressiveOptimizations flag. This patch adds an undocumented flag -disableRunAsync that just disables code-splitting when compiling an app. FWIW, the *implementation* LGTM. The open question is about whether to keep it as a command-line option or go to a module-file solution. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
Perhaps there might be cases where shard-vs-non-shard versions would have to be loaded by the selection script based on the environment. This could be due to container issues (social network containers), or more exotic scenarios like running code inside some Flash VM. I have already run into the former situation with Google Gadgets, where shards need to be either be loaded by the gadget container's proxy/cache, or via gadget.io.makeRequest(). The benefit of using deferred binding properties is that you can compile two seperate versions that load differently in different environments. To achieve the same effect with command line parameters, you need to use separate build scripts, deploy the artifacts to different URLs, use different host pages that source different selection scripts. For me personally, as someone who ships exported XS hosted GWT applications, the former has the following benefit: 1) I give my users 1 single URL, they script src=..., the selection script does the rest vs 2) I deploy multiple versions of my app to different URLs, and write extra documentation explaining to users when and where to pick each one. I am not too wedded to either approach, since I can deal with both. The big downside of using deferred binding is it would increase compilation times, which are already slow enough. -Ray On Tue, Dec 16, 2008 at 2:24 PM, Sam Gross colesb...@gmail.com wrote: What's the reasoning for preferring deferred binding properties? I would think that a option to disable sharding globally is more appropriate as a compiler flag than as a module property. My thinking is that since a module encapsulates functionality, it should avoid causing global program changes, such as disabling sharding in other modules. I understand that linkers, which are configured as module properties, affect global program changes, but I'm not sure that is sufficient reason for further breaking encapsulation. Will adding this as a module property make it more difficult to drop XML module files in favor of annotations in the future? Regards, Sam On Tue, Dec 16, 2008 at 3:09 PM, Lex Spoon sp...@google.com wrote: On Mon, Dec 15, 2008 at 4:09 AM, BobV b...@google.com wrote: I was trying to demonstrate the practical difference that runAsync would make when compared to a monolithic deployment to someone today, and there was no simple way to turn off runAsync that wasn't the -disableAggressiveOptimizations flag. This patch adds an undocumented flag -disableRunAsync that just disables code-splitting when compiling an app. FWIW, the *implementation* LGTM. The open question is about whether to keep it as a command-line option or go to a module-file solution. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : A compiler option to disable runAsync sharding
Back to Bob's patch: given that it is already useful as implemented, and a deferred binding approach would be yet more work on his plate, can we land that change and not hold it hostage to the more general conversation? rjrjr On Wed, Dec 17, 2008 at 9:33 AM, Ray Cromwell cromwell...@gmail.com wrote: Perhaps there might be cases where shard-vs-non-shard versions would have to be loaded by the selection script based on the environment. This could be due to container issues (social network containers), or more exotic scenarios like running code inside some Flash VM. I have already run into the former situation with Google Gadgets, where shards need to be either be loaded by the gadget container's proxy/cache, or via gadget.io.makeRequest(). The benefit of using deferred binding properties is that you can compile two seperate versions that load differently in different environments. To achieve the same effect with command line parameters, you need to use separate build scripts, deploy the artifacts to different URLs, use different host pages that source different selection scripts. For me personally, as someone who ships exported XS hosted GWT applications, the former has the following benefit: 1) I give my users 1 single URL, they script src=..., the selection script does the rest vs 2) I deploy multiple versions of my app to different URLs, and write extra documentation explaining to users when and where to pick each one. I am not too wedded to either approach, since I can deal with both. The big downside of using deferred binding is it would increase compilation times, which are already slow enough. -Ray On Tue, Dec 16, 2008 at 2:24 PM, Sam Gross colesb...@gmail.com wrote: What's the reasoning for preferring deferred binding properties? I would think that a option to disable sharding globally is more appropriate as a compiler flag than as a module property. My thinking is that since a module encapsulates functionality, it should avoid causing global program changes, such as disabling sharding in other modules. I understand that linkers, which are configured as module properties, affect global program changes, but I'm not sure that is sufficient reason for further breaking encapsulation. Will adding this as a module property make it more difficult to drop XML module files in favor of annotations in the future? Regards, Sam On Tue, Dec 16, 2008 at 3:09 PM, Lex Spoon sp...@google.com wrote: On Mon, Dec 15, 2008 at 4:09 AM, BobV b...@google.com wrote: I was trying to demonstrate the practical difference that runAsync would make when compared to a monolithic deployment to someone today, and there was no simple way to turn off runAsync that wasn't the -disableAggressiveOptimizations flag. This patch adds an undocumented flag -disableRunAsync that just disables code-splitting when compiling an app. FWIW, the *implementation* LGTM. The open question is about whether to keep it as a command-line option or go to a module-file solution. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
Bob, I had a question about this. Won't this create a separate JS fragment for each Proxy? It seems like people could use this in pathological ways, by being too fine-grained. At a certain size, the benefit of async-loading the Javascript would be washed out by the network overhead in loading it, so there's definately a sweet spot I think in how you use runAsync, in that you want it to shard enough JS out of one fragment, to boost subjective startup speed, but not pull in too much code such that the load latency is high. However, if the shards are too small, and you have a bunch of code that invokes a bunch in parallel, and waits for the results, you have lower efficiently doing N requests instead of 1 or 2 bigger ones. A pathological case can be seen in Microsoft's original Word Worm(?) Volta demo. They attempted to do code splitting automatically, but the result was like 100+ http requests for a trivial app. RunAsync definately is a tool that one can shoot oneself in the foot with, and I think we will need both SOYC tools and best current practice docs for developers advertising them how to wield it properly. :) -Ray On Tue, Dec 16, 2008 at 5:18 AM, BobV b...@google.com wrote: This patch adds an interface and a generator to build a thing called an AsyncProxy. What this allows you to do is to use a command-oriented API with runAsync and not have to have your calling code necessarily be aware of how or when the underlying implementation gets loaded with runAsync. It's designed for the case where you want something to happen at some point, but you don't really care about the exact timing, loading the implementation yourself, or managing a queue of outstanding calls to the implementation. The attached Hello.java and javadoc on AsyncProxy should cover most of the details, but the idea is that we can automatically generate an implementation of an interface that will lazily instantiate a concrete implementation via runAsync. Method calls on the proxy return immediately, but are queued up to pass onto the concrete instance. See @AllowNonVoid for the flag that makes non-void return types not-a-compile-error at the cost of your sanity, because they'll always return a default value. You have to opt into the strangeness of getters and setters maybe not quite working the way you think they should. This pattern would be even more awesome if Widget/Panel were factored out into an interface. @spoon: I'm having trouble getting the test to pass in web mode and there don't appear to be any test in user that use runAsync. Is this working yet? @koz: - I took our pair-programmed code from earlier today and addressed the outstanding TODOs in the generator, but it's basically the same. - Double-check that this still meets your requirements (note this is cc'd to the external list). Diffstat: src/com/google/gwt/user/AsyncProxy.gwt.xml | 18 18 + 0 - 0 ! src/com/google/gwt/user/User.gwt.xml|1 1 + 0 - 0 ! src/com/google/gwt/user/client/AsyncProxy.java | 137 137 + 0 - 0 ! src/com/google/gwt/user/client/impl/AsyncProxyBase.java | 126 126 + 0 - 0 ! src/com/google/gwt/user/rebind/AsyncProxyGenerator.java | 311 311 + 0 - 0 ! test/com/google/gwt/user/UISuite.java |2 2 + 0 - 0 ! test/com/google/gwt/user/client/AsyncProxyTest.java | 103 103 + 0 - 0 ! 7 files changed, 698 insertions(+) -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
On Tue, Dec 16, 2008 at 11:15 AM, Lex Spoon sp...@google.com wrote:
My concern is that there were high hopes that the vast majority of
method calls in a program could actually be known-synchronous. The
problem is that for any operation that might happen asynchronously,
the developer needs to deal with both the lag before it happens and
the possibility it will fail. Doesn't this patch make these issues
hard to address? If you do a.b().c().d(), it is initially compact,
but how do you keep it compact once you add error handling and lag
handling? You seem to end up needing a callback for b(), c(), and d()
anyway.
Okay, after talking with you on the phone I see I completely
misunderstood the idea. Normally, there would not be chaining of this
kind, and normally, people would be very careful about what methods
they mark as deferrable. Most frequently, these are fire and forget
kind of methods, such as show tab 3. They wouldn't be making
hundreds of these proxies, but a dozen or two, and they'll know that
they're getting a round-trip penalty for each one. I actually like
the coding pattern you are trying to support, now that I understand
it.
I'll review the implementation.
Design-wise, the main remaining question I have is about AllowNonVoid.
The main idea is that an existing interface could be reused with
minimal change. That's probably the most common way runAsync will be
used: on an existing app that has grown large. The issue is that
existing interfaces will have some methods that don't work as deferred
because they return some value. I believe the idea in the current
patch is for the generator to object by default, but to provide an
override that allows the interface to go through anyway. It will all
work so long as the callers can tolerate seeing the default value up
until the concrete implementation is actually loaded.
It looks a little better to me to encourage the idea of splitting
legacy interfaces into two parts: the half that is deferrable and the
half that is not. For example, given this legacy interface:
// old version
interface Adder {
void add(int i);
int getValue();
}
The two parts would be:
interface DeferrablePartOfAdder {
void add(int i);
}
interface Adder extends DeferrablePartOfAdder {
int getValue();
}
Only the deferrable part would have the deferred wrapper methods
generated. For the rest of the interface, callers would still have to
either use some sort of callback or ensure that an instance of Adder
is in scope. They wouldn't be stuck, but they wouldn't get to use the
boilerplate removal.
If we encouraged people to work that way, then there is less pressure
to have a big hammer that just makes an interface go through the
compiler. Instead, we could provide a little hammer and let people
annotate individual methods, like this:
interface Adder {
void setValue(int x);
@IfNotLoaded(-1)
int getValue();
}
This way also preserves the big hammer use case, but it's more
verbose. People just have to annotate each method individually.
What do you think about encouraging people to split their interfaces
like this? Even aside from the void returns, it seems like some
methods don't really work when deferred anyway.
-Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: RR : AsyncProxy to make deferred, command-oriented, runAsync'ed APIs easier
Initial implementation committed at r4347 for more general review with
a desk review of the implementation by Ray. I'll address any
follow-up reviews with a second commit.
Changes from previous patch:
- Added a @DefaultValue annotation to allow @AllowNonVoid getters to
return whatever value the developer wants.
- Expanded the test case to cover default values.
Further discussion below:
Design-wise, the main remaining question I have is about AllowNonVoid.
The main idea is that an existing interface could be reused with
minimal change. That's probably the most common way runAsync will be
used: on an existing app that has grown large. The issue is that
existing interfaces will have some methods that don't work as deferred
because they return some value. I believe the idea in the current
patch is for the generator to object by default, but to provide an
override that allows the interface to go through anyway. It will all
work so long as the callers can tolerate seeing the default value up
until the concrete implementation is actually loaded.
The developer has to explicitly opt into making non-void methods
work, because it does have the potential to cause undesired operation
in code that assumes that (o.setFoo(f); f == o.getFoo()) would always
hold true.
@IfNotLoaded(-1)
int getValue();
This was implemented as @DefaultValue(); it has value methods for all
primitive types.
What do you think about encouraging people to split their interfaces
like this? Even aside from the void returns, it seems like some
methods don't really work when deferred anyway.
I'd suggest a pattern like this
interface WorksWithDeferred {
setProperty(Object a);
// Basically cast-or-null operation, like in the AST
UseAfterInstantiation asUseAfterInstantiation();
}
interface UseAfterInstantiation extends WorksWithDeferred {
int getProperty();
}
class ConcreteType implements UseAfterInstantiation {
UseAfterInstantiation asUseAfterInstantiation() {
return this;
}
}
An AsyncProxyWorksWithDeferred will return null for the
asUseAfterInstantiation() call, while the concrete type can just
return this after it's instantiated. It avoids the need for awkward
narrowing casts which would fail if you were to try to cast the proxy
implementation. Consuming code can continue to be written against the
UserAfterImplementation interface instead of the concrete type.
--
Bob Vawter
Google Web Toolkit Team
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
