[gwt-contrib] incubator and gwt 2.1
What is the plan to bring incubator into compatability with gwt 2.1 ? Cheers Cameron -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] gwt-incubator version compatible with GWT 2.1
Just curious when the gwt-incubator will become compatible with GWT 2.1? Cameron -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases
JBoss use a naming scheme that sorts alphabetically, maybe it is worth considering http://www.jboss.org/jbossas/downloads/ Applied to the names in the original email 1) gwt-2.0.0-m1.zip 2) gwt-2.0.0-m2.zip 3) gwt-2.0.0-rc1.zip 4) gwt-2.0.0.zip They could be : 1) gwt-2.0.0-Beta1.zip (or could just use B1) 2) gwt-2.0.0-Beta2.zip 3) gwt-2.0.0-CR1.zip (candidate for release) 4) gwt-2.0.0-GA.zip Cam 2009/8/28 Andrew Bowers abow...@google.com The current problem we are trying to solve is that it is hard to know which build is a major release for those who aren't intimate. For 1.6, the golden release was 1.6.4, which is thoroughly confusing to a general user who doesn't follow the development cycle. If you only care about the final release, you expect that you would migrate to 1.6.0 as the final release and 1.6.1 would be an update to that. If someone is commenting on a bug in a pre-release build, something labeled 1.6.0-RC1, then they will know what build they are using. If they don't, then they probably shouldn't be using it. I strongly believe this use case trumps the other issues. On Thu, Aug 13, 2009 at 12:01 PM, Scott Blum sco...@google.com wrote: On Thu, Aug 13, 2009 at 2:41 PM, Kelly Norton knor...@google.com wrote: fwiw, I've never found myself sorting GWT distros but I do find myself wanting to uniquely identify them all the time. Why do you think people will be so eager to ignore part of the label? I would actually be surprised if any form of naming fixes the few incidences of the conversation you mention. I tend to think those are because people really do think they are using the release ... only to realize later they never updated their project. Heh, sorry, that was probably not the best way of making this point: I think more obvious is usually better, because you don't have to think about it. This means less wasted time, and less chance of confusion. Don't get me wrong, I'm not saying the current system is perfect or that we shouldn't change it. I'm sure there are better things than we're doing right now, which might help with the problem of identifying a release vs. a milestone or rc. But I do think a system where the numeric portion of the version is non-unique invites confusion. What if we were more consistent with the parentheticals, like in the GWT release noteshttp://google-web-toolkit.googlecode.com/svn/releases/1.7/distro-source/core/src/release_notes.html ? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Inlining nocache.js
I'd be keen to see this land in trunk ! Cam 2009/8/7 John Tamplin j...@google.com On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis g.georgovassi...@gmail.com wrote: I'd like to save first time visitors that roundtrip to fetch nocache.js. Instead I've declared the module HTML page as non- cacheable (works nice thanks to E-Tag) and moved images and GWT- compiler output to a fully cacheable directory. After inlining nocache.js into the module HTML I had to change the paths to the XYZ.cache.html permutations, but couldn't get RPC to work reliably across all browsers. Is there a way to do this cleanly? There is a Google-internal linker that does this, and will be cleaned up and moved to GWT itself in the near future. I don't know an exact timeframe for this however. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: naming runAsync calls
Each of these different libraries would be enclosed within a unique GWT
module therefore when you refer to the split point name, can't you just use
the module name + split point name ?
in module ThirdParty :
GWT.runAsync(one, new RunAsyncCallback() { ... });
in MyModule :
GWT.runAsync(one, new RunAsyncCallback() { ... });
extend-configuration-property name=compiler.splitpoint.initial.sequence
value=MyModule#one /
extend-configuration-property name=compiler.splitpoint.initial.sequence
value=ThirdParty#one /
Cam
2009/6/25 Lex Spoon sp...@google.com
On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoonsp...@google.com wrote:
Overall, unless I missed something,
Okay, Bruce pointed out a new constraint to me: if different libraries
name their runAsync calls, then we want to able to refer to those
calls reliably even if different libraries choose the same name. This
isn't an issue immediately, but it likely will be in the future.
Thinking about libraries, I would add another constraint: we don't
want libraries to have to expose their implementation. Library
writers should ideally be able to document a named runAsync call
without exposing the precise arrangement of their internal classes.
After some discussion at the office, a tweak to option 4 fixes things
up handily. Instead of passing in a string to the method, act like a
Java framework and require passing in a class literal. A typical use
in application code would pass in the enclosing top-level class:
package org.foodity.impl;
class Cookies {
...
GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
...
}
A library writer could instead specify a public class, so as not to
expose their internal factoring.
A user of the name in a gwt.xml file would use the fully qualified version:
extend-configuration-property
name=compiler.splitpoint.initial.sequence
value=org.foodity.impl.Cookies /
A user in another Java file would use imports to make the name short:
import org.foodity.impl.Cookies;
RunAsyncQueue.startPrefetching(Cookies.class);
Thoughts? The main downside I know of is the one John Tamplin has
pointed out: if there are multiple runAsync calls within a single
class -- as sometimes happens -- then the programmer has to code up
some new classes that will only be used for naming. Can we live with
that?
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: naming runAsync calls
All good points.
Would interfaces be supported as well ?
Are there any dangers of allowing arbitrary classes (or interfaces) to be
used as monikers ?
i.e from your example, would there be anything wrong with using
EmailCompositionView.class as the moniker ?
void onComposeButtonClicked() {
GWT.runAsync(EmailCompositionView.class, new AsyncCallback() {
public void onError(Throwable e) { ... }
public void onSucess() {
new EmailCompositionView().activate();
}
});
I guess the compiler would have to verify that each call to runAsync uses a
unique moniker - is there anything else ?
Must the moniker class exists in your own module ?
Would you only allow leaf classes to be used as monikers, i.e. could you use
OfficeSuiteSplitPoint.class as a moniker ?
Cam
2009/6/25 Bruce Johnson br...@google.com
Four additional arguments in favor of using split point moniker classes
is that they
1) are easier to find within an IDE (i.e. Show References in your IDE
from a moniker class declaration would show you the associated runAsync
call),
2) can take advantage of inheritance as a way to group split points into
meaningful families (which would make them more easily browsable and
navigable in javadoc and in an IDE),
3) can be javadoc'ed to explain what they do, and
4) they could potentially be augmented with additional hints to the code
splitter using annotations (these are a stretch; Lex might be able to think
of more realistic example annotations)
/**
* Split points in this hierarchy relate to the email functionality within
the office suite.
*/
class EmailSplitPoint extends OfficeSuiteSplitPoint {
}
/**
* This split point carves out all heavyweight functionality related to
composing emails,
* most importantly, the rich text area clases.
*/
@ProhibitPreloading
@MustBeExclusiveFragment
class EmailCompositionSplitPoint extends EmailSplitPoint {
}
// ... elsewhere ...
void onComposeButtonClicked() {
GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
public void onError(Throwable e) { ... }
public void onSucess() {
new EmailCompositionView().activate();
}
});
}
On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid came...@braid.com.auwrote:
Each of these different libraries would be enclosed within a unique GWT
module therefore when you refer to the split point name, can't you just use
the module name + split point name ?
in module ThirdParty :
GWT.runAsync(one, new RunAsyncCallback() { ... });
in MyModule :
GWT.runAsync(one, new RunAsyncCallback() { ... });
extend-configuration-property name=compiler.splitpoint.initial.sequence
value=MyModule#one /
extend-configuration-property name=compiler.splitpoint.initial.sequence
value=ThirdParty#one /
Cam
2009/6/25 Lex Spoon sp...@google.com
On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoonsp...@google.com wrote:
Overall, unless I missed something,
Okay, Bruce pointed out a new constraint to me: if different libraries
name their runAsync calls, then we want to able to refer to those
calls reliably even if different libraries choose the same name. This
isn't an issue immediately, but it likely will be in the future.
Thinking about libraries, I would add another constraint: we don't
want libraries to have to expose their implementation. Library
writers should ideally be able to document a named runAsync call
without exposing the precise arrangement of their internal classes.
After some discussion at the office, a tweak to option 4 fixes things
up handily. Instead of passing in a string to the method, act like a
Java framework and require passing in a class literal. A typical use
in application code would pass in the enclosing top-level class:
package org.foodity.impl;
class Cookies {
...
GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
...
}
A library writer could instead specify a public class, so as not to
expose their internal factoring.
A user of the name in a gwt.xml file would use the fully qualified
version:
extend-configuration-property
name=compiler.splitpoint.initial.sequence
value=org.foodity.impl.Cookies /
A user in another Java file would use imports to make the name short:
import org.foodity.impl.Cookies;
RunAsyncQueue.startPrefetching(Cookies.class);
Thoughts? The main downside I know of is the one John Tamplin has
pointed out: if there are multiple runAsync calls within a single
class -- as sometimes happens -- then the programmer has to code up
some new classes that will only be used for naming. Can we live with
that?
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: naming runAsync calls
You could always change the signiture of GWT.runAsync to include a String
parameter as the first parameter. I must be a literal in code, and would be
optimized out / ignored by the compiler :
GWT.runAsync(foo, new RunAsyncCallback() {
Cam
2009/6/20 Lex Spoon sp...@google.com
There are multiple reasons that people end up wanting a way to name
calls to runAsync. One of them is the specification of an initial
load sequence that I just implemented. Looking ahead, they would be
useful for prefetch requests. It's hard to say download fragment Foo
if you can, if you don't have a way to name fragment Foo.
To name the calls, ideal would be if a Java annotation could be put on
the method call. Unfortunately, Java annotations cannot currently be
placed on a method call. One fallback would be to annotate the class
that is passed into the call. This is problematic, too, however,
because in Java 5 and 6 you can't annotate an anonymous inner class.
As a next best approach, what would people think of annotating the
surrounding method? In practice, there is only one runAsync call
within a single method. We could, at least to start with, insist that
any named runAsync must be in its own method. Note that this is never
a real constraint on people's code, because they can always split out
a large method into two smaller ones, each of which has its own
runAsync call. It would look like this:
@RunAsyncName(CwBasicButton)
@Override
protected void asyncOnInitialize(final AsyncCallbackWidget callback) {
GWT.runAsync(new RunAsyncCallback() {
public void onFailure(Throwable caught) {
callback.onFailure(caught);
}
public void onSuccess() {
callback.onSuccess(onInitialize());
}
});
}
Since typical programs have well under 100 calls to runAsync, I don't
think any sort of hierarchical naming scheme is necessary. Simple
identifiers, such as CwBasicButton, look like they would work.
This looks like a straightforward and easily understood way to name
calls to runAsync. What do others think?
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
Unfortunately I wasn't able to attend Google I/O, however I did watch a few of the sessions online. I signed up for the sandbox, but it appears that google aren't going to grant access to non IO attendees for a little while yet. I'd appreciate an invite, but I understand if that's not feasible. Cheers Cameron 2009/6/17 Ray Cromwell cromwell...@gmail.com Cameron, were you at Google I/O or did you sign up for the sandbox? I can ask a Googler to invite you if not. -Ray On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid came...@braid.com.auwrote: 2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon now. BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure would be easier to discuss this in a wave... No :( But if you are offering invites, send one this way :) Otherwise, its probably wise to keep the discussion in a place where all interested parties can participate. Cam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Changing JsArrayT extends JavaScriptObject to JsArrayT
2009/6/16 Bruce Johnson br...@google.com I'm starting to make a bit o' progress on this. I'll send out a design doc real soon now. BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure would be easier to discuss this in a wave... No :( But if you are offering invites, send one this way :) Otherwise, its probably wise to keep the discussion in a place where all interested parties can participate. Cam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gwt TRUNK seems to be to restrictive for what GWT.create can return
I am checking out the new gwt query code now. I was using a custom patched version of gwtquery 0.3 http://code.google.com/p/gwtquery/issues/detail?id=5can=4 So I will just have to re-do this patch before I can continue. Kind Regards Cameron 2009/5/17 Ray Cromwell cromwell...@gmail.com Cameron, Did you check out a recent version of GQuery? I've been checking in a lot of changes recently because I've revamped it for Google I/O re-release. It now implements about 98% of all jQuery functions. I've haven't looked at the older rebind rules, but there should be a fall-thru for non-matched browers to SelectorEngineImplJS. But John could be right, it could be that the fall-thru isn't working and IE8 is resolving to no binding. -Ray On Sat, May 16, 2009 at 7:41 PM, Cameron Braid came...@braid.com.au wrote: I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding. here are some errors from my different modules : [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java' [java] [ERROR] Line 20: Rebind result 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java' [java] [ERROR] Line 206: Rebind result 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl' must be a class [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java' [java] [ERROR] Line 29: Rebind result 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class These errors didn't occur using an older GWT trunk version r4619 Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: gwt TRUNK seems to be to restrictive for what GWT.create can return
Thanks for the fast reply, and the explanation. Kind Regards Cameron 2009/5/17 John Tamplin j...@google.com On Sat, May 16, 2009 at 10:41 PM, Cameron Braid came...@braid.com.auwrote: I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding. here are some errors from my different modules : [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java' [java] [ERROR] Line 20: Rebind result 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java' [java] [ERROR] Line 206: Rebind result 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl' must be a class [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java' [java] [ERROR] Line 29: Rebind result 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class These errors didn't occur using an older GWT trunk version r4619 The first two are probably running into the IE8 changes (where you need the ie8 deferred binding rules for user.agent-sensitive bindings). The NumberConstants change was due to adding runtime locales support, and you should no longer be GWT.create'ing it, but instead use LocaleInfo.getCurrentLocale().getNumberConstants(). If you really must do GWT.create, you can use NumberConstantsImpl but that is an implementation class and may change, and you will lose the ability to use runtime locales. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gwt TRUNK seems to be to restrictive for what GWT.create can return
I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding. here are some errors from my different modules : [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java' [java] [ERROR] Line 20: Rebind result 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java' [java] [ERROR] Line 206: Rebind result 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl' must be a class [java][ERROR] Errors in 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java' [java] [ERROR] Line 29: Rebind result 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class These errors didn't occur using an older GWT trunk version r4619 Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Getting oophm working
BTW, OOPHM in trunk (as of earlier this week) supports HostedMode and the war format, and webAppCreator will produce a oophm target in the ant build file, so you can run it with just ant oophm. It does not yet create eclipse launch configs for OOPHM, but it shouldn't be hard to figure out -- basically just add gwt-dev-oophm.jar at the head of the classpath for your launch config. I've been using OOPHM in trunk for months, and I was under the assumption that it was HostedMode. (Out of Process HostedMode) Can you please explain what it means to now support HostedMode with OOPHM ? Thanks Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Please expose moveSelectionUp/Down methods in FastTree
in gwt incubator's FastTree, moveSelectionUp and moveSelectionDown are both
private.
Please either make these methods protected, so that I can subclass FastTree
and make my own public api to call them, or provide a public API to controll
navigation.
It coudld be as simple as adding these two methods :
public void moveSelectionDown() {
moveSelectionDown(curSelection, true);
}
public void moveSelectionUp() {
moveSelectionUp(curSelection);
}
Alternatively, extract the logic from these methods into public static
helpers which I can call to determine the 'previous' and 'next' elements,
and then I can call setSelectedItem
Cheers
Cameron
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] build issue in trunk with 'ant clean buildonly'
I use ant clean buildonly to quickly build gwt without the examples. However it fails due to missing folders. I have created an issue to track it, and attached a patch that fixes it. http://code.google.com/p/google-web-toolkit/issues/detail?id=3370 Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: branches oophm does not compile
On Wed, Feb 11, 2009 at 11:46 PM, Sebastien chassa...@gmail.com wrote: Hi, Oooh it's great ! It works well. Now I can debug and use firebug in the same time ! Can you confirm me that the trunk will be used for the 1.6 M2 ? (It seems the 1.6 M1 does not contains the gwt-*oophm jar). As far as I know trunk will be for gwt 1.7, or 2.0 - whatever it gets called. Note: During the compilation of GWT, there are lot of logs indicating problem of serialization on java.lang.* classes (or primitive fields). Theses logs appears in the compilation of my module too ... :-( The log level for the compiler is too verbose See the -logLevel parameter for the Compiler : -logLevel The level of logging detail: ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL I found that WARN is comparable to gwt 1.5.x Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM in gwt trunk doesn't like ExtGWT's Viewport class
Ahh.. yeah. I was using the NPAPI plugin. I didn't realise there were two
plugins. Thanks for pointing that out.
I switched over to the XPCOM plugin, and it works a treat !
Thanks again.
Cameron
On Wed, Feb 4, 2009 at 6:00 PM, John Tamplin j...@google.com wrote:
On Wed, Feb 4, 2009 at 2:57 AM, Cameron Braid came...@braid.com.auwrote:
Using ExtGWT 1.2.1, with this simple entry point
public void onModuleLoad() {
Viewport vp = new Viewport();
RootPanel.get().add(vp);
}
causes the module to immediately unload with this message in the firebug
console :
Bad NPObject as private data!
Are you using the NPAPI plugin? If so, it has various issues and isn't
likely to be fixed. You should use the XPCOM plugin, though what is
currently available is only FF3-compatible.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: strange compiler error in trunk
For the benefit of other ExtGWT users out there - Lex provided a patch that fixes this issue. See http://code.google.com/p/google-web-toolkit/issues/detail?id=3304 for the patch. Another issue still exists when using ExtGWT's Window class with gwt trunk and gwt-1.6. The fix has been implemented and should be released in a future version. Cheers Cameron On Fri, Jan 16, 2009 at 7:27 PM, Cameron Braid came...@braid.com.au wrote: using gwt r4486 from trunk The following compiler error only occurs in my gwt modules that depend on ExtGWT. I don't know why it is looking for an implementation of the method on * Object* ? Any clues on why this is happening ? Is it a bug ? [java][ERROR] An internal compiler exception occurred [java] com.google.gwt.dev.jjs.InternalCompilerException: Could not find implementation of public abstract void handleEvent(com.extjs.gxt.ui.client.event.BaseEvent) for class (id=1) [java] public class java.lang.Object [java] extends NULL TYPE [java] /* fields */ [java] private transient int typeId [java] private transient java.lang.Object typeMarker [java] /* methods */ [java] public void init() [java] public boolean equals(java.lang.Object) [java] protected void finalize() throws java.lang.Throwable [java] public Class? extends java.lang.Object getClass() [java] public int hashCode() [java] public java.lang.String toString() [java] [java] [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2340) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2344) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:379) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:372) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST.exec(GenerateJavaAST.java:3044) [java] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:339) [java] at com.google.gwt.dev.Precompile.precompile(Precompile.java:295) [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:171) [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:141) [java] at com.google.gwt.dev.GWTCompiler$1.run(GWTCompiler.java:114) [java] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84) [java] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78) [java] at com.google.gwt.dev.GWTCompiler.main(GWTCompiler.java:117) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] gwt 1.6 PushButton - please add constructor
Please add the PushButton(Image,Image,ClickHandler) constructor that
parities the PushButton(Image,Image,ClickListener) of the deprecated
listener based event system.
Thanks,
Cameron
### Eclipse Workspace Patch 1.0
#P gwt-1.6
Index: user/src/com/google/gwt/user/client/ui/PushButton.java
===
--- user/src/com/google/gwt/user/client/ui/PushButton.java(revision
4528)
+++ user/src/com/google/gwt/user/client/ui/PushButton.java(working copy)
@@ -104,6 +104,17 @@
}
/**
+ * Constructor for codePushButton/code.
+ *
+ * @param upImage image for the default(up) face of the button
+ * @param downImage image for the down face of the button
+ * @param handler ClickHandler
+ */
+ public PushButton(Image upImage, Image downImage, ClickHandler handler) {
+super(upImage, downImage, listener);
+ }
+
+ /**
* Constructor for codePushButton/code. The supplied text is used to
* construct the default face of the button.
*
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: gwt 1.6 PushButton - please add constructor
Issue created http://code.google.com/p/google-web-toolkit/issues/detail?id=3314
On Jan 26, 12:20 pm, Cameron Braid came...@braid.com.au wrote:
Please add the PushButton(Image,Image,ClickHandler) constructor that
parities the PushButton(Image,Image,ClickListener) of the deprecated
listener based event system.
Thanks,
Cameron
### Eclipse Workspace Patch 1.0
#P gwt-1.6
Index: user/src/com/google/gwt/user/client/ui/PushButton.java
===
--- user/src/com/google/gwt/user/client/ui/PushButton.java (revision
4528)
+++ user/src/com/google/gwt/user/client/ui/PushButton.java (working copy)
@@ -104,6 +104,17 @@
}
/**
+ * Constructor for codePushButton/code.
+ *
+ * @param upImage image for the default(up) face of the button
+ * @param downImage image for the down face of the button
+ * @param handler ClickHandler
+ */
+ public PushButton(Image upImage, Image downImage, ClickHandler handler) {
+ super(upImage, downImage, listener);
+ }
+
+ /**
* Constructor for codePushButton/code. The supplied text is used to
* construct the default face of the button.
*
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
On Mon, Dec 15, 2008 at 9:45 AM, Cameron Braid came...@braid.com.au wrote: b) bug in hosted.html - see overlay-hosted.html.patch The patch for hosted.html is required because I need gwt to support a url encoded gwt.hosted value My webapp re-writes urls to pass along some query string parameters from page to page. It converts 127.0.1.1:9997 into 127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't unescape it. I've added an issue to track this bug. http://code.google.com/p/google-web-toolkit/issues/detail?id=3291can=4 Its a pretty simple patch - is someone able to check it out and apply it to trunk ? Cheers Cameron --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
It looks to be more serious than a warning. Immediately after this warning is printed, the module is unloaded and the oophm plugin is disconnected from the hosted mode server. Could it be something to do with my module serializing ArrayList ? Cam On Tue, Dec 16, 2008 at 8:40 AM, BobV b...@google.com wrote: This isn't a compiler bug, it's caused by hosted mode being perhaps slightly overeager? The deal is, the custom field serializer for Arrays.asList() (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer), has a method getArray0() that uses a JSNI reference that's only valid against our own JRE emulation classes... it's not valid against a real JRE. This is okay, because the call to that method is guarded by a GWT.isScript() block. Bob, thoughts? The problem here is that we need to rewrite the JSNI method with the numeric dispatch ids before we inject the code into the browser. Previously, dispatch was string-based so it wasn't a problem. We could add an @SuppressWarnings(jsni) to the method to squelch warnings like this. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] strange compiler error in trunk
using gwt r4486 from trunk The following compiler error only occurs in my gwt modules that depend on ExtGWT. I don't know why it is looking for an implementation of the method on * Object* ? Any clues on why this is happening ? Is it a bug ? [java][ERROR] An internal compiler exception occurred [java] com.google.gwt.dev.jjs.InternalCompilerException: Could not find implementation of public abstract void handleEvent(com.extjs.gxt.ui.client.event.BaseEvent) for class (id=1) [java] public class java.lang.Object [java] extends NULL TYPE [java] /* fields */ [java] private transient int typeId [java] private transient java.lang.Object typeMarker [java] /* methods */ [java] public void init() [java] public boolean equals(java.lang.Object) [java] protected void finalize() throws java.lang.Throwable [java] public Class? extends java.lang.Object getClass() [java] public int hashCode() [java] public java.lang.String toString() [java] [java] [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2340) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2344) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:379) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:372) [java] at com.google.gwt.dev.jjs.impl.GenerateJavaAST.exec(GenerateJavaAST.java:3044) [java] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:339) [java] at com.google.gwt.dev.Precompile.precompile(Precompile.java:295) [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:171) [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:141) [java] at com.google.gwt.dev.GWTCompiler$1.run(GWTCompiler.java:114) [java] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84) [java] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78) [java] at com.google.gwt.dev.GWTCompiler.main(GWTCompiler.java:117) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: strange compiler error in trunk
I am using version 1.2.1
I created a new module that triggers the compiler error :
module
inherits name=com.extjs.gxt.ui.GXT /
entry-point class='error.client.GwtCompilerErrorEntryPoint' /
set-property name=locale value=default/
/module
package error.client;
import com.extjs.gxt.ui.client.widget.ContentPanel;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.RootPanel;
public class GwtCompilerErrorEntryPoint implements EntryPoint {
public void onModuleLoad() {
ContentPanel contentPanel = new ContentPanel();
contentPanel.setSize(600, 800);
RootPanel.get().add(contentPanel);
}
}
An interesting observation - to trigger the exception all that is required
is to import ContentPanel. The class doesn't even have to be used. eg. this
entry point also causes the error :
package error.client;
import com.extjs.gxt.ui.client.widget.ContentPanel;
import com.google.gwt.core.client.EntryPoint;
public class GwtCompilerErrorEntryPoint implements EntryPoint {
public void onModuleLoad() {
}
}
Regards
Cameron.
On Sat, Jan 17, 2009 at 9:00 AM, Lex Spoon sp...@google.com wrote:
On Fri, Jan 16, 2009 at 11:28 AM, Lex Spoon sp...@google.com wrote:
I'll go download ExtGwt now and try to figure out what's going on. It
really should find an implementing method, but the precise way it
checks must be messed up.
My initial attempt to repro didn't work.
Cameron, what precise version of ExtGWT are you using? I downloaded
1.2.1 from the web site, added GXT as an inherited module of the Hello
sample module, and then compiled Hello.
This is with revision 4488 of trunk.
I'm guessing I have the wrong version of ExtGWT. Another possibility
is that you have a class in your module that is needed to trigger the
bug.
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: OOPHM development branches
I've been giving OOPHM a try and have run into a couple of issues a) bug in compiler - see attached oophm-stacktrace.txt b) bug in hosted.html - see overlay-hosted.html.patch The patch for hosted.html is required because I need gwt to support a url encoded gwt.hosted value My webapp re-writes urls to pass along some query string parameters from page to page. It converts 127.0.1.1:9997 into 127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't unescape it. Cheers Cameron On Fri, Dec 12, 2008 at 9:41 AM, John Tamplin j...@google.com wrote: On Thu, Dec 11, 2008 at 6:12 PM, Sam Gross colesb...@gmail.com wrote: In which branch is OOPHM development taking place? I see trunk/dev/oophm, but this project seems to cause compile errors for the gwt-user project, since the version of GWTShell in trunk/dev/oophm is missing some expected methods. The main code will be maintained in trunk -- the plugins will be in branches/oophm while we figure out their long-term location. The idea is that we refactor further to reduce the overlaid classes, and then when we are ready we just move the files from gwt-dev-oophm into gwt-dev (doing away with the various platforms at the same time). What errors do you get? I see dev (core and oophm) build errors depending on the Java version I use related to inferring generic types (the fix is to assign the result of artifacts.find to a local variable before using it in the enhanced for, I haven't tracked down exactly why it works some places or others and I have some open changes in that area is why I haven't submitted them), but nothing specific to OOPHM. With those fixed in StandardGeneratorContext, GWTShell (both core and oophm), SelectionScriptLinker, and StandardLinkerContext, it compiles and runs fine for me. What are the key things that need to be done before OOPHM is the default hosted-mode in trunk? I think the primary thing is time with people using it so we can feel confident that it won't break anyone. The UI needs some improvement (though it is usable as-is), and there are some testing issues that need to be addressed. The reason for putting it in trunk as an overlay is so that people could test it without breaking people who couldn't use it for whatever reason, and to hopefully keep it up to date as the trunk is changed. There is also the issue of competing priorities, as usual. Next week I have a task to get it OOPHM usable (in its overlay form) for some internal projects, so anything preventing it from being useful as it is in trunk currently should be shaken out then. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- 00:00:37.355 [WARN] Member 'array' in JSNI reference '@java.util.Arrays$ArrayList::array' could not be found; expect subsequent failures java.lang.NoSuchFieldError: array at com.google.gwt.dev.shell.CompilingClassLoader$DispatchClassInfoOracle.getDispId(CompilingClassLoader.java:132) at com.google.gwt.dev.shell.CompilingClassLoader.getDispId(CompilingClassLoader.java:559) at com.google.gwt.dev.util.Jsni$JsSourceGenWithJsniIdentFixup.visit(Jsni.java:105) at com.google.gwt.dev.js.ast.JsNameRef.traverse(JsNameRef.java:120) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.js.JsToStringGenerationVisitor.visit(JsToStringGenerationVisitor.java:694) at com.google.gwt.dev.js.ast.JsReturn.traverse(JsReturn.java:45) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.js.JsToStringGenerationVisitor.printJsBlockOptionalTruncate(JsToStringGenerationVisitor.java:819) at com.google.gwt.dev.js.JsSourceGenerationVisitor.visit(JsSourceGenerationVisitor.java:48) at com.google.gwt.dev.js.ast.JsBlock.traverse(JsBlock.java:43) at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438) at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413) at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96) at com.google.gwt.dev.util.Jsni.generateJavaScriptForHostedMode(Jsni.java:253) at com.google.gwt.dev.util.Jsni.getJavaScriptForHostedMode(Jsni.java:240) at com.google.gwt.dev.shell.ModuleSpaceOOPHM.createNativeMethods(ModuleSpaceOOPHM.java:50) at com.google.gwt.dev.shell.CompilingClassLoader.injectJsniFor(CompilingClassLoader.java:736) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:653) at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
[gwt-contrib] Re: RR: runAsync merge to trunk
Are there any design docs for runAsync ? Cheers Cameron On Sat, Oct 18, 2008 at 2:24 AM, Lex Spoon [EMAIL PROTECTED] wrote: Hi, Bob, Can you be the main reviewer for the merge of the runAsync branch to the trunk? The attached patch is the outstanding difference between trunk and branch, plus a few minor changes. The overall structure is like this: 1. JsProgram no longer has a single global block. It has a number of JsFragments, each of which has its own global JsBlock. If there are no calls to runAsync in the program, then there will be exactly one JsFragment. 2. The linkers are updated for this structure, though most of them simply fail if there is more than one fragment. 3. The ControlFlowAnalyzer refactor is included, described in a previous email. 4. FindDeferredSitesVisitors arranges that, for every call to runAsync, there is an AsyncLoader class generated for that call. 5. ReplaceRunAsync actually replaces calls to runAsync with calls into AsyncLoaders. Each call is associated with its own AsyncLoader class. 6. GenerateJavaScriptAST now generates a map, JavaToJavaScriptMap, that associates Java AST nodes to JavaScript AST nodes. This should eventually be done using information recorded in SourceInfos, now that JavaScript nodes have a SourceInfo, but unless you see an immediate problem it would be nice to do that in a subsequent patch. 7. CodeSplitter actually splits the program into fragments. It relies on ControlFlowAnalyzer to decide how to split everything up, and it uses FragmentExtractor for the nitty gritty mechanics of extracting a fragment of code. Note that extracting a fragment is a little trickier than this statement in, this statement out. Extracting interned strings is one example that doesn't work like that. I think that's it. Comments are very welcome, both about the implementation and the general design. I would just ask that we remember there is more work to be done, and not everything has to be in this one already large patch. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
