[gwt-contrib] Re: Allows Linkers to mark themselves as shardable by including a (issue678802)
close me http://gwt-code-reviews.appspot.com/678802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)
Hi Andre, I'm waiting on Ray C or Lex to give the LGTM, but I noticed
this last patch you uploaded left out the editdistance library files.
On Mon, Aug 9, 2010 at 4:48 PM, avassalo...@google.com wrote:
http://gwt-code-reviews.appspot.com/669801/diff/33001/34006
File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java
(right):
http://gwt-code-reviews.appspot.com/669801/diff/33001/34006#newcode43
dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:43:
Pattern.compile(function |[_a-zA-Z$][.$_a-zA-Z0-9]*=function);
On 2010/08/06 02:12:25, cromwellian wrote:
This regex will incorrect match vtable declarations of the form:
_.name = function() { ... }
These prototype declarations cannot be re-ordered, so don't let it
match a
single '_' symbol.
Fixed.
http://gwt-code-reviews.appspot.com/669801/show
--
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Hard coded History integration for the Scaffold app. This is step zero (issue717801)
http://gwt-code-reviews.appspot.com/717801/diff/20002/33060
File user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java
(right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33060#newcode54
user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java:54: public
ProxyListPlace go(Place place) {
Whats confusing is that it saves the record returned by
proxyPlace().getProxy(), and then I can get the record by calling
getProxy(). Its a stateful class, but I don't understand why. Do you
ever call ProxyPlaceToListPlace.getProxy()?
http://gwt-code-reviews.appspot.com/717801/diff/20002/33062
File user/src/com/google/gwt/event/shared/EventBus.java (right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33062#newcode45
user/src/com/google/gwt/event/shared/EventBus.java:45: void
fireEvent(GwtEvent? event);
There are probably a lot of people using it because all HasXXXHandlers
extend it. For example, HasClickHandlers extends it and adds
addBlurHandler.
http://gwt-code-reviews.appspot.com/717801/diff/20002/33070
File user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java
(right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33070#newcode34
user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java:34: void
setValues(CollectionT values, RendererT render);
Assuming you mean for ImageLoadingCell, I think the renderers had more
to do with being able to customize loading and error messages than
building safe HTML. Either way, we'll need to take a look at how to
integrate the renderers in ImageLoadingCell with SafeHtmlBuilder,
because you can't just return an HTML string and call it unsafe. We
might need a SafeHtmlRenderer that takes a SafeHtmlBuilder instead of
returning a String.
http://gwt-code-reviews.appspot.com/717801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] RR: What if UiBinder could take a factory?
Hey Ray,
Thanks for trying to make GIN user's lives easier when using UiBinder.
However, injecting an injector wouldn't really work. Most GIN
applications will end up having one top level Ginjector that would
have a getter for some top level application widget. When you start
creating multiple Ginjectors, instances of classes don't stay the
same. For example, a Singleton EventBus in two Ginjectors are
different instance types.
Also, I'm pretty sure you can't put an @Inject on an interface method,
but I haven't tried.
--
Arthur Kalmenson
On Mon, Aug 9, 2010 at 10:29 PM, Ray Ryan rj...@google.com wrote:
If you don't use GIN (you know, that really should be GIn), the rest of this
note probably won't interest you.
Would something like the following improve life for GIN users enough to be
worth doing? Or is it just a hack?
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true) fields.
* p
* When an instance is needed, a zero args method with an appropriate
return type
* will be sought on the factory to provide it. If none is found
GWT.create()
* will be used instead.
* p
* It is a compile time error for the factory to provide ambiguous
methods.
*/
setFactory(F factory);
}
You might wind up with code like…
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
�...@inject setfactory(MyGinjector factory);
}
…and a few extra getters on your Ginjector.
Now injecting an injector is generally a terrible idea, but it's something
at least. (Does that even work in Gin? And can you put @Inject on an
interface method?)
What do you think?
rjrjr
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
Hi all,
this topic comes up so often that we should really find a solution. :) The
short story is that we might need to fix this issue but could potentially
work without it:
http://code.google.com/p/google-gin/issues/detail?id=95(Allow classes
created by a Generator to participate in dependency
injection)
Long story:
When you start creating multiple Ginjectors, instances of classes don't
stay the
same. For example, a Singleton EventBus in two Ginjectors are
different instance types.
If you inject your ginjector somewhere in its own dependency tree, it will
inject itself, i.e. it is automatically bound as a singleton.
Also, I'm pretty sure you can't put an @Inject on an interface method,
but I haven't tried.
Yes, you can - this is explicitly allowed in Gin for use with Generators.
Would something like the following improve life for GIN users enough to be
worth doing? Or is it just a hack?
[...]
I think this is perfectly viable - but we're running into the generator
interaction issue here. Right now, Gin cannot use generated code as input
and therefore will not be able to inspect the generated implementation of
MyUiBinder. This could be fine if we were specifying exactly what we want to
be injected into the factory. But as far as I can see, you're injecting the
ginjector and then using it in generated code. How do you know how to
retrieve objects from the Ginjector? In difference to Guice, there is
*no *getInstance(..)
method on a Ginjector.
I think what we want is a class generated by UiBinder that has @Inject
annotated constructor/fields/methods for its required children and is then
used as input by the Gin generator to wire the injection up. But to
accomplish that, we'll need to fix the issue mentioned above.
How does this sound?
Peter
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true) fields.
* p
* When an instance is needed, a zero args method with an appropriate
return type
* will be sought on the factory to provide it. If none is found
GWT.create()
* will be used instead.
* p
* It is a compile time error for the factory to provide ambiguous
methods.
*/
setFactory(F factory);
}
You might wind up with code like…
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
…and a few extra getters on your Ginjector.
Now injecting an injector is generally a terrible idea, but it's
something
at least. (Does that even work in Gin? And can you put @Inject on an
interface method?)
What do you think?
rjrjr
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
You received this message because you are subscribed to the Google Groups
google-gin group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to
google-gin+unsubscr...@googlegroups.comgoogle-gin%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/google-gin?hl=en.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
If you inject your ginjector somewhere in its own dependency tree, it will
inject itself, i.e. it is automatically bound as a singleton.
Does this work if you have multiple Ginjectors? What I've done before
was to have a hierarchy of Ginjectors and the top level one would be
what gets instantiated. If you inject one of these Ginjectors lower in
the hierarchy, would the instances still be the same?
And sorry for my inaccurate info, my GWT is getting rusty :(.
--
Arthur Kalmenson
On Tue, Aug 10, 2010 at 12:04 PM, Peter Schmitt ara...@gmail.com wrote:
Hi all,
this topic comes up so often that we should really find a solution. :) The
short story is that we might need to fix this issue but could potentially
work without it: http://code.google.com/p/google-gin/issues/detail?id=95
(Allow classes created by a Generator to participate in dependency
injection)
Long story:
When you start creating multiple Ginjectors, instances of classes don't
stay the
same. For example, a Singleton EventBus in two Ginjectors are
different instance types.
If you inject your ginjector somewhere in its own dependency tree, it will
inject itself, i.e. it is automatically bound as a singleton.
Also, I'm pretty sure you can't put an @Inject on an interface method,
but I haven't tried.
Yes, you can - this is explicitly allowed in Gin for use with Generators.
Would something like the following improve life for GIN users enough to
be
worth doing? Or is it just a hack?
[...]
I think this is perfectly viable - but we're running into the generator
interaction issue here. Right now, Gin cannot use generated code as input
and therefore will not be able to inspect the generated implementation of
MyUiBinder. This could be fine if we were specifying exactly what we want to
be injected into the factory. But as far as I can see, you're injecting the
ginjector and then using it in generated code. How do you know how to
retrieve objects from the Ginjector? In difference to Guice, there is no
getInstance(..) method on a Ginjector.
I think what we want is a class generated by UiBinder that has @Inject
annotated constructor/fields/methods for its required children and is then
used as input by the Gin generator to wire the injection up. But to
accomplish that, we'll need to fix the issue mentioned above.
How does this sound?
Peter
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true)
fields.
* p
* When an instance is needed, a zero args method with an appropriate
return type
* will be sought on the factory to provide it. If none is found
GWT.create()
* will be used instead.
* p
* It is a compile time error for the factory to provide ambiguous
methods.
*/
setFactory(F factory);
}
You might wind up with code like…
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
�...@inject setfactory(MyGinjector factory);
}
…and a few extra getters on your Ginjector.
Now injecting an injector is generally a terrible idea, but it's
something
at least. (Does that even work in Gin? And can you put @Inject on an
interface method?)
What do you think?
rjrjr
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
You received this message because you are subscribed to the Google Groups
google-gin group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to
google-gin+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-gin?hl=en.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Hard coded History integration for the Scaffold app. This is step zero (issue717801)
On Tue, Aug 10, 2010 at 6:40 AM, jlaba...@google.com wrote:
http://gwt-code-reviews.appspot.com/717801/diff/20002/33060
File user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java
(right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33060#newcode54
user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java:54: public
ProxyListPlace go(Place place) {
Whats confusing is that it saves the record returned by
proxyPlace().getProxy(), and then I can get the record by calling
getProxy(). Its a stateful class, but I don't understand why. Do you
ever call ProxyPlaceToListPlace.getProxy()?
This is an example of the over-complexity of this approach, which comes of
trying to use a mechanism for apps that do one thing at a time for an app
that is doing several at a time.
Remember that the app can only be in one place at a time. The master list at
the top of the screen needs to be shown with no selection when the app goes
to a ProxyListPlace (it's the thing that shows the list of proxies). And it
needs to stay visible and update its selection when the app moves to a
ProxyPlace (to show the details for a single record). The list on the left
side of the screen needs to maintain its selection in the same way.
A ProxyPlaceToListPlace converter is able to tell you what list a particular
proxy belongs to. An EmployeeRecord is in the EmployeeRecord.class list.
When it figures that out for you, it also holds on to the proxy it looked
at, e.g. to allow you to update your selection — getProxy(). You're right,
though, that's a just plain odd side effect. It made more sense in an
earlier, even more complicated version of this patch last week. I'll try to
drop it before submitting.
http://gwt-code-reviews.appspot.com/717801/diff/20002/33062
File user/src/com/google/gwt/event/shared/EventBus.java (right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33062#newcode45
user/src/com/google/gwt/event/shared/EventBus.java:45: void
fireEvent(GwtEvent? event);
There are probably a lot of people using it because all HasXXXHandlers
extend it. For example, HasClickHandlers extends it and adds
addBlurHandler.
Oh, okay. Thanks.
http://gwt-code-reviews.appspot.com/717801/diff/20002/33070
File user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java
(right):
http://gwt-code-reviews.appspot.com/717801/diff/20002/33070#newcode34
user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java:34: void
setValues(CollectionT values, RendererT render);
Assuming you mean for ImageLoadingCell, I think the renderers had more
to do with being able to customize loading and error messages than
building safe HTML. Either way, we'll need to take a look at how to
integrate the renderers in ImageLoadingCell with SafeHtmlBuilder,
because you can't just return an HTML string and call it unsafe. We
might need a SafeHtmlRenderer that takes a SafeHtmlBuilder instead of
returning a String.
Yes. The main point is that a Renderer should strictly be used a source of
plain user readable text, not nascent dom.
http://gwt-code-reviews.appspot.com/717801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] devmode classloader retention
Thanks so much for digging into this, Stephen. @John, Bob, Ray: can you guys take a look at this and maybe create yourselves issues? It seems like this is a real performance issue, with the user ending up in sluggish performance or else having to restart DevMode, which is certainly slower than refresh. On Tue, Aug 10, 2010 at 1:32 AM, Stephen Haberman step...@exigencecorp.comwrote: Is the number of JRealClassType instances just going up and up each refresh? Yep. I didn't explicitly check until you asked, but comparing heap diffs before/after multiple refreshes, each refresh was adding ~1800 new JRealClassTypes that never went away. Can you figure out who is holding references to them (referrants)? Turns out I can. Thank you for the rather logical suggestion--I had looked at the GC root paths and, once I saw AppClassLoader, had given up thinking it was going to be an PITA classloader issue. But, no, its just some static caches. It took a few tries, but the attached patch fixes the leaks and I can now run my whole test suite and DevMode stays snappy. Note that I use the term fixes very loosely as: * ResourceFactory.cache just needs a WeakHashMap, pretty easy * OwnerFieldClass.FIELD_CLASSES needs a hash map that is weak on both keys and values. Or some way to explicitly clear the values when the TypeOracle is done with. I tried a WeakHashMap and it was not enough as the OwnerFieldClass value is what holds the JRealClassType reference. What did work, was a stupid, ugly hack of clearing the cache on each new oracle seen (which is a bad idea, it would break multiple clients use DevMode concurrently, but it proved the point). * AbstractResourceContext.CACHES is already a WeakHashMap, however, the values end up being IdentityHashMaps with JRealClassTypes keys, which reference the oracle, so, contrary to the javadoc, it does actually keep TypeOracles from being GC'd. The same ugly hack from issue 2 also solved this final one. As my hacks obviously show, I don't know of a good way to deal with the 2nd or 3rd issues. If you have a suggestion, I can try and run with it, but I'd also be just fine with someone more knowledgeable about the codebase finding an elegant solution. :-) Thanks! - Stephen -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Better error message on garbage in text. (issue748801)
http://gwt-code-reviews.appspot.com/748801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
On Tue, Aug 10, 2010 at 9:04 AM, Peter Schmitt ara...@gmail.com wrote:
Hi all,
this topic comes up so often that we should really find a solution. :) The
short story is that we might need to fix this issue but could potentially
work without it:
http://code.google.com/p/google-gin/issues/detail?id=95(Allow classes created
by a Generator to participate in dependency
injection)
Long story:
When you start creating multiple Ginjectors, instances of classes don't
stay the
same. For example, a Singleton EventBus in two Ginjectors are
different instance types.
If you inject your ginjector somewhere in its own dependency tree, it will
inject itself, i.e. it is automatically bound as a singleton.
Also, I'm pretty sure you can't put an @Inject on an interface method,
but I haven't tried.
Yes, you can - this is explicitly allowed in Gin for use with Generators.
Would something like the following improve life for GIN users enough to
be
worth doing? Or is it just a hack?
[...]
I think this is perfectly viable - but we're running into the generator
interaction issue here. Right now, Gin cannot use generated code as input
and therefore will not be able to inspect the generated implementation of
MyUiBinder. This could be fine if we were specifying exactly what we want to
be injected into the factory. But as far as I can see, you're injecting the
ginjector and then using it in generated code. How do you know how to
retrieve objects from the Ginjector? In difference to Guice, there is *no
*getInstance(..) method on a Ginjector.
I think the scheme I sketched gets around this issue. Gin isn't aware of any
of the generated code. Rather, the generated code is aware of the public
Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just
going to write GWT.create(MyUiBinder), and then call that instance's
setFactory() method with itself. So this code:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
}
makes Gin generate the moral equivalent of
new
MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this);
Similarly, UiBinder is aware of the public interface of my public Ginjector.
That's why the JavaDoc says that the factory is required to provide an
explicit FooWidget getTheFoo() if it is to be a source of FooWidgets. You
the developer put this method on your Ginjector:
public interface MyGinjector extends Ginjector {
FooWidget getFoo();
}
And so UiBinder can generate something like:
HTMLPanel h = new HTMLPanel(Blah di blah di blah span id='foo25'/ di
blah.);
h.addAndReplaceElement(factory.getFoo(), foo25);
Also, while I was assuming that for the most part the binder would be
working off of the Ye One True Ginjector, there is no actual requirement
that you do so, nor that your Factory be Ginjector at al. E.g.:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public static class Factory {
@Inject @MagicScope EventBus eventBus;
FooWidget makeAFoo() {
return new Foo(eventBus);
}
}
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
And if it's possible for one Ginjector to create another (haven't been
paying attention, sorry), that boilerplate could perhaps be even less?
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
@MagicScope
public interface Factory extends Ginjector {
EventBus eventBus;
}
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
I think what we want is a class generated by UiBinder that has @Inject
annotated constructor/fields/methods for its required children and is then
used as input by the Gin generator to wire the injection up. But to
accomplish that, we'll need to fix the issue mentioned above.
How does this sound?
Like it would need a lot more thought and a lot more work :-). (Although
it's a nicely DI-framework-agnostic notion, now that the annotations live in
javax.). We really wouldn't just want limit you to putting @Inject on
everything, you'd want the full gin experience — e.g. to be allowed to put
other annotations on specific fields, right? All of a sudden we have to
provide an annotation syntax for ui.xml.
Don't get me wrong, I would rather fix GWT.create() so that Ginjector
actually could efficiently provide a getInstance(...) method, and to allow
gin to see generated code. But those two conversations never seem to
terminate, and I don't have the chops to just do them myself. So my question
is: if we accept the current limitations, would this change be a worthwhile
incremental step?
Peter
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a
[gwt-contrib] [google-web-toolkit] r8510 committed - Recommiting the new CrossSiteIframeLinker....
Revision: 8510
Author: sp...@google.com
Date: Tue Aug 10 07:06:57 2010
Log: Recommiting the new CrossSiteIframeLinker.
This linker works cross-site, because it uses a script tag to
download code instead of XHR. However, like the iframe linker,
it still uses an iframe to hold all the installed code.
This version adds a head element to the inner iframe if one is not already
present.
Review at http://gwt-code-reviews.appspot.com/726802
Review by: j...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=8510
Added:
/trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java
/trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeTemplate.js
/trunk/user/src/com/google/gwt/core/CrossSiteIframeLinker.gwt.xml
/trunk/user/src/com/google/gwt/core/client/impl/CrossSiteIframeLoadingStrategy.java
/trunk/user/test/com/google/gwt/core/ext/CrossSiteIframeLinkerTest.gwt.xml
/trunk/user/test/com/google/gwt/core/ext/test/CrossSiteIframeLinkerTest.java
/trunk/user/test/com/google/gwt/dev/jjs/CompilerSuiteCrossSiteIframe.gwt.xml
/trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncFailure.gwt.xml
/trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncMetrics.gwt.xml
/trunk/user/test/com/google/gwt/dev/jjs/CrossSiteIframeRunAsyncSuite.java
/trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncFailureTest.java
/trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncMetricsTest.java
/trunk/user/test/com/google/gwt/dev/jjs/test/CrossSiteIframeRunAsyncTest.java
Modified:
/trunk/user/src/com/google/gwt/core/Core.gwt.xml
/trunk/user/test/com/google/gwt/core/ext/LinkerSuite.java
===
--- /dev/null
+++
/trunk/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java
Tue Aug 10 07:06:57 2010
@@ -0,0 +1,158 @@
+/*
+ * Copyright 2010 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.core.linker;
+
+import com.google.gwt.core.ext.LinkerContext;
+import com.google.gwt.core.ext.TreeLogger;
+import com.google.gwt.core.ext.linker.CompilationResult;
+import com.google.gwt.core.ext.linker.LinkerOrder;
+import com.google.gwt.core.ext.linker.Shardable;
+import com.google.gwt.core.ext.linker.LinkerOrder.Order;
+import com.google.gwt.core.ext.linker.impl.SelectionScriptLinker;
+import com.google.gwt.dev.About;
+import com.google.gwt.dev.js.JsToStringGenerationVisitor;
+import com.google.gwt.dev.util.DefaultTextOutput;
+import com.google.gwt.dev.util.TextOutput;
+import com.google.gwt.dev.util.Util;
+
+/**
+ * This linker uses an iframe to hold the code and a script tag to
download the
+ * code. It can download code cross-site, because it uses a script tag to
+ * download it and because it never uses XHR. The iframe, meanwhile, makes
it
+ * trivial to install additional code as the app runs.
+ */
+...@linkerorder(Order.PRIMARY)
+...@shardable
+public class CrossSiteIframeLinker extends SelectionScriptLinker {
+ @Override
+ public String getDescription() {
+return Cross-Site-Iframe;
+ }
+
+ @Override
+ protected String generateDeferredFragment(TreeLogger logger,
+ LinkerContext context, int fragment, String js) {
+StringBuilder sb = new StringBuilder();
+sb.append($wnd.);
+sb.append(context.getModuleFunctionName());
+sb.append(.runAsyncCallback);
+sb.append(fragment);
+sb.append(();
+sb.append(JsToStringGenerationVisitor.javaScriptString(js));
+sb.append();\n);
+return sb.toString();
+ }
+
+ @Override
+ protected byte[] generatePrimaryFragment(TreeLogger logger,
+ LinkerContext context, CompilationResult result, String[] js) {
+// Wrap the script code with its prefix and suffix
+TextOutput script = new DefaultTextOutput(context.isOutputCompact());
+script.print(getModulePrefix(context, result.getStrongName(),
js.length 1));
+script.print(js[0]);
+script.print(getModuleSuffix(logger, context));
+
+// Rewrite the code so it can be installed with
+// __MODULE_FUNC__.onScriptDownloaded
+
+StringBuffer out = new StringBuffer();
+out.append(context.getModuleFunctionName());
+out.append(.onScriptDownloaded();
+
out.append(JsToStringGenerationVisitor.javaScriptString(script.toString()));
+out.append());
+
+return Util.getBytes(out.toString());
+ }
+
+ @Override
+ protected String
[gwt-contrib] PUBLIC: Fix compile errors in user/build.xml compile.tests target. (issue749801)
Reviewers: Ray Ryan,
Description:
PUBLIC: Fix compile errors in user/build.xml compile.tests target.
Please review this at http://gwt-code-reviews.appspot.com/749801/show
Affected files:
M user/build.xml
Index: user/build.xml
===
--- user/build.xml (revision 8505)
+++ user/build.xml (working copy)
@@ -109,6 +109,7 @@
pathelement location=${gwt.tools.lib}/junit/junit-3.8.1.jar /
pathelement
location=${gwt.tools.lib}/selenium/selenium-java-client-driver.jar /
pathelement
location=${gwt.tools}/redist/json/r2_20080312/json-1.5.jar /
+ pathelement
location=${gwt.tools.lib}/javax/validation/validation-api-1.0.0.GA.jar /
path refid=test.extraclasspath /
/classpath
/gwt.javac
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: PUBLIC: Fix compile errors in user/build.xml compile.tests target. (issue749801)
LGTM http://gwt-code-reviews.appspot.com/749801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
I think the scheme I sketched gets around this issue. Gin isn't aware of
any of the generated code. Rather, the generated code is aware of the public
Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just
going to write GWT.create(MyUiBinder), and then call that instance's
setFactory() method with itself. So this code:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
}
makes Gin generate the moral equivalent of
new
MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this);
Yes, this should work. It requires some boilerplate on the ginjector (which
often contains just a single method) but it has the advantage of not
requiring any additional infrastructure.
Also, while I was assuming that for the most part the binder would be
working off of the Ye One True Ginjector, there is no actual requirement
that you do so, nor that your Factory be Ginjector at al. E.g.:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public static class Factory {
@Inject @MagicScope EventBus eventBus;
FooWidget makeAFoo() {
return new Foo(eventBus);
}
}
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
No problem - this factory is essentially a provider, although in the usual
case it will have more than one creator method? You can also abuse assisted
inject here to have Gin generate the implementation for the factory
interface (assisted inject won't complain if you don't pass any local
variables :).
And if it's possible for one Ginjector to create another (haven't been
paying attention, sorry), that boilerplate could perhaps be even less?
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
@MagicScope
public interface Factory extends Ginjector {
EventBus eventBus;
}
public interface MyUiBinder extends UiBinderWithFactoryWidget, MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
While this works in theory, you probably want a new ginjector that actually
inherits the injection framework of the original ginjector - otherwise it
won't have any of the bindings. Probably easier to use assisted inject as
outlined above.
I think what we want is a class generated by UiBinder that has @Inject
annotated constructor/fields/methods for its required children and is then
used as input by the Gin generator to wire the injection up. But to
accomplish that, we'll need to fix the issue mentioned above.
How does this sound?
Like it would need a lot more thought and a lot more work :-). (Although
it's a nicely DI-framework-agnostic notion, now that the annotations live in
javax.). We really wouldn't just want limit you to putting @Inject on
everything, you'd want the full gin experience — e.g. to be allowed to put
other annotations on specific fields, right? All of a sudden we have to
provide an annotation syntax for ui.xml.
Don't get me wrong, I would rather fix GWT.create() so that Ginjector
actually could efficiently provide a getInstance(...) method, and to allow
gin to see generated code. But those two conversations never seem to
terminate, and I don't have the chops to just do them myself. So my question
is: if we accept the current limitations, would this change be a worthwhile
incremental step?
Yes, we should do the simple solution first. I'd really like to fix the
generator interaction challenge though, it would solve tons of other
problems as well.
Peter
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true)
fields.
* p
* When an instance is needed, a zero args method with an appropriate
return type
* will be sought on the factory to provide it. If none is found
GWT.create()
* will be used instead.
* p
* It is a compile time error for the factory to provide ambiguous
methods.
*/
setFactory(F factory);
}
You might wind up with code like…
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
…and a few extra getters on your Ginjector.
Now injecting an injector is generally a terrible idea, but it's
something
at least. (Does that even work in Gin? And can you put @Inject on an
interface method?)
What do you think?
rjrjr
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
You received this message because you are subscribed to the Google Groups
google-gin group.
To post to
[gwt-contrib] Re: Replacing ListView with HasData and HasRows (issue723801)
committed as r8511 http://gwt-code-reviews.appspot.com/723801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Replacing ListView with HasData and HasRows (issue745801)
committed as r8511 http://gwt-code-reviews.appspot.com/745801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by natewingone: @br...@google.com: It's not just mobile apps that want every byte to count. If you use GWT to enhance a largely static website, and the website must be fast to load for new users, you have to make sure javascript is as small as possible. For comparison the current collections are used all over the place in the widget/event libraries, and ArrayList alone uses around 8k. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Q: Can Object.typeId be gotten rid of? If not, what else is it being used for? http://gwt-code-reviews.appspot.com/750801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r8513 committed - Better error message on garbage in text....
Revision: 8513
Author: gwt.mirror...@gmail.com
Date: Tue Aug 10 08:37:35 2010
Log: Better error message on garbage in text.
Review at http://gwt-code-reviews.appspot.com/748801
Review by: cheng...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=8513
Modified:
/trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java
/trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java
/trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java
===
--- /trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java Wed Oct
28 09:10:53 2009
+++ /trunk/user/src/com/google/gwt/uibinder/client/UiFactory.java Tue Aug
10 08:37:35 2010
@@ -23,7 +23,7 @@
/**
* Marks a method that may be called as an alternative to a GWT.create
call in a
- * {...@link UiBinder} template. The parameter names of the constructor are
treated
+ * {...@link UiBinder} template. The parameter names of the method are treated
* as required xml element attribute values.
* p
* It is an error to apply this annotation to more than one method of a
given
===
--- /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java Fri Jul
23 14:20:15 2010
+++ /trunk/user/src/com/google/gwt/uibinder/rebind/XMLElement.java Tue Aug
10 08:37:35 2010
@@ -485,7 +485,9 @@
// Make sure there are no children left but empty husks
for (XMLElement child : consumeChildElementsNoEmptyCheck()) {
if (child.hasChildNodes() || child.getAttributeCount() 0) {
-logger.die(this, Element has illegal child %s, child);
+logger.die(this, Illegal child %s in a text-only context.
+ + Perhaps you are trying to use unescaped HTML
+ + where text is required, as in a HasText widget?,
child);
}
}
===
--- /trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java Fri Mar 19
08:12:41 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/HTMLPanel.java Tue Aug 10
08:37:35 2010
@@ -107,7 +107,9 @@
}
/**
- * Adds a child widget to the panel, contained within an HTML element.
+ * Adds a child widget to the panel, contained within an HTML
+ * element. It is up to the caller to ensure that the given element
+ * is a child of this panel's root element.
*
* @param widget the widget to be added
* @param elem the element within which it will be contained
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Generating Image with Generator
Hello, I'm trying to generate a bunch of ClientBundles with the associated images in the same directory. I can't figure out how to write the image files to the same directory as the java files generated with GeneratorContext.tryCreate(...). I also tried using GeneratorContext.tryCreateResource however the committed file ended up in my war directory. Is there a way I can get a reference to the generated directory? Cheers, Anthony -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Why is JClassType#getAnnotations() not public?
Hi, In one of my generator I would need to scan the list of all annotations in order to find one that is marked with another annotation. Unfortunately, there doesn't seem to be any public mechanism in JClassType to access the list of all annotations. Looking at the class I see: getAnnotations() and getDeclaredAnnotations() that would do exactly what I need, but they have default visibility and are indicated for testing purposes only. Is there any reason why these method couldn't be made public? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Reviewers: scottb, robertvawter, cromwellian, Description: Removed use of a global table (typeIdArray) for testing castability between types. This information is now stored per class prototype as a castableMap. Please review this at http://gwt-code-reviews.appspot.com/750801/show Affected files: M dev/core/src/com/google/gwt/core/ext/linker/SymbolData.java M dev/core/src/com/google/gwt/core/ext/linker/impl/StandardSymbolData.java M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java M dev/core/src/com/google/gwt/dev/jjs/impl/ArrayNormalizer.java M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Array.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Cast.java M dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/Util.java M tools/api-checker/config/gwt20_21userApi.conf M user/src/com/google/gwt/rpc/linker/ClientOracleLinker.java M user/src/com/google/gwt/rpc/server/ClientOracle.java M user/src/com/google/gwt/rpc/server/DelegatingClientOracle.java M user/src/com/google/gwt/rpc/server/HostedModeClientOracle.java M user/src/com/google/gwt/rpc/server/WebModeClientOracle.java M user/src/com/google/gwt/rpc/server/WebModePayloadSink.java M user/super/com/google/gwt/emul/java/lang/Object.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
Reviewers: knorton,
Description:
Removed trim in ValueBoxBase, forcing parsers to handle trim()ing.
Please review this at http://gwt-code-reviews.appspot.com/738801/show
Affected files:
M user/src/com/google/gwt/user/client/ui/ValueBoxBase.java
Index: user/src/com/google/gwt/user/client/ui/ValueBoxBase.java
===
--- user/src/com/google/gwt/user/client/ui/ValueBoxBase.java(revision 8466)
+++ user/src/com/google/gwt/user/client/ui/ValueBoxBase.java(working copy)
@@ -196,7 +196,7 @@
* @throws ParseException if the value cannot be parsed
*/
public T getValueOrThrow() throws ParseException {
-String text = getText().trim();
+String text = getText();
if (.equals(text)) {
return null;
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Add the ability to change the size of a widget in the (issue719802)
Reviewers: jgw,
Description:
Add the ability to change the size of a widget in the
DockLayoutPanel after it has already been added.
Please review this at http://gwt-code-reviews.appspot.com/719802/show
Affected files:
M user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
Index: user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
===
--- user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (revision
8450)
+++ user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java (working
copy)
@@ -304,6 +304,26 @@
return removed;
}
+
+ /**
+ * Updates the size of the widget passed in as long as it is not the
center
+ * widget and updates the layout of the dock.
+ *
+ * @param widget the widget that needs to update its size
+ * @param size the size to update the widget to
+ */
+ public void setWidgetSize(Widget widget, int size) {
+assertIsChild(widget);
+LayoutData data = (LayoutData) widget.getLayoutData();
+
+assert data.direction != Direction.CENTER :
+The size of the center widget can not be updated.;
+
+data.size = size;
+
+// Update the layout.
+animate(0);
+ }
protected Widget getCenter() {
return center;
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the size of a widget in the (issue719802)
On Mon, Aug 2, 2010 at 2:14 PM, j...@google.com wrote:
http://gwt-code-reviews.appspot.com/719802/diff/1/2
File user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java
(right):
http://gwt-code-reviews.appspot.com/719802/diff/1/2#newcode315
user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java:315: public
void setWidgetSize(Widget widget, int size) {
This needs to be a double (all units except PX can be non-integral).
True, just eclipse auto create method getting in the way, done.
http://gwt-code-reviews.appspot.com/719802/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
http://gwt-code-reviews.appspot.com/738801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] GWT-RPC generic object serialization...
It seems that the issue of generic Object serialization comes up a lot in
the arena of GWT-RPC, but good solutions seem to be far more elusive than
the postings of the problem. The most relevant proposed solution that I
found came from Scott Blum (
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#)
nearly 2 years ago. Before finding this solution, I was faced with the
problem and as the saying goes, Necessity is the mother of invention, I
came up with my own solution that is very different than Scott's. I posted a
write-up on my solution on the StackOverflow forum (
http://stackoverflow.com/questions/2210226/how-can-i-keep-gwt-from-trying-to-include-every-serializable-class-when-i-use-arr/3385509#3385509),
but unfortunately, I haven't received any feedback on it. I also contact
Scott Blum who suggested that I post my message here (as he hasn't been
involved with GWT-RPC for some time). I am really looking for some
confirmation or at least comments or feedback of some sort on my approach,
so I am hoping that by posting here I can get that; the school of GWT
thought far exceeds my experience with technology. I won't repeat the entire
stackoverflow posting here as
the interested reader can obviously reference it if necessary, but I will
include my version of a RPC-able generic object which is the core of the
solution. If would seem that if GWT could provide a standard object of this
type/functionality, then the masses would...errr might...stop reinventing
the wheel; I am sure that the developers of GWT can do this better than me;
however, there may be a significant downside/short-coming of this approach
that I am overlooking (but at least for now, it is working great in practice
for me).
All thoughts and comments are appreciated!
-Jeff
public class RpcObject implements IsSerializable {
protected HashMapString, IsSerializable rpcObjectWrapper = new
HashMapString, IsSerializable();
/*
* NOTE: The following fields are here to
* trick/fool/work-around/whatever-you-want-to-call-it GWT-RPC's
* serialization policy. Having these types present, even though their
* corresponding fields are never used directly, enables GWT-RPC to
* serialize/deserialize these primitive types if they are encountered
in
* the rpcWrapperObject! Of course GWT-RPC already knows how to
serialize
* all these primitive types, but since, for example, String doesn't
* implement GWT's IsSerializable interface, GWT has no expectation that
it
* should ever be allowed in the rpcWrapperObject instance (and thus
String,
* as well as all the other Java primitives plus Arrays of such types as
* well as List, Set, and Map, won't be part of the serialization policy
of
* the RpcObject type). This is unfortunate because thanks to java type
* erasure, we can easily stuff Strings, Integers, etc into the wrapper
* without any issues; however, GWT-RPC will cowardly refuse to
serialize
* them. Thankfully, it appears that the serialization policy is for the
* RpcObject type as a whole rather than for the rpcObjectWrapper field
* specifically. So, if we just add some dummy fields with these
primitive
* types they will get added to the serialization policy (they are
* effectively white-listed) of the type as a whole, and alas, GWT-RPC
stops
* cowardly refusing to serialize them.
*/
protected Byte _byte;
protected Short _short;
protected Integer _integer;
protected Long _long;
protected Float _float;
protected Double _double;
protected Date _date;
protected Boolean _boolean;
protected Byte[] _bytes;
protected Short[] _shorts;
protected Integer[] _integers;
protected Long[] _longs;
protected Float[] _floats;
protected Double[] _doubles;
protected Date[] _dates;
protected Boolean[] _booleans;
protected ListString _list;
protected SetString _set;
protected MapString, String _map;
public RpcObject() {
super();
}
public RpcObject(final Object value) {
super();
this.setValue(value);
}
@SuppressWarnings(unchecked)
public X X getValue() {
HashMap h = (HashMap) rpcObjectWrapper;
X value = (X) h.get(value);
return value;
}
@SuppressWarnings(unchecked)
public void setValue(Object value) {
HashMap h = (HashMap) rpcObjectWrapper;
h.put(value, value);
}
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Faster edit-distance computation in JsFunctionClusterer (issue669801)
http://gwt-code-reviews.appspot.com/669801/diff/33001/34006
File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java
(right):
http://gwt-code-reviews.appspot.com/669801/diff/33001/34006#newcode43
dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:43:
Pattern.compile(function |[_a-zA-Z$][.$_a-zA-Z0-9]*=function);
This regex will incorrect match vtable declarations of the form:
_.name = function() { ... }
These prototype declarations cannot be re-ordered, so don't let it match
a single '_' symbol.
On 2010/08/05 23:02:48, Alexandre Vassalotti wrote:
On 2010/08/05 19:27:01, zundel wrote:
Wait a minute, what happened to the caret? This means any line with
the
string
function in it will match. Is that what we want?
This is not an issue since the lookingAt() method, which matches only
at the
beginning of a string, is used in isFunctionDeclaration().
http://gwt-code-reviews.appspot.com/669801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
Scott, I'm working on getting rid of it now (I'll create a different bug issue). My quick and dirty attempt to get rid of it had a few issues, so I decided to release the main typeIdArray change first. Yes, I agree, it should be able to be gotten rid of, since it's main purpose was indeed to be nothing more than an index into the typeIdArray table. There are some special cases where it is still used, such as to decide if something is a String/JSO (i.e. there are checks in the code literally for typeId == 2)So, need to factor out those special cases. Also, need to understand whether it will affect deRPC stuff. Jason On Tue, Aug 10, 2010 at 2:38 PM, sco...@google.com wrote: Q: Can Object.typeId be gotten rid of? If not, what else is it being used for? http://gwt-code-reviews.appspot.com/750801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed trim in ValueBoxBase, forcing parsers to handle trim()ing. (issue738801)
http://gwt-code-reviews.appspot.com/738801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Problem in Large scale application development and MVP
I recently tried to follow the Large scale application development and MVP tutorial. The tutorial was great but I am having a hard time with a few things. If you try and add a contact to the list, the contact is created. If you try and add another contact, you are taken to the edit screen of the last contact you created. No more contacts can be added once you add your first contact. What needs to be changed so you can add more than one contact. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the size of a widget in the (issue719802)
http://gwt-code-reviews.appspot.com/719802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Thoughts on GWT-RPC generic object serialization
It seems that the issue of having a mechanism for generic GWT-RPC
object serialization comes up frequently. While the motivation by the
developer for being able to do this in their code varies, the end
result is generally the same: a reference explicitly or implicitly is
made for GWT to serialize java.io.Serializable which then triggers the
GWT compiler to go crazy and generate code for every serializable
object on the class path. In the best case, this merely results in
bloated code; in the worst case, it results in a project that fails on
the server with ClassNotFound exceptions during GWT-RPC (I can provide
the specifics if anyone is interested).
In the situations that I have encountered, the developer typically
wants to build a generic GWT-RPC service where all they know about the
type of the argument(s) or return value is that GWT can serialize
it...the type may be a type from the JRE that GWT emulates (String,
Long, Date, etc) and can serialize or an object of their own creation
which I will assume can be made to implement
com.google.gwt.user.client.rpc.IsSerializable. The other common case
is the desire to pass or return collections such as ListObject or
MapString, Object where, again, the developer only knows that Object
will be of a type that GWT can serialize.
There is a thread from 2008 (http://groups.google.com/group/Google-Web-
Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#) that
proposes one possible workaround. Before finding that solution, I
invented one on my own and posted it in response to a forum post on
the StackOverflow list (http://stackoverflow.com/questions/2210226/how-
can-i-keep-gwt-from-trying-to-include-every-serializable-class-when-i-
use-arr/3385509#3385509); unfortunately, my post hasn't received any
feedback. I don't feel nearly as strongly about the specific
implementation of a solution as I do that developers shouldn't have to
invent workarounds like this on their own. To that end, I am posting
my implementation (see below) for a class called RpcObject, and I
would like feedback: is the implementation sound, or are there
suggestions for improvement? should a class of this sort be provided
by GWT? is there interest in having it be a project of GWT-contrib?
In the event that I am native in my understanding of GWT-RPC and there
is already a better way to accomplish this [or there is one on the
roadmap], please let me know.
-Jeff
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;
import com.google.gwt.user.client.rpc.IsSerializable;
public class RpcObject implements IsSerializable {
protected HashMapString, IsSerializable rpcObjectWrapper = new
HashMapString, IsSerializable();
/*
* NOTE: The following fields are here to
* trick/fool/work-around/whatever-you-want-to-call-it GWT-RPC's
* serialization policy. Having these types present, even though
their
* corresponding fields are never used directly, enables GWT-RPC to
* serialize/deserialize these primitive types if they are
encountered in
* the rpcWrapperObject! Of course GWT-RPC already knows how to
serialize
* all these primitive types, but since, for example, String doesn't
* implement GWT's IsSerializable interface, GWT has no expectation
that it
* should ever be allowed in the rpcWrapperObject instance (and thus
String,
* as well as all the other Java primitives plus Arrays of such types
as
* well as List, Set, and Map, won't be part of the serialization
policy of
* the RpcObject type). This is unfortunate because thanks to java
type
* erasure, we can easily stuff Strings, Integers, etc into the
wrapper
* without any issues; however, GWT-RPC will cowardly refuse to
serialize
* them. Thankfully, it appears that the serialization policy is for
the
* RpcObject type as a whole rather than for the rpcObjectWrapper
field
* specifically. So, if we just add some dummy fields with these
primitive
* types they will get added to the serialization policy (they are
* effectively white-listed) of the type as a whole, and alas, GWT-
RPC stops
* cowardly refusing to serialize them.
*/
protected Byte _byte;
protected Short _short;
protected Integer _integer;
protected Long _long;
protected Float _float;
protected Double _double;
protected Date _date;
protected Boolean _boolean;
protected Byte[] _bytes;
protected Short[] _shorts;
protected Integer[] _integers;
protected Long[] _longs;
protected Float[] _floats;
protected Double[] _doubles;
protected Date[] _dates;
protected Boolean[] _booleans;
protected ListString _list;
protected SetString _set;
protected MapString, String _map;
public
Re: [gwt-contrib] Why is JClassType#getAnnotations() not public?
On Sun, Aug 8, 2010 at 3:57 PM, PhilBeaudoin philippe.beaud...@gmail.comwrote: In one of my generator I would need to scan the list of all annotations in order to find one that is marked with another annotation. Unfortunately, there doesn't seem to be any public mechanism in JClassType to access the list of all annotations. Looking at the class I see: getAnnotations() and getDeclaredAnnotations() that would do exactly what I need, but they have default visibility and are indicated for testing purposes only. Is there any reason why these method couldn't be made public? If you are looking for a particular annotation, why not use jct.getAnnotation(Class) or jct.findAnnotationInTypeHierarchy(Class) if it should be inherited? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Create a red dev mode glass panel when hosted mode fails to load your module, similar to the gra... (issue730802)
Committed in r8509 http://code.google.com/p/google-web-toolkit/source/detail?r=8509 http://gwt-code-reviews.appspot.com/730802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Allow RPC stats system extensions (issue751801)
Reviewers: Dan Rice, scottb, Lex, Description: This patch allows for the extension of the RPC stats system by moving the stats methods into an object, making them non-static. This would allow application developers to extend the ProxyCreator to use a different implementation of the stats methods. Please review this at http://gwt-code-reviews.appspot.com/751801/show Affected files: user/src/com/google/gwt/rpc/client/impl/RpcCallbackAdapter.java user/src/com/google/gwt/rpc/client/impl/RpcServiceProxy.java user/src/com/google/gwt/user/client/rpc/impl/RemoteServiceProxy.java user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java user/src/com/google/gwt/user/client/rpc/impl/RpcStatsContext.java user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] When dev mode fails to load a module, update the $wnd.title with a summary of the (issue750802)
Reviewers: scottb,
Description:
When dev mode fails to load a module, update the $wnd.title with a
summary of the
error, so that the error can be seen even when the browser is minimized
in
task bar. This can be useful when developing by keeping all windows
full-screen,
i.e. it can save the developer from having to CMD-TAB/ALT-TAB between
editor
and browser to see the error. This work continues where r8509 left off.
Fixes Issues: 1617
Review by: sco...@google.com
Please review this at http://gwt-code-reviews.appspot.com/750802/show
Affected files:
M dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
Index: dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html
===
--- dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html (revision
8509)
+++ dev/core/src/com/google/gwt/core/ext/linker/impl/hosted.html (working
copy)
@@ -202,6 +202,8 @@
// Nasty CSS; onresize would be better but the outer window won't let
us add a listener IE.
glassStyle.setExpression(height, document.documentElement.clientHeight);
}
+
+ $doc.title = summary + [ + $doc.title + ];
}
function findPluginObject() {
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Create a red dev mode glass panel when hosted mode fails to load your module, similar to the gra... (issue730802)
Did I already mention how awesome it is that you fixed this? awesome! /kelly On Tue, Aug 10, 2010 at 5:05 PM, fre...@google.com wrote: Committed in r8509 http://code.google.com/p/google-web-toolkit/source/detail?r=8509 http://gwt-code-reviews.appspot.com/730802/show -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: When dev mode fails to load a module, update the $wnd.title with a summary of the (issue750802)
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Comment on CssResource in google-web-toolkit
Comment by ehboto: It would be useful to allow usage of the @media rule in the resource's css file: http://www.w3.org/TR/CSS2/media.html#at-media-rule That way making widgets that work both on the screen and when printed wouldn't require any wacky workarounds. (btw there's already an issue for this http://code.google.com/p/google-web-toolkit/issues/detail?id=4911) For more information: http://code.google.com/p/google-web-toolkit/wiki/CssResource -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] For synthetic this refs, use params rather than fields while in constructors (issue752801)
Reviewers: tobyr, Please review this at http://gwt-code-reviews.appspot.com/752801/show Affected files: M dev/core/src/com/google/gwt/dev/jjs/ast/JField.java M dev/core/src/com/google/gwt/dev/jjs/impl/BuildTypeMap.java M dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [google-gin] Re: [gwt-contrib] RR: What if UiBinder could take a factory?
On Tue, Aug 10, 2010 at 11:01 AM, Peter Schmitt ara...@gmail.com wrote:
I think the scheme I sketched gets around this issue. Gin isn't aware of
any of the generated code. Rather, the generated code is aware of the public
Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just
going to write GWT.create(MyUiBinder), and then call that instance's
setFactory() method with itself. So this code:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
}
makes Gin generate the moral equivalent of
new
MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this);
Yes, this should work. It requires some boilerplate on the ginjector (which
often contains just a single method) but it has the advantage of not
requiring any additional infrastructure.
Also, while I was assuming that for the most part the binder would be
working off of the Ye One True Ginjector, there is no actual requirement
that you do so, nor that your Factory be Ginjector at al. E.g.:
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public static class Factory {
@Inject @MagicScope EventBus eventBus;
FooWidget makeAFoo() {
return new Foo(eventBus);
}
}
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
No problem - this factory is essentially a provider, although in the usual
case it will have more than one creator method? You can also abuse assisted
inject here to have Gin generate the implementation for the factory
interface (assisted inject won't complain if you don't pass any local
variables :).
Slick. I'll have to read up on that.
And if it's possible for one Ginjector to create another (haven't been
paying attention, sorry), that boilerplate could perhaps be even less?
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
@MagicScope
public interface Factory extends Ginjector {
EventBus eventBus;
}
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(Factory factory);
}
}
While this works in theory, you probably want a new ginjector that actually
inherits the injection framework of the original ginjector - otherwise it
won't have any of the bindings. Probably easier to use assisted inject as
outlined above.
I think what we want is a class generated by UiBinder that has @Inject
annotated constructor/fields/methods for its required children and is then
used as input by the Gin generator to wire the injection up. But to
accomplish that, we'll need to fix the issue mentioned above.
How does this sound?
Like it would need a lot more thought and a lot more work :-). (Although
it's a nicely DI-framework-agnostic notion, now that the annotations live in
javax.). We really wouldn't just want limit you to putting @Inject on
everything, you'd want the full gin experience — e.g. to be allowed to put
other annotations on specific fields, right? All of a sudden we have to
provide an annotation syntax for ui.xml.
Don't get me wrong, I would rather fix GWT.create() so that Ginjector
actually could efficiently provide a getInstance(...) method, and to allow
gin to see generated code. But those two conversations never seem to
terminate, and I don't have the chops to just do them myself. So my question
is: if we accept the current limitations, would this change be a worthwhile
incremental step?
Yes, we should do the simple solution first. I'd really like to fix the
generator interaction challenge though, it would solve tons of other
problems as well.
I'll try to get this done, as I think it may solve a number of problems for
me, but no ETA.
Re: the correct solution, I don't think any of us can raise our hand. But I
bet we could get you pointed in the right direction if you want to roll up
your sleeves.
Peter
public interface UiBinderWithFactoryU, O, F extends UiBinderU, O {
/**
* Sets a factory to use when instantiating objects that are not
* provided via @UiFactory methods or @UiField(provided = true)
fields.
* p
* When an instance is needed, a zero args method with an
appropriate
return type
* will be sought on the factory to provide it. If none is found
GWT.create()
* will be used instead.
* p
* It is a compile time error for the factory to provide ambiguous
methods.
*/
setFactory(F factory);
}
You might wind up with code like…
@Inject
public MyWidget(MyUiBinder binder) extends Composite {
public interface MyUiBinder extends UiBinderWithFactoryWidget,
MyWidget,
MyGinjector {
@Inject setFactory(MyGinjector factory);
}
…and a few extra getters on your
[gwt-contrib] Re: Add Mnemonics/Shortcuts for frequently used buttons on the Dev Shell (Swing UI) (issue708801)
What's about a commit to the main trunk? The patch still hasn't been applied although it's been accepted: http://code.google.com/p/google-web-toolkit/issues/detail?id=5150 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
Reviewers: cromwellian, Ray Ryan, robertvawter, Description: Enables setter methods to be directly called on Record/proxy objects, instead of going through a DeltaValueStore. Also removes the now unnecessary DeltaValueStore from the public api. Patch by: amitmanjhi Review by: rjrjr, cromwellian, robertvawter Please review this at http://gwt-code-reviews.appspot.com/752802/show Affected files: M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/ExpenseDetails.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileExpenseEntry.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/client/MobileReportEntry.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/EmployeeRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ExpenseRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ExpenseRequest.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/request/ReportRecord.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/employee/EmployeeDetailsActivity.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/employee/EmployeeEditView.java M bikeshed/src/com/google/gwt/sample/expenses/gwt/ui/report/ReportDetailsActivity.java M user/src/com/google/gwt/app/place/AbstractRecordEditActivity.java M user/src/com/google/gwt/app/place/RecordEditView.java M user/src/com/google/gwt/app/rebind/EditorSupportGenerator.java M user/src/com/google/gwt/requestfactory/client/impl/AbstractRequest.java M user/src/com/google/gwt/requestfactory/client/impl/DeltaValueStoreJsonImpl.java M user/src/com/google/gwt/requestfactory/client/impl/RequestFactoryJsonImpl.java M user/src/com/google/gwt/requestfactory/rebind/RequestFactoryGenerator.java D user/src/com/google/gwt/requestfactory/shared/DeltaValueStore.java M user/src/com/google/gwt/requestfactory/shared/RequestObject.java M user/src/com/google/gwt/valuestore/shared/impl/RecordImpl.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Annotate the SpeedTracer log data with some extra info. (issue753801)
http://gwt-code-reviews.appspot.com/753801/diff/1/3 File dev/core/src/com/google/gwt/dev/javac/CompilationState.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/3#newcode93 dev/core/src/com/google/gwt/dev/javac/CompilationState.java:93: generatedUnitsAddEvent.addData(# new generated units, + generatedUnits.size()); Is this a valid JSON property name? I've nver used a # or spaces in one. http://gwt-code-reviews.appspot.com/753801/diff/1/4 File dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/4#newcode506 dev/core/src/com/google/gwt/dev/javac/JdtCompiler.java:506: jdtCompilerEvent.end(# icus, + icus.size()); same comment http://gwt-code-reviews.appspot.com/753801/diff/1/9 File dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java (right): http://gwt-code-reviews.appspot.com/753801/diff/1/9#newcode94 dev/core/src/com/google/gwt/dev/shell/ShellModuleSpaceHost.java:94: whitespace http://gwt-code-reviews.appspot.com/753801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r8515 committed - PUBLIC: Fix compile errors in user/build.xml compile.tests target....
Revision: 8515
Author: gwt.mirror...@gmail.com
Date: Tue Aug 10 20:34:17 2010
Log: PUBLIC: Fix compile errors in user/build.xml compile.tests target.
Review at http://gwt-code-reviews.appspot.com/749801
Review by: rj...@google.com
http://code.google.com/p/google-web-toolkit/source/detail?r=8515
Modified:
/trunk/user/build.xml
===
--- /trunk/user/build.xml Thu Aug 5 13:48:12 2010
+++ /trunk/user/build.xml Tue Aug 10 20:34:17 2010
@@ -109,6 +109,7 @@
pathelement location=${gwt.tools.lib}/junit/junit-3.8.1.jar /
pathelement
location=${gwt.tools.lib}/selenium/selenium-java-client-driver.jar /
pathelement
location=${gwt.tools}/redist/json/r2_20080312/json-1.5.jar /
+ pathelement
location=${gwt.tools.lib}/javax/validation/validation-api-1.0.0.GA.jar /
path refid=test.extraclasspath /
/classpath
/gwt.javac
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Enables setter methods to be directly called on Record/proxy objects, instead of going through a... (issue752802)
http://gwt-code-reviews.appspot.com/752802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Removed use of a global table (typeIdArray) for testing castability between types. This informa... (issue750801)
I have a working version now that removes the use of the typeId, that's passing our tests. I will clean it up and submit it as a separate patch tomorrow(unless you think it's worth adding to this one?) Jason http://gwt-code-reviews.appspot.com/750801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
