[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
You can extend properties in your own module file, so if a user has a need
in the future to override the proxy superclass, they can +
the new override. You'll see that RPC already uses a
property for settings in the RemoteService.gwt.xml
-Ray
On Thu, Jan 22, 2009 at 11:02 PM, Alex Epshteyn <
alexander.epsht...@gmail.com> wrote:
>
> I agree that an environment variable isn't ideal, but could you
> explain the annotations you listed? Is that a proposed future way to
> access module properties from inside a generator?
> GeneratorContext.getPropertyOracle() is the way to get these at
> runtime, correct?
>
> So do you want me to add name="gwt.rpc.proxySuperClass" values="com.foo.Bar"/> to
> /com/google/gwt/user/RemoteService.gwt.xml ?
>
> I'm fine with that, except I'm not sure about the values attribute. I
> don't want end-user modules to be forced to choose from a pre-defined
> set of values for this property. I want to support providing
> arbitrary subclasses of RemoteServiceProxy.
>
> From the docs:
>
> " :
> Define a property and allowable values (comma-separated identifiers).
> This element is typically used to generate a value that will be
> evaluated by a rule using a element."
>
> Alex
>
> On Fri, Jan 23, 2009 at 1:25 AM, Ray Cromwell
> wrote:
> >
> > Agreed. I used a similar patch in my own implementation a few weeks ago,
> > although yours is simpler. One thing I'd suggest though is to get the
> > superclass setting either from a module property, or from something in
> the
> > type system, or runtime, rather than the environment.
> > e.g.
> >
> >
> > which is kind of an abuse of the property system, but allows compiling
> > different permutations of the app for different environments (e.g. gadget
> vs
> > non-gadget versions) There was some discussion awhile ago of adding new
> > kinds of properties which specify configuration.
> > @GwtProxySuperClass("com.foo.Bar")
> > public interface MyService extends RemoteService { ... }
> >
> > which allows specifying the transport, but does not allow more than 1
> > transport at a time for the same type (without creating subinterfaces)
> > However you could easily do something like:
> >
> > @GwtProxySuperClass("GadgetProxy")
> > public MyGadgetService extends MyService {...}
> > @GwtProxySuperClass("ProtoBufProxy")
> > public MyProtoBufService extends MyService {...}
> > Using environment properties doesn't seem GWT-like to me, since it kind
> of
> > buries flags deep inside implementation code that most users won't see
> and
> > moves it to build scripts. This is one of the things I always disliked
> about
> > Sun's use of -D parameters all over the JRE code, since finding out a
> > complete list of all these magic variables and exactly what they do is
> often
> > difficult. GWT's idiom is usually to embed build specific switches via
> > deferred binding properties.
> > -Ray
> >
> > On Thu, Jan 22, 2009 at 8:27 PM, Alex Epshteyn
> > wrote:
> >>
> >> Anyhow, let's get this thread back on track to being a discussion
> >> about allowing RPC over non-XHR proxy channels like
> >> gadgets.io.makeRequst. You can use my RPC code with or without the
> >> gwt-gadgets library.
> >>
> >> I'd like to get this patch into trunk if no one objects.
> >>
> >> Alex
> >>
> >>
> >>
> >>
> >> On Thu, Jan 22, 2009 at 8:38 PM, Ray Cromwell
> >> wrote:
> >> >
> >> > I don't quite understand this point. Any JSO you create is going to be
> >> > tightly bound to the underlying Gadget/OpenSocial APIs, so what's the
> >> > difference between a JSO binding which is isn't dependency injected,
> vs
> >> > one
> >> > that is, with regard to keeping up with API changes? Are you arguing
> >> > against using GWT JSOs to call OpenSocial APIs, or just trying to
> argue
> >> > against GadgetLinker injecting the reference for you? There seems to
> be
> >> > little difference between writing a native method to get the initial
> >> > reference to an Overlay type, or having it injected for you, with
> >> > respect to
> >> > "fast evolving specs". All the GadgetLinker does is construct an
> >> > instance of
> >> > a type that you tell it and it wouldn't be hard to modify it so inject
> >> > JSO
> >> > Overlays.
> >> > To me, the only issue that controls whether or not you can keep in
> sink
> >> > is
> >> > whether you have access to the mapping source. And even then, that
> isn't
> >> > the
> >> > biggest issue with OpenSocial programming. The actual specs
> >> > 0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish
> >> > they'd
> >> > change faster.
> >> > The real problem with OpenSocial programming, which hits Java
> >> > programmers
> >> > just as hard as JavaScript programmers, is poor container
> >> > implementations,
> >> > and the fact that the spec is designed in a way that virtually
> >> > everything is
> >> > optional to implement. Quick, which containers support notifications,
> >> > requestShareApp, or activities? Which support OAuth?
> >> >
> >> > IMHO, a
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
I agree that an environment variable isn't ideal, but could you
explain the annotations you listed? Is that a proposed future way to
access module properties from inside a generator?
GeneratorContext.getPropertyOracle() is the way to get these at
runtime, correct?
So do you want me to add to
/com/google/gwt/user/RemoteService.gwt.xml ?
I'm fine with that, except I'm not sure about the values attribute. I
don't want end-user modules to be forced to choose from a pre-defined
set of values for this property. I want to support providing
arbitrary subclasses of RemoteServiceProxy.
>From the docs:
" :
Define a property and allowable values (comma-separated identifiers).
This element is typically used to generate a value that will be
evaluated by a rule using a element."
Alex
On Fri, Jan 23, 2009 at 1:25 AM, Ray Cromwell wrote:
>
> Agreed. I used a similar patch in my own implementation a few weeks ago,
> although yours is simpler. One thing I'd suggest though is to get the
> superclass setting either from a module property, or from something in the
> type system, or runtime, rather than the environment.
> e.g.
>
>
> which is kind of an abuse of the property system, but allows compiling
> different permutations of the app for different environments (e.g. gadget vs
> non-gadget versions) There was some discussion awhile ago of adding new
> kinds of properties which specify configuration.
> @GwtProxySuperClass("com.foo.Bar")
> public interface MyService extends RemoteService { ... }
>
> which allows specifying the transport, but does not allow more than 1
> transport at a time for the same type (without creating subinterfaces)
> However you could easily do something like:
>
> @GwtProxySuperClass("GadgetProxy")
> public MyGadgetService extends MyService {...}
> @GwtProxySuperClass("ProtoBufProxy")
> public MyProtoBufService extends MyService {...}
> Using environment properties doesn't seem GWT-like to me, since it kind of
> buries flags deep inside implementation code that most users won't see and
> moves it to build scripts. This is one of the things I always disliked about
> Sun's use of -D parameters all over the JRE code, since finding out a
> complete list of all these magic variables and exactly what they do is often
> difficult. GWT's idiom is usually to embed build specific switches via
> deferred binding properties.
> -Ray
>
> On Thu, Jan 22, 2009 at 8:27 PM, Alex Epshteyn
> wrote:
>>
>> Anyhow, let's get this thread back on track to being a discussion
>> about allowing RPC over non-XHR proxy channels like
>> gadgets.io.makeRequst. You can use my RPC code with or without the
>> gwt-gadgets library.
>>
>> I'd like to get this patch into trunk if no one objects.
>>
>> Alex
>>
>>
>>
>>
>> On Thu, Jan 22, 2009 at 8:38 PM, Ray Cromwell
>> wrote:
>> >
>> > I don't quite understand this point. Any JSO you create is going to be
>> > tightly bound to the underlying Gadget/OpenSocial APIs, so what's the
>> > difference between a JSO binding which is isn't dependency injected, vs
>> > one
>> > that is, with regard to keeping up with API changes? Are you arguing
>> > against using GWT JSOs to call OpenSocial APIs, or just trying to argue
>> > against GadgetLinker injecting the reference for you? There seems to be
>> > little difference between writing a native method to get the initial
>> > reference to an Overlay type, or having it injected for you, with
>> > respect to
>> > "fast evolving specs". All the GadgetLinker does is construct an
>> > instance of
>> > a type that you tell it and it wouldn't be hard to modify it so inject
>> > JSO
>> > Overlays.
>> > To me, the only issue that controls whether or not you can keep in sink
>> > is
>> > whether you have access to the mapping source. And even then, that isn't
>> > the
>> > biggest issue with OpenSocial programming. The actual specs
>> > 0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish
>> > they'd
>> > change faster.
>> > The real problem with OpenSocial programming, which hits Java
>> > programmers
>> > just as hard as JavaScript programmers, is poor container
>> > implementations,
>> > and the fact that the spec is designed in a way that virtually
>> > everything is
>> > optional to implement. Quick, which containers support notifications,
>> > requestShareApp, or activities? Which support OAuth?
>> >
>> > IMHO, a generator which could parse idiomatic JsDoc/Javascript ala Bob's
>> > JS
>> > Interop, and with some extra annotations, automatically generate JSO
>> > bindings, would actually be superior to writing JSOs by hand to keep
>> > them in
>> > sink, or even programming Javascript by hand. Why? Because everytime the
>> > spec is updated, if there was a mismatch, you could detect errors.
>> > However, none of that really matters much, since unless you decide to
>> > target
>> > a single OS container, probably 90% of the work is workarounds of
>> > unsupported or broken features.
>> > -Ray
>> > On Thu, Jan 22, 2009 at 2:17
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Agreed. I used a similar patch in my own implementation a few weeks ago,
although yours is simpler. One thing I'd suggest though is to get the
superclass setting either from a module property, or from something in the
type system, or runtime, rather than the environment.
e.g.
which is kind of an abuse of the property system, but allows compiling
different permutations of the app for different environments (e.g. gadget vs
non-gadget versions) There was some discussion awhile ago of adding new
kinds of properties which specify configuration.
@GwtProxySuperClass("com.foo.Bar")
public interface MyService extends RemoteService { ... }
which allows specifying the transport, but does not allow more than 1
transport at a time for the same type (without creating subinterfaces)
However you could easily do something like:
@GwtProxySuperClass("GadgetProxy")
public MyGadgetService extends MyService {...}
@GwtProxySuperClass("ProtoBufProxy")
public MyProtoBufService extends MyService {...}
Using environment properties doesn't seem GWT-like to me, since it kind of
buries flags deep inside implementation code that most users won't see and
moves it to build scripts. This is one of the things I always disliked about
Sun's use of -D parameters all over the JRE code, since finding out a
complete list of all these magic variables and exactly what they do is often
difficult. GWT's idiom is usually to embed build specific switches via
deferred binding properties.
-Ray
On Thu, Jan 22, 2009 at 8:27 PM, Alex Epshteyn wrote:
>
> Anyhow, let's get this thread back on track to being a discussion
> about allowing RPC over non-XHR proxy channels like
> gadgets.io.makeRequst. You can use my RPC code with or without the
> gwt-gadgets library.
>
> I'd like to get this patch into trunk if no one objects.
>
> Alex
>
>
>
>
> On Thu, Jan 22, 2009 at 8:38 PM, Ray Cromwell
> wrote:
> >
> > I don't quite understand this point. Any JSO you create is going to be
> > tightly bound to the underlying Gadget/OpenSocial APIs, so what's the
> > difference between a JSO binding which is isn't dependency injected, vs
> one
> > that is, with regard to keeping up with API changes? Are you arguing
> > against using GWT JSOs to call OpenSocial APIs, or just trying to argue
> > against GadgetLinker injecting the reference for you? There seems to be
> > little difference between writing a native method to get the initial
> > reference to an Overlay type, or having it injected for you, with respect
> to
> > "fast evolving specs". All the GadgetLinker does is construct an instance
> of
> > a type that you tell it and it wouldn't be hard to modify it so inject
> JSO
> > Overlays.
> > To me, the only issue that controls whether or not you can keep in sink
> is
> > whether you have access to the mapping source. And even then, that isn't
> the
> > biggest issue with OpenSocial programming. The actual specs
> > 0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish
> they'd
> > change faster.
> > The real problem with OpenSocial programming, which hits Java programmers
> > just as hard as JavaScript programmers, is poor container
> implementations,
> > and the fact that the spec is designed in a way that virtually everything
> is
> > optional to implement. Quick, which containers support notifications,
> > requestShareApp, or activities? Which support OAuth?
> >
> > IMHO, a generator which could parse idiomatic JsDoc/Javascript ala Bob's
> JS
> > Interop, and with some extra annotations, automatically generate JSO
> > bindings, would actually be superior to writing JSOs by hand to keep them
> in
> > sink, or even programming Javascript by hand. Why? Because everytime the
> > spec is updated, if there was a mismatch, you could detect errors.
> > However, none of that really matters much, since unless you decide to
> target
> > a single OS container, probably 90% of the work is workarounds of
> > unsupported or broken features.
> > -Ray
> > On Thu, Jan 22, 2009 at 2:17 PM, Alex Epshteyn
> > wrote:
> >>
> >> The reason GWT works is because HTML and Javascript evolve very
> >> slowly. A tight Java binding to a fast-changing Javascript API like
> >> Gadgets or OpenSocial is asking for trouble because you won't be able
> >> to keep updating the Java code fast enough.
> >>
> >> Alex
> >>
> >>
> >> On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell
> >> wrote:
> >> >
> >> > I think there are two issues. One is providing hooks to allow the RPC
> >> > call
> >> > to be dispatched via a customized mechanism. This can range from
> >> > makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer
> >> > RpcChannel. I've brought up this issue time and time again, as I've
> been
> >> > an
> >> > early adopter of writing complex GWT apps inside of Gadgets. I think
> it
> >> > would be useful to revisit the RPC design in the future to make it
> >> > easier to
> >> > plugin custom methods, not just for Gadgets/makeRequest, but also for
> >> > stuff
> >>
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Ray, I'm not arguing against Bob's gwt-gadgets library, if that's what you want to use. I just wanted to point out that it's easy to write social gadgets without it. It's too heavyweight for my liking, but I shouldn't have said anything about that in the first place because that's not the point of this thread. I agree that the difference between container implementations is a big problem with opensocial. I guess you could argue that gwt-gadgets could do for the container differences what GWT did for browser differences. Anyhow, let's get this thread back on track to being a discussion about allowing RPC over non-XHR proxy channels like gadgets.io.makeRequst. You can use my RPC code with or without the gwt-gadgets library. I'd like to get this patch into trunk if no one objects. Alex On Thu, Jan 22, 2009 at 8:38 PM, Ray Cromwell wrote: > > I don't quite understand this point. Any JSO you create is going to be > tightly bound to the underlying Gadget/OpenSocial APIs, so what's the > difference between a JSO binding which is isn't dependency injected, vs one > that is, with regard to keeping up with API changes? Are you arguing > against using GWT JSOs to call OpenSocial APIs, or just trying to argue > against GadgetLinker injecting the reference for you? There seems to be > little difference between writing a native method to get the initial > reference to an Overlay type, or having it injected for you, with respect to > "fast evolving specs". All the GadgetLinker does is construct an instance of > a type that you tell it and it wouldn't be hard to modify it so inject JSO > Overlays. > To me, the only issue that controls whether or not you can keep in sink is > whether you have access to the mapping source. And even then, that isn't the > biggest issue with OpenSocial programming. The actual specs > 0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish they'd > change faster. > The real problem with OpenSocial programming, which hits Java programmers > just as hard as JavaScript programmers, is poor container implementations, > and the fact that the spec is designed in a way that virtually everything is > optional to implement. Quick, which containers support notifications, > requestShareApp, or activities? Which support OAuth? > > IMHO, a generator which could parse idiomatic JsDoc/Javascript ala Bob's JS > Interop, and with some extra annotations, automatically generate JSO > bindings, would actually be superior to writing JSOs by hand to keep them in > sink, or even programming Javascript by hand. Why? Because everytime the > spec is updated, if there was a mismatch, you could detect errors. > However, none of that really matters much, since unless you decide to target > a single OS container, probably 90% of the work is workarounds of > unsupported or broken features. > -Ray > On Thu, Jan 22, 2009 at 2:17 PM, Alex Epshteyn > wrote: >> >> The reason GWT works is because HTML and Javascript evolve very >> slowly. A tight Java binding to a fast-changing Javascript API like >> Gadgets or OpenSocial is asking for trouble because you won't be able >> to keep updating the Java code fast enough. >> >> Alex >> >> >> On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell >> wrote: >> > >> > I think there are two issues. One is providing hooks to allow the RPC >> > call >> > to be dispatched via a customized mechanism. This can range from >> > makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer >> > RpcChannel. I've brought up this issue time and time again, as I've been >> > an >> > early adopter of writing complex GWT apps inside of Gadgets. I think it >> > would be useful to revisit the RPC design in the future to make it >> > easier to >> > plugin custom methods, not just for Gadgets/makeRequest, but also for >> > stuff >> > like JSON wireformats and ProtocolBuffers. >> > The issue of the GadgetLinker manifest generation is separate. I happen >> > to >> > like the concept, but dislike the current implementation. I like the >> > auto-generation of the manifest, the type safety of dependency-injected >> > interfaces. However, the current system is too inflexible. It doesn't >> > support multiple Gadget views, it doesn't support "optional" feature >> > requirements. That is, if you require an optional feature in the >> > manifest, >> > the feature interfaces will still get injected even if they weren't >> > loaded. >> > Simply put, I don't find using annotations, generators, and linkers >> > scary. >> > Code generation is one of the core features of GWT, and nothing new is >> > being >> > added to the Java programming language, as the syntax is part of the >> > Java >> > language. >> > On a wider now, realistically, GALGWT needs official bindings for >> > non-legacy >> > Gadgets and OpenSocial. I've implemented JSOs for most of those >> > privately as >> > Gadget features, but it would be nice to have an officially sanctioned >> > Google binding. >> > >> > -Ray >> > >> > On Th
[gwt-contrib] UIObject.setStyleName(Element, String, boolean) visibility
It occurs to me that the static methods UIObject.setVisible and UIObject.setStyleName are akin to each other -- they're both static, they both alter properties of an Element, and they're both called by public instance methods in UIObject -- yet the former has public visibility whereas the latter is protected. Why not give the latter public visibility also? I'm currently using GWT for a more "traditional" app (langolab.com) and it would be useful to call this method for elements in the page that aren't necessarily in a widget. With the current visibility level my choices are either to duplicate the code or add a utility method to a new class in com.google.gwt.user.client.ui. Curious, Adam --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4519 - in trunk/dev/core/src/com/google/gwt/dev: . shell/tomcat
Author: fabb...@google.com
Date: Thu Jan 22 18:04:36 2009
New Revision: 4519
Added:
trunk/dev/core/src/com/google/gwt/dev/ArgHandlerOutDirDeprecated.java
Modified:
trunk/dev/core/src/com/google/gwt/dev/Compiler.java
trunk/dev/core/src/com/google/gwt/dev/GWTShell.java
trunk/dev/core/src/com/google/gwt/dev/HostedMode.java
trunk/dev/core/src/com/google/gwt/dev/Link.java
trunk/dev/core/src/com/google/gwt/dev/shell/tomcat/EmbeddedTomcatServer.java
Log:
patches for legacy option and property support... these things should go
away "soon," but we need to provide some grace period first.
TBR: jgw
Added: trunk/dev/core/src/com/google/gwt/dev/ArgHandlerOutDirDeprecated.java
==
--- (empty file)
+++ trunk/dev/core/src/com/google/gwt/dev/ArgHandlerOutDirDeprecated.java
Thu Jan 22 18:04:36 2009
@@ -0,0 +1,35 @@
+/**
+ *
+ */
+package com.google.gwt.dev;
+
+import com.google.gwt.dev.util.arg.OptionOutDir;
+import com.google.gwt.util.tools.ArgHandlerOutDir;
+
+import java.io.File;
+
+/**
+ * Deprecated handler for -out options
+ */
+public class ArgHandlerOutDirDeprecated extends ArgHandlerOutDir {
+
+ OptionOutDir option;
+
+ public ArgHandlerOutDirDeprecated(OptionOutDir option) {
+this.option = option;
+ }
+
+ public String getPurpose() {
+return super.getPurpose() + " (deprecated)";
+ }
+
+ public boolean isUndocumented() {
+return true;
+ }
+
+ @Override
+ public void setDir(File dir) {
+option.setOutDir(dir);
+ }
+
+}
Modified: trunk/dev/core/src/com/google/gwt/dev/Compiler.java
==
--- trunk/dev/core/src/com/google/gwt/dev/Compiler.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/Compiler.java Thu Jan 22 18:04:36
2009
@@ -86,6 +86,11 @@
return localWorkers;
}
+@Deprecated
+public File getOutDir() {
+ return linkOptions.getOutDir();
+}
+
public File getWarDir() {
return linkOptions.getWarDir();
}
@@ -98,6 +103,11 @@
this.localWorkers = localWorkers;
}
+@Deprecated
+public void setOutDir(File outDir) {
+ linkOptions.setOutDir(outDir);
+}
+
public void setWarDir(File outDir) {
linkOptions.setWarDir(outDir);
}
Modified: trunk/dev/core/src/com/google/gwt/dev/GWTShell.java
==
--- trunk/dev/core/src/com/google/gwt/dev/GWTShell.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/GWTShell.java Thu Jan 22 18:04:36
2009
@@ -136,6 +136,13 @@
*/
GWTShell gwtShell = new GWTShell();
ArgProcessor argProcessor = new ArgProcessor(gwtShell.options, false,
false);
+
+// deprecated old property way to set outputs
+if (System.getProperty("com.google.gwt.shell.outdir") != null) {
+ gwtShell.options.setOutDir(new
File(System.getProperty("com.google.gwt.shell.outdir")));
+ gwtShell.options.setWorkDir(new
File(System.getProperty("com.google.gwt.shell.outdir")));
+}
+
if (argProcessor.processArgs(args)) {
gwtShell.run();
// Exit w/ success code.
Modified: trunk/dev/core/src/com/google/gwt/dev/HostedMode.java
==
--- trunk/dev/core/src/com/google/gwt/dev/HostedMode.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/HostedMode.java Thu Jan 22
18:04:36 2009
@@ -175,6 +175,7 @@
implements HostedModeOptions {
private File extraDir;
private int localWorkers;
+private File outDir;
private ServletContainerLauncher scl;
private File warDir;
@@ -186,6 +187,11 @@
return localWorkers;
}
+@Deprecated
+public File getOutDir() {
+ return outDir;
+}
+
public ServletContainerLauncher getServletContainerLauncher() {
return scl;
}
@@ -208,6 +214,11 @@
public void setLocalWorkers(int localWorkers) {
this.localWorkers = localWorkers;
+}
+
+@Deprecated
+public void setOutDir(File outDir) {
+ this.outDir = outDir;
}
public void setServletContainerLauncher(ServletContainerLauncher scl) {
Modified: trunk/dev/core/src/com/google/gwt/dev/Link.java
==
--- trunk/dev/core/src/com/google/gwt/dev/Link.java (original)
+++ trunk/dev/core/src/com/google/gwt/dev/Link.java Thu Jan 22 18:04:36 2009
@@ -54,7 +54,7 @@
* Options for Link.
*/
public interface LinkOptions extends CompileTaskOptions, OptionExtraDir,
- OptionWarDir {
+ OptionWarDir, OptionOutDir /*deprecated*/ {
}
static class ArgProcessor extends CompileArgProcessor {
@@ -62,6 +62,7 @@
super(options);
registerHandler(new ArgHandlerExtraDir(options));
registerHandler(new Ar
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
I don't quite understand this point. Any JSO you create is going to be tightly bound to the underlying Gadget/OpenSocial APIs, so what's the difference between a JSO binding which is isn't dependency injected, vs one that is, with regard to keeping up with API changes? Are you arguing against using GWT JSOs to call OpenSocial APIs, or just trying to argue against GadgetLinker injecting the reference for you? There seems to be little difference between writing a native method to get the initial reference to an Overlay type, or having it injected for you, with respect to "fast evolving specs". All the GadgetLinker does is construct an instance of a type that you tell it and it wouldn't be hard to modify it so inject JSO Overlays. To me, the only issue that controls whether or not you can keep in sink is whether you have access to the mapping source. And even then, that isn't the biggest issue with OpenSocial programming. The actual specs 0.6/0.7/0.8/0.81/0.9 etc aren't changing that fast, in fact, I wish they'd change faster. The real problem with OpenSocial programming, which hits Java programmers just as hard as JavaScript programmers, is poor container implementations, and the fact that the spec is designed in a way that virtually everything is optional to implement. Quick, which containers support notifications, requestShareApp, or activities? Which support OAuth? IMHO, a generator which could parse idiomatic JsDoc/Javascript ala Bob's JS Interop, and with some extra annotations, automatically generate JSO bindings, would actually be superior to writing JSOs by hand to keep them in sink, or even programming Javascript by hand. Why? Because everytime the spec is updated, if there was a mismatch, you could detect errors. However, none of that really matters much, since unless you decide to target a single OS container, probably 90% of the work is workarounds of unsupported or broken features. -Ray On Thu, Jan 22, 2009 at 2:17 PM, Alex Epshteyn wrote: > > The reason GWT works is because HTML and Javascript evolve very > slowly. A tight Java binding to a fast-changing Javascript API like > Gadgets or OpenSocial is asking for trouble because you won't be able > to keep updating the Java code fast enough. > > Alex > > > On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell > wrote: > > > > I think there are two issues. One is providing hooks to allow the RPC > call > > to be dispatched via a customized mechanism. This can range from > > makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer > > RpcChannel. I've brought up this issue time and time again, as I've been > an > > early adopter of writing complex GWT apps inside of Gadgets. I think it > > would be useful to revisit the RPC design in the future to make it easier > to > > plugin custom methods, not just for Gadgets/makeRequest, but also for > stuff > > like JSON wireformats and ProtocolBuffers. > > The issue of the GadgetLinker manifest generation is separate. I happen > to > > like the concept, but dislike the current implementation. I like the > > auto-generation of the manifest, the type safety of dependency-injected > > interfaces. However, the current system is too inflexible. It doesn't > > support multiple Gadget views, it doesn't support "optional" feature > > requirements. That is, if you require an optional feature in the > manifest, > > the feature interfaces will still get injected even if they weren't > loaded. > > Simply put, I don't find using annotations, generators, and linkers > scary. > > Code generation is one of the core features of GWT, and nothing new is > being > > added to the Java programming language, as the syntax is part of the Java > > language. > > On a wider now, realistically, GALGWT needs official bindings for > non-legacy > > Gadgets and OpenSocial. I've implemented JSOs for most of those privately > as > > Gadget features, but it would be nice to have an officially sanctioned > > Google binding. > > > > -Ray > > > > On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn > > wrote: > >> > >> Background: > >> > >> OpenSocial containers provide the method gadget.io.makeRequest because > >> gadget scripts aren't able to use XHR due to the SOP. Furthermore, I > >> believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) > >> method that the gwt-gadgets library uses. > >> > >> Now, regarding the gwt-gadgets library, to be blunt, it simply scares > >> me. I don't want all the gadget stuff brought into the Java > >> programming language with interfaces and annotations. Having the > >> bootsrap and gadget.xml generated with a custom linker is scary and > >> unnecessary. This is just asking for trouble with a leaky > >> abstraction. > >> > >> The RPC Problem: > >> > >> It's very easy to write a Google Gadget with GWT without using the gwt- > >> gadgets library. Simply write your gadget.xml by hand (there's not > >> much to it, really), write your GWT app the traditional way, compile > >> it with the XS
[gwt-contrib] [google-web-toolkit commit] r4518 - releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty
Author: sco...@google.com
Date: Thu Jan 22 15:59:26 2009
New Revision: 4518
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Log:
Isolates Jetty's WebAppClassLoader to enforce that the user must supply
server-side libraries into WEB-INF/lib.
Modified:
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
==
---
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
(original)
+++
releases/1.6/dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java
Thu Jan 22 15:59:26 2009
@@ -23,6 +23,7 @@
import org.mortbay.jetty.Server;
import org.mortbay.jetty.nio.SelectChannelConnector;
+import org.mortbay.jetty.webapp.WebAppClassLoader;
import org.mortbay.jetty.webapp.WebAppContext;
import org.mortbay.log.Log;
import org.mortbay.log.Logger;
@@ -132,13 +133,40 @@
}
}
+ /**
+ * Ensures that only Jetty and other server classes can be loaded into
the web
+ * app classloader. This forces the user to put any necessary
dependencies
+ * into WEB-INF/lib.
+ */
+ private static final class FilteringParentClassLoader extends
ClassLoader {
+private WebAppClassLoader child = null;
+private final ClassLoader delegateTo =
Thread.currentThread().getContextClassLoader();
+
+private FilteringParentClassLoader() {
+ super(null);
+}
+
+public void setChild(WebAppClassLoader child) {
+ this.child = child;
+}
+
+@Override
+protected Class findClass(String name) throws
ClassNotFoundException {
+ if (child != null
+ && (child.isServerPath(name) || child.isSystemPath(name))) {
+return delegateTo.loadClass(name);
+ }
+ throw new ClassNotFoundException();
+}
+ }
+
private static class JettyServletContainer extends ServletContainer {
private final int actualPort;
private final File appRootDir;
private final TreeLogger logger;
-private final WebAppContext wac;
private final Server server;
+private final WebAppContext wac;
public JettyServletContainer(TreeLogger logger, Server server,
WebAppContext wac, int actualPort, File appRootDir) {
@@ -222,6 +250,10 @@
// Create a new web app in the war directory.
WebAppContext wac = new
WebAppContext(appRootDir.getAbsolutePath(), "/");
+FilteringParentClassLoader parentClassLoader = new
FilteringParentClassLoader();
+WebAppClassLoader wacl = new WebAppClassLoader(parentClassLoader, wac);
+parentClassLoader.setChild(wacl);
+wac.setClassLoader(wacl);
// Prevent file locking on Windows; pick up file changes.
wac.getInitParams().put(
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Success - I got this to work! Now running GWT-RPC through OpenSocial's gadget.io.makeRequest! Only two lines of code had to be changed in GWT to make the RPC system pluggable. Here is a patch against trunk. Could someone review and approve? The other half consists of custom RequestBuilder and RemoteServiceProxy subclasses. I will continue testing and polishing those and will share them later. Alex On Thu, Jan 22, 2009 at 5:17 PM, Alex Epshteyn wrote: > Yes, the option to extend RPC and gadgets are two separate ideas. > >> Code generation is one of the core features of GWT, and nothing new is being >> added to the Java programming language, as the syntax is part of the Java >> language. > > The reason GWT works is because HTML and Javascript evolve very > slowly. A tight Java binding to a fast-changing Javascript API like > Gadgets or OpenSocial is asking for trouble because you won't be able > to keep updating the Java code fast enough. > > Alex > > > On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell wrote: >> >> I think there are two issues. One is providing hooks to allow the RPC call >> to be dispatched via a customized mechanism. This can range from >> makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer >> RpcChannel. I've brought up this issue time and time again, as I've been an >> early adopter of writing complex GWT apps inside of Gadgets. I think it >> would be useful to revisit the RPC design in the future to make it easier to >> plugin custom methods, not just for Gadgets/makeRequest, but also for stuff >> like JSON wireformats and ProtocolBuffers. >> The issue of the GadgetLinker manifest generation is separate. I happen to >> like the concept, but dislike the current implementation. I like the >> auto-generation of the manifest, the type safety of dependency-injected >> interfaces. However, the current system is too inflexible. It doesn't >> support multiple Gadget views, it doesn't support "optional" feature >> requirements. That is, if you require an optional feature in the manifest, >> the feature interfaces will still get injected even if they weren't loaded. >> Simply put, I don't find using annotations, generators, and linkers scary. >> Code generation is one of the core features of GWT, and nothing new is being >> added to the Java programming language, as the syntax is part of the Java >> language. >> On a wider now, realistically, GALGWT needs official bindings for non-legacy >> Gadgets and OpenSocial. I've implemented JSOs for most of those privately as >> Gadget features, but it would be nice to have an officially sanctioned >> Google binding. >> >> -Ray >> >> On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn >> wrote: >>> >>> Background: >>> >>> OpenSocial containers provide the method gadget.io.makeRequest because >>> gadget scripts aren't able to use XHR due to the SOP. Furthermore, I >>> believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) >>> method that the gwt-gadgets library uses. >>> >>> Now, regarding the gwt-gadgets library, to be blunt, it simply scares >>> me. I don't want all the gadget stuff brought into the Java >>> programming language with interfaces and annotations. Having the >>> bootsrap and gadget.xml generated with a custom linker is scary and >>> unnecessary. This is just asking for trouble with a leaky >>> abstraction. >>> >>> The RPC Problem: >>> >>> It's very easy to write a Google Gadget with GWT without using the gwt- >>> gadgets library. Simply write your gadget.xml by hand (there's not >>> much to it, really), write your GWT app the traditional way, compile >>> it with the XS linker, and write a script tag referencing >>> your .nocache.js script in your gadget.xml. You can call all the >>> OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO >>> overlay types could simplify things a bit). >>> >>> The only problem is RPC. Currently using GWT-RPC in an OpenSocial >>> container seems impossible. You'd have to write a JSON service. >>> >>> The Proposed Solution: >>> >>> This is just a rough sketch, but I think this can be accomplished as >>> follows: >>> >>> 1) Subclass RequestBuilder to use gadgets.io.makeRequest >>> >>> 2) Subclass RemoteServiceProxy and override the protected method >>> doPrepareRequestBuilder to return an instance of your custom >>> RequestBuilder subclass. >>> >>> 3) Modify ProxyCreator to allow setting a custom superclass for the >>> generated proxy class. I.e. allow chaning this line: >>> composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName >>> ()); >>> >>> (Perhaps with a system property defining the class name for starters). >>> >> >> >> >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- rpc_hooks.patch Description: Binary data
[gwt-contrib] RR: cleaner runAsync callback calling
Kathrin, can you review this patch for me? It improves the way runAsync calls its callbacks in two ways: First, if an exception happens while calling a callback, the exception is passed to GWT's global uncaught exception handler. Second, the callbacks happen in the order they are registered. This is done by updating the linked-list code that manages the list of pending runAsync callbacks. In addition to the "callbacks" field pointing to the head of the list of callbacks, there is a "callbacksTail" field that points to the tail of the list. New requests can now easily be added to the end of the list. RunAsyncTest is updated to test for both of these. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- runAsyncCallbacks-r4507.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r4517 - releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/d efaultmuseum
Author: e...@google.com
Date: Thu Jan 22 15:08:07 2009
New Revision: 4517
Modified:
releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForEventsFiring.java
Log:
Typo-o on converting to Event.as.
TBR:jlabanca
Modified:
releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForEventsFiring.java
==
---
releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForEventsFiring.java
(original)
+++
releases/1.6/reference/code-museum/src/com/google/gwt/museum/client/defaultmuseum/VisualsForEventsFiring.java
Thu Jan 22 15:08:07 2009
@@ -215,7 +215,7 @@
* @param event the event that was triggered
*/
private void passTest(NativeEvent event) {
-passTest(Event.as(event).getTypeInt()));
+passTest(Event.as(event).getTypeInt());
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4516 - releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker
Author: amitman...@google.com
Date: Thu Jan 22 14:39:50 2009
New Revision: 4516
Modified:
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityUnitTest.java
Log:
Fixes the test failure. Junit on cmd-line was failing because one of the
classes had a name ending in Test (even though eclipse's junit did not have
a
problem).
Plus, some sort & format.
Patch by: amitmanjhi
Modified:
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityUnitTest.java
==
---
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityUnitTest.java
(original)
+++
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityUnitTest.java
Thu Jan 22 14:39:50 2009
@@ -59,7 +59,7 @@
}
}
- private static class FinalKeywordRefactoring extends
ApiCompatibilityUnitTest {
+ private static class FinalKeywordRefactoring {
private static String getFirstApiSourceForObject() {
StringBuffer sb = new StringBuffer();
sb.append("package java.lang;\n");
@@ -88,9 +88,9 @@
// firstApi is the reference Api
Collection apiChanges = getApiChanges(firstApi,
secondApi);
- assertEquals(
- Arrays.asList(new ApiChange[] {new ApiChange(new MockApiElement(
- "java.lang.Object::foo"), ApiChange.Status.FINAL_ADDED),}),
apiChanges);
+ assertEquals(Arrays.asList(new ApiChange[] {new ApiChange(
+ new MockApiElement("java.lang.Object::foo"),
+ ApiChange.Status.FINAL_ADDED),}), apiChanges);
// secondApi is the reference Api
apiChanges = getApiChanges(secondApi, firstApi);
@@ -109,7 +109,7 @@
* However, if foo(Object ..) is added, it should be okay since JLS
matches
* from the most specific to the least specific.
*/
- private static class MethodOverloadingTest extends
ApiCompatibilityUnitTest {
+ private static class OverloadedMethodRefactoring {
private static String getFirstApiSourceForObject() {
StringBuffer sb = new StringBuffer();
sb.append("package java.lang;\n");
@@ -170,7 +170,7 @@
* to a super class.
*
*/
- private static class SuperClassRefactoring extends
ApiCompatibilityUnitTest {
+ private static class SuperClassRefactoring {
private static String getFirstApiSourceForObject() {
StringBuffer sb = new StringBuffer();
sb.append("package java.lang;\n");
@@ -289,7 +289,7 @@
public void testMethodOverloading() throws NotFoundException,
UnableToCompleteException {
-new MethodOverloadingTest().testBothWays();
+new OverloadedMethodRefactoring().testBothWays();
}
public void testSuperClassRefactoring() throws NotFoundException,
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Yes, the option to extend RPC and gadgets are two separate ideas. > Code generation is one of the core features of GWT, and nothing new is being > added to the Java programming language, as the syntax is part of the Java > language. The reason GWT works is because HTML and Javascript evolve very slowly. A tight Java binding to a fast-changing Javascript API like Gadgets or OpenSocial is asking for trouble because you won't be able to keep updating the Java code fast enough. Alex On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell wrote: > > I think there are two issues. One is providing hooks to allow the RPC call > to be dispatched via a customized mechanism. This can range from > makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer > RpcChannel. I've brought up this issue time and time again, as I've been an > early adopter of writing complex GWT apps inside of Gadgets. I think it > would be useful to revisit the RPC design in the future to make it easier to > plugin custom methods, not just for Gadgets/makeRequest, but also for stuff > like JSON wireformats and ProtocolBuffers. > The issue of the GadgetLinker manifest generation is separate. I happen to > like the concept, but dislike the current implementation. I like the > auto-generation of the manifest, the type safety of dependency-injected > interfaces. However, the current system is too inflexible. It doesn't > support multiple Gadget views, it doesn't support "optional" feature > requirements. That is, if you require an optional feature in the manifest, > the feature interfaces will still get injected even if they weren't loaded. > Simply put, I don't find using annotations, generators, and linkers scary. > Code generation is one of the core features of GWT, and nothing new is being > added to the Java programming language, as the syntax is part of the Java > language. > On a wider now, realistically, GALGWT needs official bindings for non-legacy > Gadgets and OpenSocial. I've implemented JSOs for most of those privately as > Gadget features, but it would be nice to have an officially sanctioned > Google binding. > > -Ray > > On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn > wrote: >> >> Background: >> >> OpenSocial containers provide the method gadget.io.makeRequest because >> gadget scripts aren't able to use XHR due to the SOP. Furthermore, I >> believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) >> method that the gwt-gadgets library uses. >> >> Now, regarding the gwt-gadgets library, to be blunt, it simply scares >> me. I don't want all the gadget stuff brought into the Java >> programming language with interfaces and annotations. Having the >> bootsrap and gadget.xml generated with a custom linker is scary and >> unnecessary. This is just asking for trouble with a leaky >> abstraction. >> >> The RPC Problem: >> >> It's very easy to write a Google Gadget with GWT without using the gwt- >> gadgets library. Simply write your gadget.xml by hand (there's not >> much to it, really), write your GWT app the traditional way, compile >> it with the XS linker, and write a script tag referencing >> your .nocache.js script in your gadget.xml. You can call all the >> OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO >> overlay types could simplify things a bit). >> >> The only problem is RPC. Currently using GWT-RPC in an OpenSocial >> container seems impossible. You'd have to write a JSON service. >> >> The Proposed Solution: >> >> This is just a rough sketch, but I think this can be accomplished as >> follows: >> >> 1) Subclass RequestBuilder to use gadgets.io.makeRequest >> >> 2) Subclass RemoteServiceProxy and override the protected method >> doPrepareRequestBuilder to return an instance of your custom >> RequestBuilder subclass. >> >> 3) Modify ProxyCreator to allow setting a custom superclass for the >> generated proxy class. I.e. allow chaning this line: >> composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName >> ()); >> >> (Perhaps with a system property defining the class name for starters). >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
I think there are two issues. One is providing hooks to allow the RPC call to be dispatched via a customized mechanism. This can range from makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer RpcChannel. I've brought up this issue time and time again, as I've been an early adopter of writing complex GWT apps inside of Gadgets. I think it would be useful to revisit the RPC design in the future to make it easier to plugin custom methods, not just for Gadgets/makeRequest, but also for stuff like JSON wireformats and ProtocolBuffers. The issue of the GadgetLinker manifest generation is separate. I happen to like the concept, but dislike the current implementation. I like the auto-generation of the manifest, the type safety of dependency-injected interfaces. However, the current system is too inflexible. It doesn't support multiple Gadget views, it doesn't support "optional" feature requirements. That is, if you require an optional feature in the manifest, the feature interfaces will still get injected even if they weren't loaded. Simply put, I don't find using annotations, generators, and linkers scary. Code generation is one of the core features of GWT, and nothing new is being added to the Java programming language, as the syntax is part of the Java language. On a wider now, realistically, GALGWT needs official bindings for non-legacy Gadgets and OpenSocial. I've implemented JSOs for most of those privately as Gadget features, but it would be nice to have an officially sanctioned Google binding. -Ray On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn wrote: > > Background: > > OpenSocial containers provide the method gadget.io.makeRequest because > gadget scripts aren't able to use XHR due to the SOP. Furthermore, I > believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) > method that the gwt-gadgets library uses. > > Now, regarding the gwt-gadgets library, to be blunt, it simply scares > me. I don't want all the gadget stuff brought into the Java > programming language with interfaces and annotations. Having the > bootsrap and gadget.xml generated with a custom linker is scary and > unnecessary. This is just asking for trouble with a leaky > abstraction. > > The RPC Problem: > > It's very easy to write a Google Gadget with GWT without using the gwt- > gadgets library. Simply write your gadget.xml by hand (there's not > much to it, really), write your GWT app the traditional way, compile > it with the XS linker, and write a script tag referencing > your .nocache.js script in your gadget.xml. You can call all the > OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO > overlay types could simplify things a bit). > > The only problem is RPC. Currently using GWT-RPC in an OpenSocial > container seems impossible. You'd have to write a JSON service. > > The Proposed Solution: > > This is just a rough sketch, but I think this can be accomplished as > follows: > > 1) Subclass RequestBuilder to use gadgets.io.makeRequest > > 2) Subclass RemoteServiceProxy and override the protected method > doPrepareRequestBuilder to return an instance of your custom > RequestBuilder subclass. > > 3) Modify ProxyCreator to allow setting a custom superclass for the > generated proxy class. I.e. allow chaning this line: > composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName > ()); > > (Perhaps with a system property defining the class name for starters). > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Proposal: Lightweight GWT-RPC implementation for OpenSocial and Gadgets
Background: OpenSocial containers provide the method gadget.io.makeRequest because gadget scripts aren't able to use XHR due to the SOP. Furthermore, I believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) method that the gwt-gadgets library uses. Now, regarding the gwt-gadgets library, to be blunt, it simply scares me. I don't want all the gadget stuff brought into the Java programming language with interfaces and annotations. Having the bootsrap and gadget.xml generated with a custom linker is scary and unnecessary. This is just asking for trouble with a leaky abstraction. The RPC Problem: It's very easy to write a Google Gadget with GWT without using the gwt- gadgets library. Simply write your gadget.xml by hand (there's not much to it, really), write your GWT app the traditional way, compile it with the XS linker, and write a script tag referencing your .nocache.js script in your gadget.xml. You can call all the OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO overlay types could simplify things a bit). The only problem is RPC. Currently using GWT-RPC in an OpenSocial container seems impossible. You'd have to write a JSON service. The Proposed Solution: This is just a rough sketch, but I think this can be accomplished as follows: 1) Subclass RequestBuilder to use gadgets.io.makeRequest 2) Subclass RemoteServiceProxy and override the protected method doPrepareRequestBuilder to return an instance of your custom RequestBuilder subclass. 3) Modify ProxyCreator to allow setting a custom superclass for the generated proxy class. I.e. allow chaning this line: composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName ()); (Perhaps with a system property defining the class name for starters). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on WAR_Design_1_6 in google-web-toolkit
Comment by srdrucker: A qualified.ModuleName/ directory for GWT artifacts sounds great. However, I don't see a need to call the nocache file qualified.ModuleName.nocache.js, it could just be nocache.js. Then, in MyProject.html, you could just have src="qualified.ModuleName/nocache.js" for javascript loading. For example, src="com.google.gwt.sample.Hello/nocache.js". For more information: http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code Review for 1.6: Removes unused HasHandlers#isEventHandled
Doesn't bother me, I just didn't want it in the public api. On Thu, Jan 22, 2009 at 11:09 AM, Emily Crutcher wrote: > Do you mind if I put this method back into the concrete HandlerManager > class? As having it saves about 200 milliseconds per user minute when there > is no event preview installed on the event stack. > > Cheers, > > Emily > > > > On Wed, Jan 21, 2009 at 7:35 PM, wrote: > >> Committed to releases/1.6 @r4509 >> >> >> On 2009/01/21 21:46:53, jgw wrote: >> >>> On 2009/01/21 19:04:33, rjrjr wrote: >>> > >>> >>> LGTM. I can't think of any use case that really justifies adding this >>> >> extra >> >>> complexity to the HasHandlers interface (certainly not one that >>> >> couldn't be >> >>> easily worked around). The fact that there are no callers anywhere in >>> >> the system >> >>> makes that even more clear to me. >>> >> >> >> >> http://gwt-code-reviews.appspot.com/2209 >> > > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4514 - in releases/1.6/tools/api-checker: config src/com/google/gwt/tools/apichecker test/com/go...
Author: amitman...@google.com
Date: Thu Jan 22 10:44:19 2009
New Revision: 4514
Added:
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityUnitTest.java
Modified:
releases/1.6/tools/api-checker/config/gwt15_16userApi.conf
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClass.java
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClassDiffGenerator.java
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiMethod.java
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiCompatibilityTest.java
releases/1.6/tools/api-checker/test/com/google/gwt/tools/apichecker/ApiContainerTest.java
Log:
This patch adds a modular testing framework for adding ApiChecker tests. In
addition, it fixes the following 3 cases where the ApiChecker was wrong and
adds tests for each case.
(i) A api class is made FINAL and simultaneously the FINAL keyword is
removed from its methods.
(ii) An api class's methods are overloaded and the overloading is such that
the
methods are "compatible."
(iii) A api class's fields are moved to its superclass.
Patch by: amitmanjhi
Review by: ecc (desk review)
Modified: releases/1.6/tools/api-checker/config/gwt15_16userApi.conf
==
--- releases/1.6/tools/api-checker/config/gwt15_16userApi.conf (original)
+++ releases/1.6/tools/api-checker/config/gwt15_16userApi.conf Thu Jan 22
10:44:19 2009
@@ -96,6 +96,5 @@
# to be hard. Come back and fix this issue, if more such cases come up.
java.lang.StringBuilder::append(Ljava/lang/StringBuffer;)
OVERRIDABLE_METHOD_ARGUMENT_TYPE_CHANGE
com.google.gwt.user.client.ui.Button::Button(Ljava/lang/String;Lcom/google/gwt/user/client/ui/ClickListener;)
OVERLOADED_METHOD_CALL
-com.google.gwt.user.client.ui.MultiWordSuggestOracle::addAll(Ljava/util/Collection;)
FINAL_ADDED
com.google.gwt.user.client.ui.ToggleButton::ToggleButton(Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/Image;Lcom/google/gwt/user/client/ui/ClickListener;)
OVERLOADED_METHOD_CALL
com.google.gwt.user.client.ui.Tree::setImageBase(Ljava/lang/String;)
MISSING
Modified:
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClass.java
==
---
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClass.java
(original)
+++
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClass.java
Thu Jan 22 10:44:19 2009
@@ -225,8 +225,7 @@
JField fields[] = getAccessibleFields();
for (JField field : fields) {
if (isApiMember(field)) {
-apiFields.put(ApiField.computeApiSignature(field), new
ApiField(field,
-this));
+apiFields.put(field.getName(), new ApiField(field, this));
} else {
notAddedFields.add(field.toString());
}
Modified:
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClassDiffGenerator.java
==
---
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClassDiffGenerator.java
(original)
+++
releases/1.6/tools/api-checker/src/com/google/gwt/tools/apichecker/ApiClassDiffGenerator.java
Thu Jan 22 10:44:19 2009
@@ -190,21 +190,57 @@
return collection;
}
- private boolean isIncompatibileDueToMethodOverloading(
+ /**
+ * Attempts to find out if a methodName(null) call previously succeeded,
and
+ * would fail with the new Api. Currently, this method is simple.
+ * TODO(amitmanjhi): generalize this method.
+ *
+ * @param methodsInNew Candidate methods in the new Api
+ * @param methodsInExisting Candidate methods in the existing Api.
+ * @return the possible incompatibilities due to method overloading.
+ */
+ private Map
getOverloadedMethodIncompatibility(
Set methodsInNew,
Set methodsInExisting) {
if (!ApiCompatibilityChecker.API_SOURCE_COMPATIBILITY
|| methodsInExisting.size() != 1 || methodsInNew.size() <= 1) {
- return false;
+ return Collections.emptyMap();
}
-String signature = methodsInExisting.toArray(new
ApiAbstractMethod[0])[0].getCoarseSignature();
-int numMatchingSignature = 0;
+ApiAbstractMethod existingMethod = methodsInExisting.toArray(new
ApiAbstractMethod[0])[0];
+String signature = existingMethod.getCoarseSignature();
+List matchingMethods = new
ArrayList();
for (ApiAbstractMethod current : methodsInNew) {
if (current.getCoarseSignature().equals(signature)) {
-++numMatchingSignature;
+matchingMethods.add(current);
+ }
+}
+if (isPairwiseCompatible(matchingMethods)) {
+ return Collections.emptyMap();
+}
+Map incomp
[gwt-contrib] Re: Code Review for 1.6: Removes unused HasHandlers#isEventHandled
Do you mind if I put this method back into the concrete HandlerManager class? As having it saves about 200 milliseconds per user minute when there is no event preview installed on the event stack. Cheers, Emily On Wed, Jan 21, 2009 at 7:35 PM, wrote: > Committed to releases/1.6 @r4509 > > > On 2009/01/21 21:46:53, jgw wrote: > >> On 2009/01/21 19:04:33, rjrjr wrote: >> > >> >> LGTM. I can't think of any use case that really justifies adding this >> > extra > >> complexity to the HasHandlers interface (certainly not one that >> > couldn't be > >> easily worked around). The fact that there are no callers anywhere in >> > the system > >> makes that even more clear to me. >> > > > > http://gwt-code-reviews.appspot.com/2209 > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r4513 - releases/1.6
On Thu, Jan 22, 2009 at 12:17 PM, Scott Blum wrote: > What version of svn are you using? I'm using 1.5.x, and that flag for me > means the merge will definitely finish, albeit with conflicts, rather than > prompting you for every conflict encountered (which hangs the merge waiting > for you input). That is the default behavior for older versions of svn. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Browser-agnostic RequestBuilder available in Core?
The general plan seems fine to me, although I doubt I'm qualified to comment.
I do have a question regarding the implementation, though. Given that
you first check
if ($wnd.XMLHttpRequest)
and then have the cascading try blocks in the _else_ case, what's the
point in trying to new an XMLHttpRequest when you've already
determined that XMLHttpRequest is false-y and therefore not a
function?
It seems to me that you should be able to either use the code without
the new catch block or do away with the if-check by moving the new
XMLHttpRequest() into the first of the cascaded trys, like so:
try {
// recent IE and non-IE
return new XMLHttpRequest();
}
catch (e) {
try {
// less recent IE
return new ActiveXObject('MSXML2.XMLHTTP.3.0');
}
catch (e) {
// even less recent IE
return new new ActiveXObject("Microsoft.XMLHTTP");
}
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: [google-web-toolkit commit] r4513 - releases/1.6
What version of svn are you using? I'm using 1.5.x, and that flag for me means the merge will definitely finish, albeit with conflicts, rather than prompting you for every conflict encountered (which hangs the merge waiting for you input). On Thu, Jan 22, 2009 at 11:40 AM, wrote: > > Author: rj...@google.com > Date: Thu Jan 22 08:34:50 2009 > New Revision: 4513 > > Modified: >releases/1.6/branch-info.txt > > Log: > Updates 1.6 branch-info.txt to reflect today's merge (490:4497,4498:4511). > > Note that --accept=postpone has been dropped. svn says there is no such > thing. > > LGTM from jgw via chat > > > > Modified: releases/1.6/branch-info.txt > > == > --- releases/1.6/branch-info.txt(original) > +++ releases/1.6/branch-info.txtThu Jan 22 08:34:50 2009 > @@ -26,6 +26,7 @@ > /releases/1.6/@r4385:4459 was merged (r4488) into trunk > /releases/1.6/@r4359:4490 was merged (r4491) into trunk > /releases/1.6/@c4498 was merged (r4499) into trunk > +/releases/1.6/@r4490:4497,4498:4511 was merged (r4512) into trunk, > skipping c4498 (cherry picked above) > > The next merge into trunk will be: > -svn merge --accept=postpone -r4490:4498,4499: > https://google-web-toolkit.googlecode.com/svn/releases/1.6 . > +svn merge -r4511: > https://google-web-toolkit.googlecode.com/svn/releases/1.6 . > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Browser-agnostic RequestBuilder available in Core?
SGTM.
On Thu, Jan 22, 2009 at 12:14 PM, Lex Spoon wrote:
>
> I'd like runAsync to use XHR for the iframe linker, so that GWT
> applications can get timely notification if an async code download
> fails for any reason.
>
> I've outlined all the code changes, but there is a remaining question
> about how the runAsync support should access XHR. Ten minutes of
> reading through RequestBuilder and related classes is very convincing
> that that's the code to use. It's a classic case where different
> browsers do a variety of weird and quirky things, and there are
> solutions to all the known quirks already implemented in those
> classes.
>
> The problem is that GWT.runAsync is in Core, RequestBuilder requires
> UserAgent, and Core is not supposed to require UserAgent.
>
> To solve this problem, how about we make a generic RequestBuilder that
> can be used in Core, and then add deferred bindings for the common
> case that UserAgent is included? It would be analogous to what we do
> for StringBuffer.
>
> After looking at the implementation, I believe the only thing
> sensitive to the user agent is the method doCreateXmlHTTPRequest().
> The rest of the code is shared. If that's the case, wouldn't it be
> possible to define a generic doCreateXmlHTTPRequest that handles all
> browsers? It would look like the current IE implementation except
> with an additional catch block:
>
>
> @Override
> protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
>if ($wnd.XMLHttpRequest) {
> return new XMLHttpRequest();
>} else {
> try {
>return new ActiveXObject('MSXML2.XMLHTTP.3.0');
> } catch (e) {
>try {
> return new ActiveXObject("Microsoft.XMLHTTP");
>} catch (e) {
> // new catch block
> return new XMLHttpRequest();
>}
> }
>}
> }-*/;
>
>
> Assuming the above implementation is reliable, HTTPRequestImpl could
> use it as the implementation in the base class. We could add a new
> class HTTPRequestImplNonIE6 that has the simple "return new
> XMLHttpRequest" that works on all non-IE browsers.
>
> The modules would be changed as follows:
>
> Core would inherit HTTP, and thus get a functioning but suboptimal
> RequestBuilder
>
> HTTPRequest would change its default binding of HTTPRequestImpl to
> HTTPRequestImplNonIE6
>
>
>
> Before I experiment further, does anyone spot anything to worry about?
>
>
> Lex
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Browser-agnostic RequestBuilder available in Core?
I'd like runAsync to use XHR for the iframe linker, so that GWT
applications can get timely notification if an async code download
fails for any reason.
I've outlined all the code changes, but there is a remaining question
about how the runAsync support should access XHR. Ten minutes of
reading through RequestBuilder and related classes is very convincing
that that's the code to use. It's a classic case where different
browsers do a variety of weird and quirky things, and there are
solutions to all the known quirks already implemented in those
classes.
The problem is that GWT.runAsync is in Core, RequestBuilder requires
UserAgent, and Core is not supposed to require UserAgent.
To solve this problem, how about we make a generic RequestBuilder that
can be used in Core, and then add deferred bindings for the common
case that UserAgent is included? It would be analogous to what we do
for StringBuffer.
After looking at the implementation, I believe the only thing
sensitive to the user agent is the method doCreateXmlHTTPRequest().
The rest of the code is shared. If that's the case, wouldn't it be
possible to define a generic doCreateXmlHTTPRequest that handles all
browsers? It would look like the current IE implementation except
with an additional catch block:
@Override
protected native JavaScriptObject doCreateXmlHTTPRequest() /*-{
if ($wnd.XMLHttpRequest) {
return new XMLHttpRequest();
} else {
try {
return new ActiveXObject('MSXML2.XMLHTTP.3.0');
} catch (e) {
try {
return new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {
// new catch block
return new XMLHttpRequest();
}
}
}
}-*/;
Assuming the above implementation is reliable, HTTPRequestImpl could
use it as the implementation in the base class. We could add a new
class HTTPRequestImplNonIE6 that has the simple "return new
XMLHttpRequest" that works on all non-IE browsers.
The modules would be changed as follows:
Core would inherit HTTP, and thus get a functioning but suboptimal
RequestBuilder
HTTPRequest would change its default binding of HTTPRequestImpl to
HTTPRequestImplNonIE6
Before I experiment further, does anyone spot anything to worry about?
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r4513 - releases/1.6
Author: rj...@google.com Date: Thu Jan 22 08:34:50 2009 New Revision: 4513 Modified: releases/1.6/branch-info.txt Log: Updates 1.6 branch-info.txt to reflect today's merge (490:4497,4498:4511). Note that --accept=postpone has been dropped. svn says there is no such thing. LGTM from jgw via chat Modified: releases/1.6/branch-info.txt == --- releases/1.6/branch-info.txt(original) +++ releases/1.6/branch-info.txtThu Jan 22 08:34:50 2009 @@ -26,6 +26,7 @@ /releases/1.6/@r4385:4459 was merged (r4488) into trunk /releases/1.6/@r4359:4490 was merged (r4491) into trunk /releases/1.6/@c4498 was merged (r4499) into trunk +/releases/1.6/@r4490:4497,4498:4511 was merged (r4512) into trunk, skipping c4498 (cherry picked above) The next merge into trunk will be: -svn merge --accept=postpone -r4490:4498,4499: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . +svn merge -r4511: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review: update 1.6 branch-info.txt
Commited at r4513 http://gwt-code-reviews.appspot.com/2011 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review: merge 1.6 to trunk
On 2009/01/22 15:35:22, rjrjr wrote: > LGTM from Joel via chat. Submitted at r4512 http://gwt-code-reviews.appspot.com/2210 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5.3: Type mismatch with enum in parameterized class.
And if I'd been silly enough to bet against you, Scott, then I
would've lost. For posterity:
1. SVN r4361 contains the updated JDT. I copied that to my 1.5 release branch.
2. SVN r4362 contains a small code change to LongFromJSNIChecker.java.
I applied that to my 1.5 branch.
3. SVN r4362 also contains the change to dev/core/build.xml to use the
new jar. Applied that.
4. Build and enjoy.
Thank you very much, Scott. This duct tape should hold until I can
upgrade to 1.6.
@Bruce - I'm eagerly waiting the turning of that corner!
Love the toolkit. Love the fast, friendly, free support. Thank you all!
- Isaac
On Wed, Jan 21, 2009 at 6:55 PM, Scott Blum wrote:
> Isaac, I would put money on our updating to a newer version of JDT. I'd
> find where Lex committed this upgrade... if there are no code changes, you
> might try putting the newer JDT higher on the classpath as a test. If that
> works, simple jar surgery should get you where you want to go.
>
> On Wed, Jan 21, 2009 at 10:54 AM, Isaac Truett wrote:
>>
>> I've found an interesting error in GWT 1.5.3:
>>
>> [ERROR] Line 14: Type mismatch: cannot convert from
>> Test.Parametric.Number
>> s to Test.Parametric.Numbers
>> [ERROR] Line 17: Type mismatch: cannot convert from
>> Test.Parametric.Number
>> s to Test.Parametric.Numbers
>> Compiling module test.Test
>> Computing all possible rebind results for 'test.client.Test'
>> Rebinding test.client.Test
>> Checking rule > class='com.google.gwt.user.rebind.ui.ImageBun
>> dleGenerator'/>
>> [ERROR] Unable to find type 'test.client.Test'
>>[ERROR] Hint: Previous compiler errors may have made this type
>> unava
>> ilable
>>[ERROR] Hint: Check the inheritance chain from your module; it
>> may n
>> ot be inheriting a required module or a module may not be adding its
>> source path
>> entries properly
>>
>>
>> To reproduce:
>>
>> public class Test implements EntryPoint {
>> static class Parametric {
>>enum Numbers {
>> ONE, TWO;
>>}
>> }
>>
>> public void onModuleLoad() {
>>switch (Parametric.Numbers.valueOf("ONE")) {
>> case ONE: // Line 14
>>System.out.println("ONE");
>>break;
>> case TWO: // Line 17
>>System.out.println("ONE");
>>break;
>>}
>> }
>> }
>>
>> Removing the parameter from the type enclosing the enum fixes the problem.
>>
>> The above *works* in trunk and 1.6, but I searched a little bit and I
>> couldn't find anything in the issue tracker that appeared related.
>> Upgrading to 1.6/trunk isn't a good option for me at the moment, so
>> I'm hoping that someone has seen this before and could help me find
>> the change that fixed it. If it's a simple patch, I can apply it to
>> 1.5.3 until such time as an upgrade is possible. Moving the enum to a
>> non-parameterized type would probably work as well, but I'm loathe to
>> do too much redesign on account of a compiler bug that appears to
>> already have been fixed.
>>
>>
>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Code review: update 1.6 branch-info.txt
Reviewers: jgw, Description: Updates 1.6 branch-info.txt to reflect today's merge (490:4497,4498:4511). () to be updated when merge lands. Note that --accept=postpone has been dropped. svn says there is no such thing. Please review this at http://gwt-code-reviews.appspot.com/2011 Affected files: branch-info.txt Index: branch-info.txt === --- branch-info.txt (revision 4511) +++ branch-info.txt (working copy) @@ -26,6 +26,7 @@ /releases/1.6/@r4385:4459 was merged (r4488) into trunk /releases/1.6/@r4359:4490 was merged (r4491) into trunk /releases/1.6/@c4498 was merged (r4499) into trunk +/releases/1.6/@r4490:4497,4498:4511 was merged () into trunk, skipping c4498 (cherry picked above) The next merge into trunk will be: -svn merge --accept=postpone -r4490:4498,4499: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . +svn merge -r4511: https://google-web-toolkit.googlecode.com/svn/releases/1.6 . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Code review: merge 1.6 to trunk
Reviewers: jgw, Description: svn merge -r4490:4497 https://google-web-toolkit.googlecode.com/svn/releases/1.6 . svn merge -r4498:4511 https://google-web-toolkit.googlecode.com/svn/releases/1.6 . Note that we skip 4498 which was previously cherry picked (tmp dir fix), and 4499 (the merge of the cherry pick, not strictly necessary, but hey) Please review this at http://gwt-code-reviews.appspot.com/2210 Affected files: dev/core/src/com/google/gwt/dev/Compiler.java dev/core/src/com/google/gwt/dev/GWTCompiler.java dev/core/src/com/google/gwt/dev/shell/tomcat/EmbeddedTomcatServer.java dev/core/src/org/apache/catalina/loader/WebappLoader.java eclipse/README.txt user/src/com/google/gwt/event/Event.gwt.xml user/src/com/google/gwt/event/dom/client/DomEvent.java user/src/com/google/gwt/event/logical/shared/BeforeSelectionEvent.java user/src/com/google/gwt/event/logical/shared/CloseEvent.java user/src/com/google/gwt/event/logical/shared/HighlightEvent.java user/src/com/google/gwt/event/logical/shared/OpenEvent.java user/src/com/google/gwt/event/logical/shared/ResizeEvent.java user/src/com/google/gwt/event/logical/shared/SelectionEvent.java user/src/com/google/gwt/event/logical/shared/ShowRangeEvent.java user/src/com/google/gwt/event/logical/shared/ValueChangeEvent.java user/src/com/google/gwt/event/shared/HandlerManager.java user/src/com/google/gwt/event/shared/HasHandlers.java user/src/com/google/gwt/user/User.gwt.xml user/src/com/google/gwt/user/client/DOM.java user/src/com/google/gwt/user/client/History.java user/src/com/google/gwt/user/client/ListenerWrapper.java user/src/com/google/gwt/user/client/Window.java user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java user/src/com/google/gwt/user/client/impl/HistoryImpl.java user/src/com/google/gwt/user/client/ui/DisclosurePanel.java user/src/com/google/gwt/user/client/ui/FocusPanel.java user/src/com/google/gwt/user/client/ui/FocusWidget.java user/src/com/google/gwt/user/client/ui/FormPanel.java user/src/com/google/gwt/user/client/ui/HTMLTable.java user/src/com/google/gwt/user/client/ui/Hyperlink.java user/src/com/google/gwt/user/client/ui/Image.java user/src/com/google/gwt/user/client/ui/Label.java user/src/com/google/gwt/user/client/ui/ListBox.java user/src/com/google/gwt/user/client/ui/ListenerWrapper.java user/src/com/google/gwt/user/client/ui/PopupPanel.java user/src/com/google/gwt/user/client/ui/ScrollPanel.java user/src/com/google/gwt/user/client/ui/SuggestBox.java user/src/com/google/gwt/user/client/ui/TabBar.java user/src/com/google/gwt/user/client/ui/TabPanel.java user/src/com/google/gwt/user/client/ui/TextBoxBase.java user/src/com/google/gwt/user/client/ui/Tree.java user/src/com/google/gwt/user/client/ui/TreeItem.java user/src/com/google/gwt/user/client/ui/Widget.java user/src/com/google/gwt/user/datepicker/client/DateChangeEvent.java user/super/com/google/gwt/junit/translatable/com/google/gwt/junit/client/GWTTestCase.java user/test/com/google/gwt/event/shared/HandlerManagerTest.java user/test/com/google/gwt/junit/client/TestManualAsync.java user/test/com/google/gwt/user/client/CommandExecutorTest.java user/test/com/google/gwt/user/client/ui/DisclosurePanelTest.java user/test/com/google/gwt/user/datepicker/client/DateChangeEventTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: CSS for ScrollTable out of date
Thanks John, that works :) -- Arthur Kalmenson On Wed, Jan 21, 2009 at 4:05 PM, John LaBanca wrote: > You can use the CSS from the gen2 demo: > http://code.google.com/p/google-web-toolkit-incubator/source/browse/trunk/src/com/google/gwt/demos/scrolltable/public/ScrollTableDemo.css > > And the image: > http://code.google.com/p/google-web-toolkit-incubator/source/browse/#svn/trunk/src/com/google/gwt/demos/scrolltable/public/images%3Fstate%3Dclosed > > Hope this helps. > > Thanks, > John LaBanca > jlaba...@google.com > > > On Wed, Jan 21, 2009 at 3:02 PM, Arthur Kalmenson > wrote: >> >> Hello everyone, >> >> I've tried to play around with the gen2 ScrollTable and I found that >> the CSS posted here: >> http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable >> doesn't work. thomas.husfeldt commented 7 comments from the bottom >> with some updated CSS that sort of works (not as nice as the demo). Is >> there any CSS available that works with the gen2 ScrollTable? Thank >> you. >> >> Regards, >> -- >> Arthur Kalmenson >> >> > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
