[gwt-contrib] Re: Getting available TimeZones, Detecting Timezones?
And what in the case that the application is not running on the internet ? In banking software chances are very slim that the PC is connected. David On Sat, Apr 4, 2009 at 1:58 AM, Ray Cromwell cromwell...@gmail.com wrote: John, A google hosted service would be great, sounds like a good, valuable service, of use to everyone on the web. I don't mind asynchronously fetching this data, because you typically have to ask the user which TZ he's in anyway, unless you try to infer it from the browser's Date.toString() method, which isn't always reliable. (Some browsers report actual TZ Common names, others don't) -Ray On Fri, Apr 3, 2009 at 4:34 PM, John Tamplin j...@google.com wrote: On Fri, Apr 3, 2009 at 7:28 PM, Ray Cromwell cromwell...@gmail.comwrote: Am I missing something? There doesn't appear to be a way to query for all of the supported Common Timezones, which makes it problematic to construct a UI dialog that asks the user to specify a TimeZone without hard coding. Simple Timezones have the problem that they don't provide DST information, which makes the behavior of DateTimeFormat wrong in some TZs. I'm wondering if it makes sense to either 1) provide a default RPC service for obtaining TZ related info (localized), or revisit the issue of providing full TZ introspection using code splitting to reduce some of the inefficiency. Work is in progress to provide a JSONP service, either provided by Google or where you can run a servlet on your own infrastructure, and fetch the timezone data that way. It is too large in its current form to include in the compiled output (though we may be able to improve that for certain common cases in the future) and the async nature of the interface means it won't be transparent to user code, but it should be out for review shortly. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting available TimeZones, Detecting Timezones?
On Mon, Apr 6, 2009 at 2:40 AM, David david.no...@gmail.com wrote: And what in the case that the application is not running on the internet ? In banking software chances are very slim that the PC is connected. The data could be compiled into the application, but it would be large. It could also be stored in Gears or HTML5 databases. It seems hard to imagine a client application of much use without any connection to a server. If it is on a private network, the servlet could be run on private infrastructure as mentioned. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: weak listener in GWT?
Hi Hiho, Thanks for your reaction. I don't want to sound (too) arrogant, but your solution is way to simple in my case (I wish I could use it). Because of the complex requirements I have to meet, I have several layers on top of basic widgets. That is: on the level I want to do some cleanup, these widgets are way out of scope (and I have too many widgets below). That is also desired behavior as on the level I want to do some cleanup, I don't want to directly see these widgets anymore as I am in another problem scope. I did some more prototyping and even my above suggestion doesn't solve my problem entirely as I sometimes want to remove part of the listeners that belong to a category. What I will do now: Like explained above: I have my own Form that contains Form field (these are the ones that wrap the basic widgets). These form fields (general gwt things) contain all kind of default behavior: validation, dirty checking, resetting, validation handling, etc.. (I have all kind of general form field for strings, birthday, datepicker, group of checkboxes, etc...) I will add a method to the Form field beforeRemove () that will always called by his managing Form just before removing (detaching) the form field of the Form, that gives the form field a change to do some cleanup. That is: when removing widgets/form field of the Form, I always do this trhough the manging Form. I will then add an extra method to the form field: addRemover (HasDestroy destroy), such that I can add things that need to be called by the Form field when beforeRemove() is called. In my builder I can then add instances to the Form field that need to do some cleanup. I think this is an elegant and nice solution, don't you think ? Da, I do miss the Weak Listener from SWT/Swing in cases like this... (It's back to the stoneage to do everyting yourself. Btw: don't get me wrong, I am not blaming GWT for this it's simple javascript that doesn't support this all) I would love to hear experiences of other developers have bounced their head against this issue. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: JSO patch to use desiredAssertionStatus
Very close, but I think the Java optimizer won't be able to figure that out
as early as we'd like.
How about something like this?
public final String toString() {
return JavaScriptObject.class.desiredAssertionStatus() ?
toStringVerbose()? : toStringSimple();
}
On Mon, Apr 6, 2009 at 1:48 AM, Freeland Abbott fabb...@google.com wrote:
Scott,
is this what you were suggesting, to lighten JavaScriptObject.toString()
for micro-apps?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: code review requested - allow OpenJDK to compile GWT
On Mon, Apr 6, 2009 at 9:07 AM, BobV b...@google.com wrote: Here is the patch which does what Scott suggested. Any objections? LGTM Thanks, committed with Scott's javadoc change at r5184. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add StyleInjector to GWT trunk
StyleInjector committed to trunk at r5185. @RayC, I added an assertion that there is a head tag. @RayR, The line lengths seem to be ok according to the eclipse formatting rules checked into trunk. I added notes to the Javadoc indicating that not all StyleElements returned are necessarily unique and that setContents should be used with caution. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5184 - Fix OpenJDK compatibility (a generic type inference bug) by removing the
Author: j...@google.com
Date: Mon Apr 6 06:27:37 2009
New Revision: 5184
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
Log:
Fix OpenJDK compatibility (a generic type inference bug) by removing the
ability to return a different type than is requested. None of our code
uses this ability, and it is easy enough to copy the returned list into a
list of the supertype externally anyway.
Issue: 3058
Patch by: jat
Review by: scottb, bobv
Modified: trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
==
--- trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java
(original)
+++ trunk/dev/core/src/com/google/gwt/core/ext/linker/ArtifactSet.java Mon
Apr 6 06:27:37 2009
@@ -61,35 +61,30 @@
return treeSet.containsAll(c);
}
+ @Override
public boolean equals(Object o) {
return treeSet.equals(o);
}
/**
* Find all Artifacts assignable to some base type. The returned value
will be
- * a snapshot of the values in the ArtifactSet. The following two
examples
- * result in an equivalent set:
+ * a snapshot of the values in the ArtifactSet. An example of how this
could
+ * be used:
*
* pre
- * SortedSetlt;EmittedArtifactgt; search =
artifactSet.find(PublicResource.class);
- * search.addAll(artifactSet.find(GeneratedResource.class);
+ * for (EmittedArtifact ea : artifactSet.find(EmittedArtifact.class)) {
+ * ...
+ * }
* /pre
*
- * or
- *
- * pre
- * SortedSetlt;EmittedArtifactgt; search =
artifactSet.find(EmittedArtifact.class);
- * /pre
- *
- * @param A a type bound possibly wider than the desired type of
artifact
* @param T the desired type of Artifact
* @param artifactType the desired type of Artifact
* @return all Artifacts in the ArtifactSet assignable to the desired
type
*/
- public A extends Artifact?, T extends A SortedSetA find(
+ public T extends Artifact? super T SortedSetT find(
ClassT artifactType) {
// TODO make this sub-linear (but must retain order for
styles/scripts!)
-SortedSetA toReturn = new TreeSetA();
+SortedSetT toReturn = new TreeSetT();
for (Artifact? artifact : this) {
if (artifactType.isInstance(artifact)) {
toReturn.add(artifactType.cast(artifact));
@@ -113,6 +108,7 @@
}
}
+ @Override
public int hashCode() {
return treeSet.hashCode();
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5186 - Edited wiki page through web user interface.
Author: b...@google.com Date: Mon Apr 6 07:41:16 2009 New Revision: 5186 Modified: wiki/ClientBundle.wiki Log: Edited wiki page through web user interface. Modified: wiki/ClientBundle.wiki == --- wiki/ClientBundle.wiki (original) +++ wiki/ClientBundle.wiki Mon Apr 6 07:41:16 2009 @@ -23,3 +23,4 @@ * `CssResource.enableMerge` to `CssResource.mergeEnabled` * `CssResource.forceStrict` to `CssResource.strictAccessors` * `CssResource.globalPrefix` to `CssResource.obfuscationPrefix` + * StyleInjector moved to `com.google.gwt.dom.client` package \ No newline at end of file --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: shorten filenames for SOYC reports
I guess I should actually include the patch. Here it is: http://gwt-code-reviews.appspot.com/16802/show -Lex On Fri, Apr 3, 2009 at 6:30 PM, Lex Spoon sp...@google.com wrote: Bob, can you review this patch for me? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5187 - Edited wiki page through web user interface.
Author: b...@google.com
Date: Mon Apr 6 08:51:55 2009
New Revision: 5187
Modified:
wiki/ClientBundle.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/ClientBundle.wiki
==
--- wiki/ClientBundle.wiki (original)
+++ wiki/ClientBundle.wiki Mon Apr 6 08:51:55 2009
@@ -1,13 +1,110 @@
#summary Compile-time resource optimizations
-TODO(bobv): Copy wiki articles from incubator to here; cross-link the pages
+wiki:toc /
-= Migrating from ImmutableResourceBundle =
+= Introduction =
+
+ The resources in a deployed GWT application can be roughly categorized
into resources to never cache `.nocache.js`, to cache forever
`.cache.html`, and everything else `myapp.css`. The ClientBundle interface
moves entries in the everything-else category into the cache-forever
category.
+
+= Goals =
+
+ * No more uncertainty if your application is getting the right contents
for program resources.
+ * Decrease non-determinism caused by intermediate proxy servers.
+ * Enable more aggressive caching headers for program resources.
+ * Eliminate mismatches between physical filenames and constants in Java
code by performing consistency checks during the compile.
+ * Use 'data:' URLs, JSON bundles, or other means of embedding resources
in compiled JS when browser- and size-appropriate to decrease the number of
round-trips entirely.
+ * Provide an extensible design for adding new resource types.
+ * Ensure there is no penalty for having multiple ClientBundle resource
functions refer to the same content.
+
+= Non-Goals =
+
+ * To provide a file-system abstraction
+
+= Examples =
+
+To use the ClientBundle, add an inherits tag to your `gwt.xml` file:
+{{{
+inherits name=com.google.gwt.resources.Resources /
+}}}
+
+Interfaces:
+{{{
+public interface MyResources extends ClientBundle {
+ public static final MyResources INSTANCE =
GWT.create(MyResources.class);
+
+ @Source(my.css)
+ public CssResource css();
+
+ @Source(config.xml)
+ public TextResource initialConfiguration();
+
+ @Source(manual.pdf)
+ public DataResource ownersManual();
+}
+}}}
+
+You can then say:
+{{{
+ Window.alert(MyResources.INSTANCE.css().getText());
+ new Frame(MyResources.INSTANCE.ownersManual().getURL());
+}}}
+
+= I18N =
+
+ClientBundle is compatible with GWT's I18N module.
+
+Suppose you defined a resource:
+{{{
+...@source(default.txt)
+public TextResource defaultText();
+}}}
+
+For each possible value of the `locale` deferred-binding property, the
ClientBundle generator will look for variations of the specified filename
in a manner similar to that of Java's `ResourceBundle`.
+
+Suppose the `locale` were set to `fr_FR`. The generator would look for
files in the following order:
+ # default_fr_FR.txt
+ # default_fr.txt
+ # default.txt
+
+This will work equally well with all resource types, which can allow you
to provide localized versions of other resources, say `ownersManual_en.pdf`
versus `ownersManual_fr.pdf`.
+
+= Pluggable Resource Generation =
+
+Each subtype of `ResourcePrototype` must define a `...@resourcegenerator`
annotation whose value is a concrete Java class that extends
`ResourceGenerator`. The instance of the `ResourceGenerator` is
responsible for accumulation (or bundling) of incoming resource data as
well as a small degree of code generation to assemble the concrete
implementation of the ClientBundle class. Implementors of
`ResourceGenerator` subclasses can expect that only one `ResourceGenerator`
will be created for a given type of resource within an ClientBundle
interface.
+
+The methods on a `ResourceGenerator` are called in the following order
+ # `init` to provide the `ResourceGenerator` with a `ResourceContext`
+ # `prepare` is called for each `JMethod` the `ResourceGenerator` is
expected to handle
+ # `createFields` allows the `ResourceGenerator` to add code at the class
level
+ # `createAssignment` is called for each `JMethod`. The generated code
should be suitable for use as the right-hand side of an assignment
expression.
+ # `finish` is called after all assignments should have been written.
+
+`ResourceGenerators` are expected to make use of the
`ResourceGeneratorUtil` class.
+
+= Potential pitfalls =
+ * Changing the content of the resources will change the filenames (or
data: encoding), thus forcing a recompile of the GWT application. To avoid
this, the inlining and renaming features can be globally toggled off in
your gwt.xml file during the development phase.
+ * Inlining files into the compiled JS may not make sense if those files
are not always accessed by the program, thus inlining should be
configurable on a per-resource or per-ClientBundle basis.
+
+= Levers and knobs =
+
+ * `ClientBundle.enableInlining` is a deferred-binding property that can
be used to disable the use of `data:` URLs in browsers that would
[gwt-contrib] RFC : Adding deprecations to gwt.xml files
I'm in the process of migrating ClientBundle into trunk and it occurred to me that even if you remove the use of all deprecated types from your code, your module might still inherit an otherwise-unused module. What do you think about adding another tag to gwt.xml as follows? module deprecated href=http://google.com/more_info; This module has been replaced by blah-blah-blah./deprecated /module -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
Sounds pretty useful. We should lock its behavior down more, though. Maybe just deprecated superceded-by=othermodule/ where superceded-by is optional. It would be helpful to have consistent-looking deprecation messages, so we probably shouldn't leave the text open-ended. On Mon, Apr 6, 2009 at 11:57 AM, BobV b...@google.com wrote: I'm in the process of migrating ClientBundle into trunk and it occurred to me that even if you remove the use of all deprecated types from your code, your module might still inherit an otherwise-unused module. What do you think about adding another tag to gwt.xml as follows? module deprecated href=http://google.com/more_info; This module has been replaced by blah-blah-blah./deprecated /module -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DOMImplIE6.getZoomMultiple() divide by zero error
LGTM And I agree with putting this on the 1.6 branch, but it's Bruce's call http://gwt-code-reviews.appspot.com/17801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:28 PM, Bruce Johnson br...@google.com wrote: Sounds pretty useful. We should lock its behavior down more, though. Maybe Locking it down is just going to get in the way because we can't cover all of the types of messages that you'd necessarily want to be able to convey in tag attributes. Developers will just have to be judicious in their use of a free-form message; it more-or-less works for JavaDoc. (tangent: ModuleDoc?) If you want to lock it down, the most useful thing to be able to specify is a URL with additional information. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: weak listener in GWT?
The solution that I suggest above, seem to work fine. BTW: I also had another look at the solution suggested by MiroSlav, but that is a technical soution that isn't correct in my case. His solution was to remove the global model listeners when the widget got detached. However, I can easily detach a widget/panel from one form and connect it to another form, which in my case is completely legal, but will result in correct behavior as the listeners are removed :(. So I solved it in a functional way by adding listeners to my Form Fields that are informed about form field removal/insertions. These listeners are added to the Form Field. I also have a Form listener that receives these kind of notifications, but couldn't be used in the form field builder as Form isn't know there, where as the Form field is. I hope it's of some use to others. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:35 PM, BobV b...@google.com wrote: On Mon, Apr 6, 2009 at 1:28 PM, Bruce Johnson br...@google.com wrote: Sounds pretty useful. We should lock its behavior down more, though. Maybe Locking it down is just going to get in the way because we can't cover all of the types of messages that you'd necessarily want to be able to convey in tag attributes. I may not be thinking about the spectrum clearly enough. Do you have some examples in mind? It seems like the 99% case is people saying Don't use this anymore; use that instead. Developers will just have to be judicious in their use of a free-form message; it more-or-less works for JavaDoc. (tangent: ModuleDoc?) In javadoc, it has always seemed like an un-usefully underconstrained tag. Everbody says exactly the same things, phrased every-so-slightly differently. If you want to lock it down, the most useful thing to be able to specify is a URL with additional information. I don't think that handles the most common use case, though. Wouldn't the most common thing be, Don't use this; use that? Most people will go to the absolute minimum trouble necessary, so it's unlikely people would be included to create an actual URL to point to. (IMHO) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5191 - Adds more bridge methods so as to simplify and make more robust
Author: sp...@google.com
Date: Mon Apr 6 12:48:03 2009
New Revision: 5191
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/MakeCallsStatic.java
trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
Log:
Adds more bridge methods so as to simplify and make more robust
virtual-method dispatch in the face of tricky generics cases.
Fixes issue 3517.
Patch by: scottb
Review by: spoon
Modified:
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
==
---
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
(original)
+++
trunk/dev/core/src/com/google/gwt/core/ext/soyc/impl/StandardMethodMember.java
Mon Apr 6 12:48:03 2009
@@ -51,6 +51,7 @@
sb.append(type.getJsniSignatureName());
}
sb.append());
+sb.append(method.getOriginalReturnType().getJsniSignatureName());
this.sourceName = sb.toString();
SortedSetString aliases = new TreeSetString();
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JMethod.java Mon Apr 6
12:48:03 2009
@@ -47,6 +47,7 @@
private final boolean isStatic;
private final String name;
private ListJType originalParamTypes;
+ private JType originalReturnType;
/**
* References to any methods which this method overrides. This should be
an
@@ -102,7 +103,7 @@
for (JParameter param : params) {
paramTypes.add(param.getType());
}
-setOriginalParamTypes(paramTypes);
+setOriginalTypes(returnType, paramTypes);
}
public JAbstractMethodBody getBody() {
@@ -124,6 +125,10 @@
return originalParamTypes;
}
+ public JType getOriginalReturnType() {
+return originalReturnType;
+ }
+
/**
* Returns the transitive closure of all the methods this method
overrides.
*/
@@ -189,10 +194,11 @@
isFinal = true;
}
- public void setOriginalParamTypes(ListJType paramTypes) {
+ public void setOriginalTypes(JType returnType, ListJType paramTypes) {
if (originalParamTypes != null) {
throw new InternalCompilerException(Param types already frozen);
}
+originalReturnType = returnType;
originalParamTypes = Lists.normalize(paramTypes);
// Determine if we should trace this method.
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java Mon Apr 6
12:48:03 2009
@@ -124,6 +124,7 @@
sb.append(type.getJsniSignatureName());
}
sb.append());
+sb.append(method.getOriginalReturnType().getJsniSignatureName());
return sb.toString();
}
Modified: trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JTypeOracle.java Mon Apr
6 12:48:03 2009
@@ -156,6 +156,11 @@
return false;
}
+// original return type must be identical
+if (method1.getOriginalReturnType() !=
method2.getOriginalReturnType()) {
+ return false;
+}
+
// original parameter types must be identical
ListJType params1 = method1.getOriginalParamTypes();
ListJType params2 = method2.getOriginalParamTypes();
Modified:
trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
==
--- trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
(original)
+++ trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java Mon
Apr 6 12:48:03 2009
@@ -309,8 +309,8 @@
* /p
*/
public void addBridgeMethods(SourceTypeBinding clazzBinding) {
- if (clazzBinding.isInterface() || clazzBinding.isAbstract()) {
-// Only add bridges in concrete classes, to simplify matters.
+ if (clazzBinding.isInterface()) {
+// Only add bridges in classes, to simplify matters.
return;
}
@@ -322,7 +322,8 @@
*/
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
I don't think that handles the most common use case, though. Wouldn't the most common thing be, Don't use this; use that? Most people will go to the absolute minimum trouble necessary, so it's unlikely people would be included to create an actual URL to point to. (IMHO) I'm thinking of the case that I have where transitioning from ImmutableResourceBundle to ClientBundle could use some documentation to indicate where there have been changes. So how about use this instead and more information here and lose the free-form data? -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:17 PM, BobV b...@google.com wrote: I'm thinking of the case that I have where transitioning from ImmutableResourceBundle to ClientBundle could use some documentation to indicate where there have been changes. So how about use this instead and more information here and lose the free-form data? How does that manifest as XML? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
How does that manifest as XML? deprecated superceded-by=othermodule href=http://google.com/something; / where both attributes are optional. The URL will be presented by using the AbstractTreeLogger.log() method that takes a HelpInfo object. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:26 PM, BobV b...@google.com wrote: How does that manifest as XML? deprecated superceded-by=othermodule href=http://google.com/something; / where both attributes are optional. The URL will be presented by using the AbstractTreeLogger.log() method that takes a HelpInfo object. superceded-by should probably accept a comma-separated list of modules in case the functionality gets split up. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
(BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? Assuming people do agree that it's a bit better to avoid freeform text, then Bob, I like your most recent suggestion with John's addendum. On Mon, Apr 6, 2009 at 4:37 PM, John Tamplin j...@google.com wrote: On Mon, Apr 6, 2009 at 4:26 PM, BobV b...@google.com wrote: How does that manifest as XML? deprecated superceded-by=othermodule href=http://google.com/something; / where both attributes are optional. The URL will be presented by using the AbstractTreeLogger.log() method that takes a HelpInfo object. superceded-by should probably accept a comma-separated list of modules in case the functionality gets split up. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson br...@google.com wrote: (BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? I think there may be some case where you want/need more explanation, especially if it is of the form If you were doing X, use module A -- if you were doing Y, use module B. However, I think the URL will address most of that and it is easy enough to extend it later for free-form text if it becomes useful to do so -- it is harder to remove it if we add it now but it isn't useful. The one question I have is where will the URL point for an unreleased version? Ie, say we deprecate something in trunk, where would we make the URL point for more information? -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 4:51 PM, John Tamplin j...@google.com wrote: On Mon, Apr 6, 2009 at 4:47 PM, Bruce Johnson br...@google.com wrote: (BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? I think there may be some case where you want/need more explanation, especially if it is of the form If you were doing X, use module A -- if you were doing Y, use module B. However, I think the URL will address most of that and it is easy enough to extend it later for free-form text if it becomes useful to do so -- it is harder to remove it if we add it now but it isn't useful. The one question I have is where will the URL point for an unreleased version? Ie, say we deprecate something in trunk, where would we make the URL point for more information? The compiler does this already by including reference to HTML files that are included in the distro. It is important that this could work (i.e. file URLs). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RFC : Adding deprecations to gwt.xml files
On Mon, Apr 6, 2009 at 1:47 PM, Bruce Johnson br...@google.com wrote: (BTW, I could be wrong about the whole let's not have freeform text. It was just one guy's opinion that it makes things too inconsistent. I'd like to hear if other people agree/disagree.) @Other people: agree/disagree? Assuming people do agree that it's a bit better to avoid freeform text, then Bob, I like your most recent suggestion with John's addendum. The option to document the deprecation seems useful to me. Especially in the case that John mentioned--you may need to explain which parts of the big module got split into which chunk. I don't really like the idea that you have to provide a URL because it moves the documentation out of the module. I think one of the strengths of JavaDoc is that the doc is right there in the code. I'd like to suggest this format: deprecated superceded-by module=...Optional free-form text explaining this change/superceded-by /deprecated I think it's cleaner than a comma-separated superceded-by attribute and it allows you to document each replacement in-line. If people generally don't like the free-form text in line, then I'd vote for Bob's solution--an external file is likely to explain the whole change so it wouldn't make sense to replace my in-line text with an href on each superceded-by element. Ian --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
This is a big improvement on the logging. I really like the gist of it. I think it should have a second iteration, though. I reluctantly agree about dropping most all warnings. Once we have a way to suppress warnings, then we can talk about how to put them back in. The main thing is that many problems are still logged via TreeLogger and not stored in the ProblemReport. Shouldn't we jump over consistently to the new system rather than have a mix? Are there any particular cases you ran into where it was hard to assign the problem to a particular type? In particular, the four callers to getLogLevel() look like they should be updated. Also, the new visited field is redundant with the typeToTyeInfoComputed map. It looks like you ran into some recursion issue somewhere. We should fix that problem by improving the existing short-circuiting via TICs, not by adding a new and subtly different field. Error message content: I have not looked at the output carefully, but it looks like we are losing dependency information between types. This could be improved greatly by adding link-up messages to any type that fails due to a separate type from failing. In particular: 1. In checkSubtypes(), add a problem for each candidate that is rejected. For example, tried subtype Foo but it was not instantiable. 2. In checkSubtype(), log messages for recursing to a supertype and recursing into a field's type. For example, superclass Foo is not instantiable. Field x of type Foo is not instantiable. It could be that I misunderstand what the output will look like, though. If you think these messages would be overkill, could you post some error traces for cases like these? It would greatly help if the report sorted the types by their fully qualified name. Nits: To simplify the code and help with future developments, the errors could be stored in the TIC class instead of in ProblemReport. Simply add a field ListString problems. The two static methods that take a ProblemReport as an argument could instead take a List as an argument. The general rule is that TIC holds the information STOB deduces about a particular type. Surely it will work well to log the errors there directly. STOB.canBeInstantiated should lose its logLevel parameter, because it's no longer used. Yay! I didn't scan carefully, but perhaps some other methods could lose a similar parameter. Maybe even some loggers can go away. Likewise, you HAVE to delete the isSpeculative parameter from all methods that have one. This is this patch's greatest accomplishment, and is why it generates such better error messages. You should delete it, revive it, and delete it again, and then upload the video to YouTube. I see four calls still to getLogLevel(), but it looks like all of them should go away in favor of recording into ProblemReport. STOB.build needs formatting Style things, up to you: The first variant of shouldConsiderFieldsForSerialization invites callers to discard problem messages. IMHO, delete it and force people to supply an empty list if they really want to ignore the problems. Returning an empty list from getProblemsForType looks safer and more convenient than returning null. It's as easy to call isEmpty() as to check for null, and there are many idioms where having an empty list is more convenient than having a list-or-null. -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] new test which demonstrates the infinite recursion bug
The attached patch, relative to trunk r5191, adds a new tests which fails
only in web mode and only for the JsniSuper case. It appears the problem
isn't directly related to super, but rather with making calls to private
methods polymorphic rather than virtual dispatch. This is the bug I ran
into with the CurrencyListGenerator changes I committed and then had to roll
back.
Ie:
public class A {
public void foo() {}
}
public class B extends A {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
public class C extends B {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
B's foo will always call B's callSuper, even when this is actually a C. We
handle this properly for Java code, but not when foo is a JSNI method.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
===
--- user/test/com/google/gwt/dev/jjs/test/CompilerTest.java (revision 5191)
+++ user/test/com/google/gwt/dev/jjs/test/CompilerTest.java (working copy)
@@ -28,6 +28,62 @@
@SuppressWarnings(unused)
public class CompilerTest extends GWTTestCase {
+ public static class JsniSuperChild extends JsniSuperParent {
+@Override
+public native int foo() /*-{
+ return th...@com.google.gwt.dev.jjs.test.compilertest$jsnisuperchild::callSuper()();
+}-*/;
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class JsniSuperGrandparent {
+public int foo() {
+ return 0;
+}
+ }
+
+ public static class JsniSuperParent extends JsniSuperGrandparent {
+@Override
+public native int foo() /*-{
+ return th...@com.google.gwt.dev.jjs.test.compilertest$jsnisuperparent::callSuper()();
+}-*/;
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class SuperChild extends SuperParent {
+@Override
+public int foo() {
+ return callSuper();
+}
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
+ public static class SuperGrandparent {
+public int foo() {
+ return 0;
+}
+ }
+
+ public static class SuperParent extends SuperGrandparent {
+@Override
+public int foo() {
+ return callSuper();
+}
+
+private int callSuper() {
+ return super.foo();
+}
+ }
+
interface MyMap {
Object get(String key);
}
@@ -952,6 +1008,15 @@
new CheckSubclassStaticInnerAndClinitOrdering();
}
+ /**
+ * Test that super calls work properly, including private bridge methods
+ * needed since JSNI can't call super methods.
+ */
+ public void testSuper() {
+assertEquals(0, new SuperChild().foo());
+assertEquals(0, new JsniSuperChild().foo());
+ }
+
public void testSwitchStatement() {
switch (0) {
case 0:
[gwt-contrib] code review requested - add JSONP suport
The attached patch for trunk adds JSONP support, for use with cross-site
data retrieval, such as GData APIs.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Index: user/src/com/google/gwt/jsonp/Jsonp.gwt.xml
===
--- user/src/com/google/gwt/jsonp/Jsonp.gwt.xml (revision 0)
+++ user/src/com/google/gwt/jsonp/Jsonp.gwt.xml (revision 0)
@@ -0,0 +1,18 @@
+!----
+!-- Copyright 2009 Google Inc. --
+!-- Licensed under the Apache License, Version 2.0 (the License); you--
+!-- may not use this file except in compliance with the License. You may --
+!-- may obtain a copy of the License at--
+!----
+!-- http://www.apache.org/licenses/LICENSE-2.0 --
+!----
+!-- Unless required by applicable law or agreed to in writing, software--
+!-- distributed under the License is distributed on an AS IS BASIS, --
+!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or--
+!-- implied. License for the specific language governing permissions and --
+!-- limitations under the License. --
+
+module
+ inherits name='com.google.gwt.user.User'/
+ source path=client/
+/module
Index: user/src/com/google/gwt/jsonp/client/JsonpRequest.java
===
--- user/src/com/google/gwt/jsonp/client/JsonpRequest.java (revision 0)
+++ user/src/com/google/gwt/jsonp/client/JsonpRequest.java (revision 0)
@@ -0,0 +1,215 @@
+/*
+ * Copyright 2009 Google Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License); you may not
+ * use this file except in compliance with the License. You may obtain a copy of
+ * the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations under
+ * the License.
+ */
+package com.google.gwt.jsonp.client;
+
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Node;
+import com.google.gwt.dom.client.ScriptElement;
+import com.google.gwt.user.client.Command;
+import com.google.gwt.user.client.DeferredCommand;
+import com.google.gwt.user.client.Timer;
+import com.google.gwt.user.client.rpc.AsyncCallback;
+
+/**
+ * A JSONP request that is waiting for a response. The request can be cancelled.
+ *
+ * @param T the type of the response object.
+ */
+public class JsonpRequestT {
+
+ /**
+ * Each request will be assigned a new id.
+ */
+ private static int callbackCounter = 0;
+
+ private static native Node getDocumentElement() /*-{
+return $doc.documentElement;
+ }-*/;
+
+ private static String nextCallbackId() {
+return __jsonp + (callbackCounter++) + __;
+ }
+
+ private final String callbackId;
+
+ private final int timeout;
+
+ private final AsyncCallbackT callback;
+
+ /**
+ * Whether the result is expected to be an integer or not
+ */
+ @SuppressWarnings(unused) // used by JSNI
+ private final boolean expectInteger;
+
+ private final String callbackParam;
+
+ private final String failureCallbackParam;
+
+ /**
+ * Timer which keeps track of timeouts.
+ */
+ private Timer timer;
+
+ /**
+ * Create a new JSONP request.
+ *
+ * @param callback The callback instance to notify when the response comes
+ * back
+ * @param timeout Time in ms after which a {...@link TimeoutException} will be
+ * thrown
+ * @param expectInteger Should be true if T is {...@link Integer}, false
+ * otherwise
+ * @param callbackParam Name of the url param of the callback function name
+ * @param failureCallbackParam Name of the url param containing the the
+ * failure callback function name, or null for no failure callback
+ */
+ JsonpRequest(AsyncCallbackT callback, int timeout, boolean expectInteger,
+ String callbackParam, String failureCallbackParam) {
+callbackId = nextCallbackId();
+this.callback = callback;
+this.timeout = timeout;
+this.expectInteger = expectInteger;
+this.callbackParam = callbackParam;
+this.failureCallbackParam = failureCallbackParam;
+ }
+
+ /**
+ * Cancels a pending request.
+ */
+ public void cancel() {
+timer.cancel();
+unload();
+ }
+
+ public
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin j...@google.com wrote:
The attached patch, relative to trunk r5191, adds a new tests which fails
only in web mode and only for the JsniSuper case. It appears the problem
isn't directly related to super, but rather with making calls to private
methods polymorphic rather than virtual dispatch. This is the bug I ran
into with the CurrencyListGenerator changes I committed and then had to roll
back.
Ie:
public class A {
public void foo() {}
}
public class B extends A {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
public class C extends B {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
B's foo will always call B's callSuper, even when this is actually a C.
We handle this properly for Java code, but not when foo is a JSNI method.
Woudn't this cause infinite recursion when this is actually a C using
virtual dispatch?
c.foo - c.callSuper - b.foo - c.callSuper - b.foo - c.callSuper etc.
If it's a polymorphic call, I believe the call graph looks like:
c.foo - c.callSuper - b.foo - b.callSuper - a.foo
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: new test which demonstrates the infinite recursion bug
callSuper() is private, so B's invocation is not polymorphic, and should not
reference C's callSuper()
On Mon, Apr 6, 2009 at 4:50 PM, Vitali Lovich vlov...@gmail.com wrote:
On Mon, Apr 6, 2009 at 7:13 PM, John Tamplin j...@google.com wrote:
The attached patch, relative to trunk r5191, adds a new tests which fails
only in web mode and only for the JsniSuper case. It appears the problem
isn't directly related to super, but rather with making calls to private
methods polymorphic rather than virtual dispatch. This is the bug I ran
into with the CurrencyListGenerator changes I committed and then had to roll
back.
Ie:
public class A {
public void foo() {}
}
public class B extends A {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
public class C extends B {
public void foo() { callSuper(); }
private void callSuper() { super.foo(); }
}
B's foo will always call B's callSuper, even when this is actually a C.
We handle this properly for Java code, but not when foo is a JSNI method.
Woudn't this cause infinite recursion when this is actually a C using
virtual dispatch?
c.foo - c.callSuper - b.foo - c.callSuper - b.foo - c.callSuper etc.
If it's a polymorphic call, I believe the call graph looks like:
c.foo - c.callSuper - b.foo - b.callSuper - a.foo
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] FastTree Focus Issue
Reviewers: jlabanca, minz,
Description:
There was a focus issue with the fasttree when the size of the tree was
larger than the viewport, this was especially manifested with very large
trees.
Please review this at http://gwt-code-reviews.appspot.com/18801
Affected files:
com/google/gwt/gen2/complexpanel/client/FastTree.java
Index: com/google/gwt/gen2/complexpanel/client/FastTree.java
===
--- com/google/gwt/gen2/complexpanel/client/FastTree.java (revision 1594)
+++ com/google/gwt/gen2/complexpanel/client/FastTree.java (working copy)
@@ -53,6 +53,7 @@
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.Accessibility;
import com.google.gwt.user.client.ui.Focusable;
import com.google.gwt.user.client.ui.Panel;
@@ -849,15 +850,26 @@
}
private void moveElementOverTarget(Element movable, Element target) {
-int containerTop = getAbsoluteTop();
-
-int top = DOM.getAbsoluteTop(target) - containerTop;
+int top = DOM.getAbsoluteTop(target);
int height = DOM.getElementPropertyInt(target, offsetHeight);
+int left = DOM.getAbsoluteLeft(target) + getAbsoluteLeft();
+int width = DOM.getElementPropertyInt(target, offsetWidth);
+
+int maxBottom = Window.getScrollTop() + Window.getClientHeight();
+if (top + target.getOffsetHeight() maxBottom) {
+ top = maxBottom - target.getOffsetHeight();
+}
+
// Set the element's position and size to exactly underlap the
// item's content element.
DOM.setStyleAttribute(movable, height, height + px);
-DOM.setStyleAttribute(movable, top, top + px);
+
+if (top 0) {
+ DOM.setStyleAttribute(movable, top, top + px);
+}
+DOM.setStyleAttribute(movable, left, left + px);
+DOM.setStyleAttribute(movable, width, width + px);
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
Thanks, Lex! On Tue, Apr 7, 2009 at 8:01 AM, Lex Spoon sp...@google.com wrote: This is a big improvement on the logging. I really like the gist of it. I think it should have a second iteration, though. I reluctantly agree about dropping most all warnings. Once we have a way to suppress warnings, then we can talk about how to put them back in. The big thing here was the expected warnings, for example from the nonserializable subtypes of list. I wanted to differentiate user from non-user code (which may be a suppression regexp, for example), but deferred that for now. The main thing is that many problems are still logged via TreeLogger and not stored in the ProblemReport. Shouldn't we jump over consistently to the new system rather than have a mix? Are there any Probably; I was worried that I might lose something valuable (for example, if we put a log message in ProblemReport and then drop it as above). That shouldn't be an issue if we're selective about which TreeLogger logs migrate; I just wanted to get the focal thing working first. Happy to do a second revision. Also, the new visited field is redundant with the typeToTyeInfoComputed map. It looks like you ran into some recursion issue somewhere. We should fix that problem by improving the existing short-circuiting via TICs, not by adding a new and subtly different field. Yeah, I suspected this would come up. I'll take a closer look at using TIC instead. There's no special recursion I had to provoke; if you put logging in instead of my short circuit, I think DynaTable reconsiders java.lang.String something like 23 times before reaching TIC shortcircuits. My patch saved almost 10% time for DynaTable, I think due to this earlier shortcircuit. (Sorry, should have bragged on that in the first posting.) Error message content: I have not looked at the output carefully, but it looks like we are losing dependency information between types. This could be improved greatly by adding link-up messages to any type that fails due to a separate type from failing. In particular: 1. In checkSubtypes(), add a problem for each candidate that is rejected. For example, tried subtype Foo but it was not instantiable. This one I think we don't lose, because of the context in the ProblemReport. We get messages like com.foocorp.SubFoo had no default instructor (reached via com.foocorp.Foo). The complete chain of subtypes, yes, you'd need debug logging to see. 2. In checkSubtype(), log messages for recursing to a supertype and recursing into a field's type. For example, superclass Foo is not instantiable. Field x of type Foo is not instantiable. You similarly get the context type from your actual interface here, but yes, in these cases it might be more confusing how you got from here to there. It would greatly help if the report sorted the types by their fully qualified name. Ok. Nits: To simplify the code and help with future developments, the errors could be stored in the TIC class instead of in ProblemReport. Simply add a field ListString problems. The two static methods that take a ProblemReport as an argument could instead take a List as an argument. The general rule is that TIC holds the information STOB deduces about a particular type. Surely it will work well to log the errors there directly. The reason I was hesitant here was memory pressure... I wasn't sure how long-lived the STOB and TIC info was (yes, I should have worked it out). The purpose to ProblemReport is to become garbage relatively quickly. You should delete it, revive it, and delete it again, and then upload the video to YouTube. I never taunt dead code, for fear it will come back to haunt me... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: FastTree Focus Issue
It looks like the movable focus element was previously placed relative to
the outer element of FastTree and is now placed relative to the document
body. However, the movable element is physically within the FastTree, so
there is no way to know what its offset parent will be unless we force it to
be the FastTree. I think we need to make the FastTree have position
relative, and then position the movable element relative to it. In fact, I
wonder if doing so wouldn't fix the jumpiness issues.
The top position of an element is always relative to its offset parent,
which is usually the first parent with a position attribute set to relative
or absolute. Since you can't assume the user's layout, the only safe option
is to set the position attribute of an element that the widget controls,
such as its outer element.
Thanks,
John LaBanca
jlaba...@google.com
On Mon, Apr 6, 2009 at 8:37 PM, nw...@google.com wrote:
Reviewers: jlabanca, minz,
Description:
There was a focus issue with the fasttree when the size of the tree was
larger than the viewport, this was especially manifested with very large
trees.
Please review this at http://gwt-code-reviews.appspot.com/18801
Affected files:
com/google/gwt/gen2/complexpanel/client/FastTree.java
Index: com/google/gwt/gen2/complexpanel/client/FastTree.java
===
--- com/google/gwt/gen2/complexpanel/client/FastTree.java (revision
1594)
+++ com/google/gwt/gen2/complexpanel/client/FastTree.java (working
copy)
@@ -53,6 +53,7 @@
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
+import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.Accessibility;
import com.google.gwt.user.client.ui.Focusable;
import com.google.gwt.user.client.ui.Panel;
@@ -849,15 +850,26 @@
}
private void moveElementOverTarget(Element movable, Element target) {
-int containerTop = getAbsoluteTop();
-
-int top = DOM.getAbsoluteTop(target) - containerTop;
+int top = DOM.getAbsoluteTop(target);
int height = DOM.getElementPropertyInt(target, offsetHeight);
+int left = DOM.getAbsoluteLeft(target) + getAbsoluteLeft();
+int width = DOM.getElementPropertyInt(target, offsetWidth);
+
+int maxBottom = Window.getScrollTop() + Window.getClientHeight();
+if (top + target.getOffsetHeight() maxBottom) {
+ top = maxBottom - target.getOffsetHeight();
+}
+
// Set the element's position and size to exactly underlap the
// item's content element.
DOM.setStyleAttribute(movable, height, height + px);
-DOM.setStyleAttribute(movable, top, top + px);
+
+if (top 0) {
+ DOM.setStyleAttribute(movable, top, top + px);
+}
+DOM.setStyleAttribute(movable, left, left + px);
+DOM.setStyleAttribute(movable, width, width + px);
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: weak listener in GWT?
Another option to assist with mass one step removal is to add said listeners to a container class that also implements the listener. Then add the listener to the widget. To remove all listeners in one operation simply remove the container. This and similar types of organisation do not require changes to widgets but rather benefit from other strategies. Hth On 07/04/2009, at 5:00 AM, Ed post2edb...@hotmail.com wrote: The solution that I suggest above, seem to work fine. BTW: I also had another look at the solution suggested by MiroSlav, but that is a technical soution that isn't correct in my case. His solution was to remove the global model listeners when the widget got detached. However, I can easily detach a widget/panel from one form and connect it to another form, which in my case is completely legal, but will result in correct behavior as the listeners are removed :(. So I solved it in a functional way by adding listeners to my Form Fields that are informed about form field removal/insertions. These listeners are added to the Form Field. I also have a Form listener that receives these kind of notifications, but couldn't be used in the form field builder as Form isn't know there, where as the Form field is. I hope it's of some use to others. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
