[gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
*Appendix: Old way vs. New way@JsExport @JsTypeclass MyClass
{}@Js(exports=ALL)class MyClass {}@JsExportclass MyClass
{}@Js(exports=STATIC_MEMBERS)class MyClass {}@JsExport(“Name”)class MyClass
{}@JsExport(“a.b.c.someName”)class MyClass {}@Js(name=”Name”,
namespace=GLOBAL, exports=STATIC_MEMBERS)class MyClass {}@Js(name=”Name”,
namespace=”a.b.c”, exports=STATIC_MEMBERS)class MyClass {}Also see
(*)@JsTypeclass MyClass {}@Js(exports=INSTANCE_MEMBERS)class MyClass
{}@JsTypeinterface MyInterface{}@Js(exports=INSTANCE_MEMBERS)interface
MyInterface{}@JsTypeinterface ImportedLibrary{}@Jsinterface
ImportedLibrary{}@JsTypeinterface
ImportedLibraryCallback{}@Js(exports=INSTANCE_MEMBERS)interface
ImportedLibraryCallback{}@JsExportstatic void
someStaticMethod{}@Js(export=true)static void
someStaticMethod{}@JsExport(“someName”)static void
someStaticMethod{}@JsExport(“a.b.c.someName”)static void
someStaticMethod{}@Js(name=”someName”, namespace=GLOBAL, export=true)static
void someStaticMethod{}@Js(name=”someName”, namespace=”a.b.c”,
export=true)static void someStaticMethod{}Also see (*)@JsNoExportstatic
void someStaticMethod{}@Js(ignore=true) or @Js(export=false)static void
someStaticMethod{}@JsNoExportvoid someMethod{}@Js(ignore=true)void
someMethod{}@JsPropertyvoid someMethod{}@Js(property=true)void
someMethod{}(*) In most of the cases, export name is provided for changing
the simple name (not the fully qualified name). In those cases, namespace
attribute doesn’t need to be set. Appendix: (ALTERNATIVE) Old way vs. New
way@JsExport @JsTypeclass MyClass {}@JsType(exports=ALL)class MyClass
{}@JsExportclass MyClass {}@JsType(exports=STATIC_MEMBERS)class MyClass
{}@JsExport(“Name”)class MyClass {}@JsExport(“a.b.c.someName”)class MyClass
{}@JsNamespace(GLOBAL)@JsType(name=”Name”, exports=STATIC_MEMBERS)class
MyClass {}@JsNamespace(“a.b.c”)@JsType(name=”Name”,
exports=STATIC_MEMBERS)class MyClass {}Also see (*)@JsTypeclass MyClass
{}@JsType(exports=INSTANCE_MEMBERS)class MyClass {}@JsTypeinterface
MyInterface{}@JsType(exports=INSTANCE_MEMBERS)interface
MyInterface{}@JsTypeinterface ImportedLibrary{}@JsTypeinterface
ImportedLibrary{}@JsTypeinterface
ImportedLibraryCallback{}@JsType(exports=INSTANCE_MEMBERS)interface
ImportedLibraryCallback{}@JsExportstatic void
someStaticMethod{}@JsMember(export=true)static void
someStaticMethod{}@JsExport(“someName”)static void
someStaticMethod{}@JsExport(“a.b.c.someName”)static void
someStaticMethod{}@JsNamespace(GLOBAL)@JsMember(name=”someName”,
export=true)static void
someStaticMethod{}@JsNamespace(“a.b.c.”)@JsMember(name=”someName”,
export=true)static void someStaticMethod{}Also see (*)@JsNoExportstatic
void someStaticMethod{}@JsMember(ignore=true) or
@JsMember(export=false)static void someStaticMethod{}@JsNoExportvoid
someMethod{}@JsMember(ignore=true)void someMethod{}@JsPropertyvoid
someMethod{}@JsMember(property=true)void someMethod{}(*) In most of the
cases, export name is provided for changing the simple name (not the fully
qualified name). In those cases, JsNamespace doesn’t need to be set.*
On Tue, Apr 21, 2015 at 11:41 AM, Goktug Gokdogan gok...@google.com wrote:
There is some upcoming changes to JsInteorp in preparation toward v1.0
release.
The most major change is to the annotations and their meanings. Here is
the doc explaining the changes and the reasoning. We are looking for your
feedback, especially on alternatives.
*Issues with existing design and annotations 1. @JsExport/@JsType slicing
is not intuitive for a lot of people esp. with gwt-exporter background.
People are confused about when to use what.2. There is no reason to why
@JsType doesn’t have any effect on the static methods. That is only because
of the original use cases that the design was tackling only cared about
well formed prototypal structures. Diving deeper into Elemental and
different javascript output styles, ability to define the full class
structure without exporting proves to be useful.3. @JsExport uses @JsType
to define the prototype structure. However this imposes unnecessary
restriction if/when there will be no javascript implementers of the @JsType
contract. @JsType that extends non-JsType is normally ok if it is not
implemented in js.4. You always need to fully qualify the name of the
export even if you just want to change the simple name.The New Annotation
SystemThere will be single annotation called @Js. Applying @Js to a member
is making that member available in javascript without any obfuscation.
However it is not safe from pruning if there are no references in java
code, so one needs to put enable exporting for the type if no pruning
wanted. Applying @Js at class level should considered as a shortcut to
apply @Js to all members. See following chart for the attributes and their
corresponding behavior:@JsType@Js(exports =
INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode =
LITERAL)@JsMethod@Js(name =
Re: GWT web content from a Java servlet
That works like a charm, but now I can't get GWT RPC to work with Super Dev Mode. I found a thread here https://groups.google.com/d/topic/google-web-toolkit/p9BGyLxiLkE/discussion, but that isn't for 2.7 and it doesn't provide a solution. When in Super Dev Mode, all of my GWT RPC calls go to code server URL/GWTRPC. Is there some trick to setting the correct URL for the RPC calls? They should be going to my J2EE app server, not the GWT code server. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT web content from a Java servlet
I was wrong in that last post. The GWT RPC request isn't going to the code server, it's going to the ... I guess it's a Jetty server that is launched by Eclipse when I run in debug mode? Is there a good tutorial on using Super Dev Mode with a J2EE app server? I've read that I should be able to do that without the Jetty server that is launched by Eclipse, but I can't find documentation about it. The site http://www.gwtproject.org/articles/superdevmode.html seems to be the official site, but I'm having trouble understanding it. I'm especially confused by the bit about running super dev mode without dev mode, but I have a sneaking suspicion that's what I want to do. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT web content from a Java servlet
Excellent suggestion. I like the path info thing. Thank you! On Saturday, April 18, 2015 at 8:07:55 AM UTC-5, Thomas Broyer wrote: On Friday, April 17, 2015 at 10:59:49 PM UTC+2, eho...@usdataworks.com wrote: I've tried looking for answers to this question, but the terms are so common that I can't find anything useful. Either that or I don't know the right term to include in my search. My goal is to provide GWT web content (an HTML page, the nocache.js and cache.js files, etc.) all from a Java servlet. My HTML file has a script tag that specifies the servlet (and some parameters) in its src attribute. That successfully loads the nocache.js file from my servlet. Inside the nocache.js file, though, there is a section of calls to unflattenKeylistIntoAnswers() that maps browser types to the generated names for the GWT javascript files. I need to prepend my servlet name (and some parameters) to those file names so they will also be loaded from my servlet. So instead of loading the cache.js files from www.myhost/foo/3D4F8081F105F3856719E7F2AEF0133D.cache.js the nocache.js file will load them from www.myhost/foo/myservlet?page=bar_3D4F8081F105F3856719E7F2AEF0133D.cache.js I'm looking for some way to modify the __moduleBase added to the filename in computeUrlForResource(), or some way to redefine the functions like installCode() to change the URL for the .js file. Any ideas? It would be easier to use the path-info rather than a query-string parameter: map your servlet to /myservlet/* and use HttpServletRequest#getPathInfo() http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getPathInfo() to get the rest of the path. If you really want to use a query-string parameter, then you'll have to customize the selection-script, as you already noticed. Fortunately, this is made relatively easy by the CrossSiteIframeLinker: create a subclass where you override getJsComputeUrlForResource http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/linker/CrossSiteIframeLinker.html#getJsComputeUrlForResource(com.google.gwt.core.ext.LinkerContext) and use that as your primary linker in place of xsiframe. cf. http://www.gwtproject.org/doc/latest/DevGuideLinkers.html -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
compilation-mappings.txt
Hi. In my project, GWT outputs a compilation-mappings.txt and modulename.devmode.js files. I think they shouldn't be needed in production, is there a way to configure (e.g. compiler flag) so that those files aren't generated? Thank you. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Catching Window.onUnload event
Hi Dimitri,
Did you find any solution in GWT for above mentioned problem that would
invoke an event when user navigates away from the screen without closing it
On Wednesday, 3 September 2008 05:13:01 UTC-4, buz...@gmail.com wrote:
Hello,
Is there a way in GWT to catch Window.onUnload event.
I need that to detect when user navigates away from the page, but does
not close the browser.
I have written a native implementation, but are there any plans to add
Window.addUnloadListener() functionality?
Or am I missing something?
My implementation looked like this () :
public abstract class MeasuringEntryPoint implements EntryPoint {
private static final List onunloadListneners = new ArrayList();
public MeasuringEntryPoint() {
attachOnUnloadListener();
addUnloadListener(new
MeasuringEntryPoint.WindowUnloadListener() {
public void onWindowUnloaded() {
detachOnUnloadListener();
Collection measurements =
MeasurementStorage.retrieveMeasurements();
MeasurementDeliveryGateway.deliver(measurements);
}
});
}
public static void addUnloadListener(WindowUnloadListener
listener) {
onunloadListneners.add(listener);
}
public static void onUnload() {
for (Iterator iterator = onunloadListneners.iterator();
iterator.hasNext();) {
WindowUnloadListener listener = (WindowUnloadListener)
iterator.next();
listener.onWindowUnloaded();
}
}
private native void attachOnUnloadListener() /*-{
$wnd.onunload = function() {
@com.mycoolapp.gwt.client.MeasuringEntryPoint::onUnload()
();
}
}-*/;
private native void detachOnUnloadListener() /*-{
$wnd.onunload = null
}-*/;
}
Thanks,
Dmitry
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
There is some upcoming changes to JsInteorp in preparation toward v1.0
release.
The most major change is to the annotations and their meanings. Here is the
doc explaining the changes and the reasoning. We are looking for your
feedback, especially on alternatives.
*Issues with existing design and annotations 1. @JsExport/@JsType slicing
is not intuitive for a lot of people esp. with gwt-exporter background.
People are confused about when to use what.2. There is no reason to why
@JsType doesn’t have any effect on the static methods. That is only because
of the original use cases that the design was tackling only cared about
well formed prototypal structures. Diving deeper into Elemental and
different javascript output styles, ability to define the full class
structure without exporting proves to be useful.3. @JsExport uses @JsType
to define the prototype structure. However this imposes unnecessary
restriction if/when there will be no javascript implementers of the @JsType
contract. @JsType that extends non-JsType is normally ok if it is not
implemented in js.4. You always need to fully qualify the name of the
export even if you just want to change the simple name.The New Annotation
SystemThere will be single annotation called @Js. Applying @Js to a member
is making that member available in javascript without any obfuscation.
However it is not safe from pruning if there are no references in java
code, so one needs to put enable exporting for the type if no pruning
wanted. Applying @Js at class level should considered as a shortcut to
apply @Js to all members. See following chart for the attributes and their
corresponding behavior:@JsType@Js(exports =
INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode =
LITERAL)@JsMethod@Js(name = myName)@JsProperty@Js(property =
true)@Js(name = myName, property = true)@JsNamespace@Js(namespace =
mynamespace)@JsExport@Js(exports = STATIC_MEMBERS)@Js(name = “A”, exports
= ALL)@Js(name = “A”, namespace=”a.b.c.”, exports = ALL)// When applied to
a member@Js(export = true)@Js(name = “myName”, export =
true)@JsNoExport@Js(ignore=true)@JsOpaque@Js(opaque=true)See Appendix below
for a complete comparison to existing annotations.Semantics /
Implementation in GWTImplementation: - Apply all Js names as bridge methods
(or the reverse if Js extends Java object case
https://groups.google.com/a/google.com/d/msg/gwt-users/i5KCHorBC6k/6wkPSuBBXBgJ
needs to be supported).- Optimize away everything with regular optimization
rules if the member is not exported.- Generate export statements for all
pinned methods/classes.Usage: - Hybrid / Inbox use case needs to use @Js
with exports. This will make the whole object exported and not pruned.-
Regular library importing should use @Js with interfaces (no exports), if
it is a callback the @Js interface should be marked as exported so the
methods are not pruned when the object is not pruned.- Elemental needs to
use not exported Js types with prototype set and native methods.Checks -
mode and exports is only used in types.- export and ignore is only used in
members.- property is only used in methods.- name is only used in members
and types.- namespace is only used in exported static members, types and
packages.- mode=FUNCTION cannot have any attribute set.Considered
AlternativesAlternative 1:We could follow the above design but keep using
old annotations for class level annotations: - @Js(mode=OBJECT) --
@JsType- @Js(mode=FUNCTION) -- @JsFunction- @Js(mode=LITERAL) --
@JsLiteral- @Js(namespace=”...”) -- @JsNamespace- @JsMember for the
rest.Pros: - Reads well . (e.g. @JsType interface Element instead of @Js
interface Element { .. } ).- These modes are substantially different so
different annotations makes that explicit and helps to document.- Need to
add additional checks as attributes are mostly disjoint. e.g exports
doesn't apply to members, name/namespace isn't applicable for
Js(mode=LITERAL) etc.Cons: - Multiple annotations to learn.- Using
JsType/JsFunction/JsLiteral in the same type is forbidden but having single
annotations automatically enforces that.Alternative 2:We can introduce two
different concepts JsImport and JsExport. Both annotation will imply old
JsType behavior if applied at class level. It can be applied at method
level to provide method level customizations.The main advantage is that the
name implies what the developer is trying to achieve. If importing a
library or generating Elemental, @JsImport is used. For exporting code
@JsExport is used.However, it actually make things more confusing when it
comes to callbacks. In that case, an imported callback is actually an
export so @JsExport should be applied instead.The main issue is, unlike the
above designs it doesn’t let you configure your JS output without
introducing exports.@JsType@JsImport@JsFunction@JsImport(mode = FUNCTION)//
Another gotcha, here we are actually logically not importing always. If it
is to call some javascript
GWT 2.7 Dev mode and JDK6 Error
I am getting the below error when run simple GWT demo app in Dev mode using JDK6, but dev mode works fine with JDK7. I am using Chromium + GWT plugin. Is 2.7 GWT Dev mode supported only on JDK7+?. Eventually, I will switch to Super dev mode. [ERROR] [gwt27demo] - Unable to load module entry point class com.google.gwt.user.client.DocumentModeAsserter (see associated exception for details) [ERROR] [gwt27demo] - Failed to load module 'gwt27demo' from user agent 'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2192.0 Safari/537.36' at 127.0.0.1:49436 12:06:38.522 [ERROR] [gwt27demo] Unable to load module entry point class com.google.gwt.user.client.DocumentModeAsserter (see associated exception for details) java.lang.RuntimeException: Deferred binding failed for 'com.google.gwt.user.client.DocumentModeAsserter$DocumentModeProperty' (did you forget to inherit a required module?) at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:53) at com.google.gwt.core.shared.GWT.createImpl(GWT.java:83) at com.google.gwt.core.client.GWT.create(GWT.java:86) at com.google.gwt.user.client.DocumentModeAsserter.onModuleLoad(DocumentModeAsserter.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:423) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:530) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:368) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.UnsupportedClassVersionError: com/google/gwt/user/client/DocumentModeAsserter_DocumentModeProperty : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1142) at com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1215) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:683) at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:486) at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:49) at com.google.gwt.core.shared.GWT.createImpl(GWT.java:83) at com.google.gwt.core.client.GWT.create(GWT.java:86) at com.google.gwt.user.client.DocumentModeAsserter.onModuleLoad(DocumentModeAsserter.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:423) at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200) at com.google.gwt.dev.shell.BrowserChannelServer.processConnectio at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChann -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT RichTextArea target='_blank' for links
Is there a way to customize the GWT RichTextArea to open a new link in new tab? e.g. produce something like this? a href=http://www.w3schools.com; target=_blankVisit W3Schools/a Or do you know a better Widget? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: gwt-site(https://github.com/gwtproject/gwt-site ) compiled and run successfully but a lot of stuff missing
1. GWT is not a Google product anymore. The website has been mainly built by Arcbees, a Canadian company member of the GWT steering committee. Google is just offering to host freely the website on its infrastructure. 2. AppEngine is used to store the pages on the database so that we can change the content of the pages without redeploying the application. It's not so complex and gives us a lot of flexibility. We use GWT and not jQuery (though we use gwtQuery) because we are GWT developpers and it makes sense to use GWT for the GWT website (we use GWT to enhance the html like we would have done if we had used jQuery...). So it's not a problem of using GWT instead of jQuery. In our case, I think the main issue that make the site available offline is that CSS hide the main content until the GWT code (or javascript code if you prefer) is loaded. That why you cannot simply crawl the website from the file system. There are still a lot of work to do on the website (like updating the content for example) but don't expect Google engineers to do that. It's the role of the community to do it. So if you want to contribute in order to make the website more user friendly for non-connected users, fell free to contribute or wait that another people on the community has the same problem and decide to fix it. Julien On Tuesday, April 21, 2015 at 3:47:03 AM UTC+2, Alex Luya wrote: Sorry, But I think this isn't about time but how gwt guys think about problem,I just hope gwt guys can think from user's perspective: 1,not from google perspective.google just hope everything be online,then it can track every clicking and push ads to you,so it rarely provides downloadabe docs(in the opposite,apache and many other tech providers do it very well:provide good downloadable doc).Google just has too strong desire of controlling. 2,GwtProject site primarily contains static pages,not so much interactions can be performed.Why does it use so heavy and fancy tech like GWT+App engine?Html and jquery can handle it very well.New tech should simplify complicated things,not 'complicatify' simple things. On 04/20/2015 09:12 PM, Julien Dramaix wrote: The old site was downloadable and you was able to crawl it locally. It's something we broke with the new site and that has to be fixed. When ? When somene would have time to work on a patch for that :-) On Monday, April 20, 2015 at 1:55:19 AM UTC+2, Alex Luya wrote: Thanks, I tried it,but it depends on google app engine.I just wonder:since GWT has kinds of out of google,why does it still inherit google's bad tradition:not provide downloadable doc package?After all,it is faster,bandwith saving and still avaialbe when network is down or in google blocked place. On 04/18/2015 07:34 PM, Thomas Broyer wrote: gwt-site contains the doc's content only. If you want the full website, then you need https://gwt.googlesource.com/gwt-site-webapp/ in addition. On Saturday, April 18, 2015 at 7:10:49 AM UTC+2, Alex Luya wrote: https://lh3.googleusercontent.com/-ES3ZneCVP3c/VSN0VQNZmHI/AM0/wIrBOtLKuNs/s1600/Workspace%2B1_048.png Hello, I have asked a question here: https://groups.google.com/forum/#!topic/google-web-toolkit/x-OoMQv_RHo.Briefly speaking,due to all google related stuff is blocked in China,so I want to set up gwt-site in my local machine,followed the instructions in gwt-site page,I got compilation and run successfully,but there are many stuffs missing including:gwtproject.nocache.js(please check blow image),why? (screenshot with firebug of gwt-site) -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IjUJ2wDZgCM/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-we...@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups Google Web Toolkit group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/IjUJ2wDZgCM/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. To post to this group, send email to google-we...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: GSS migration: mixin definition for a transition with multiple transition-property
You can open a issue to track this problem but it has to be fixed in
closure stylesheet directly.
On Monday, April 20, 2015 at 4:18:16 PM UTC+2, Benjamin V. wrote:
Yes, that works. But it is a bit unintuitive as I have multiple different
transitions properties in one stylesheet. So I have to define multiple
similiar property variables which are all only used once.
Am Montag, 20. April 2015 15:55:22 UTC+2 schrieb Jens:
Does it work if you create a constant for the properties? E.g.:
@def MY_TRANSITION_PROPERTIES opacity .5s linear 0s, visibility 0s linear
.5s;
.class {
@mixin transitions(MY_TRANSITION_PROPERTIES);
}
-- J.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Re: Help Posting form with file input using elemental
Jens approach should work.
Another approach, for example if you are missing some functions like the
append(String
name, Blob file, String filename) on elementals interfaces, is this:
public static class ExtJsFormData extends JsFormData {
protected ExtJsFormData() {
}
public final native static ExtJsFormData newExtJsForm() /*-{
return new $wnd.FormData();
}-*/;
public final native void append(String name, Blob file, String
filename) /*-{
this.append(name, file, filename);
}-*/;
}
On Tuesday, April 21, 2015 at 1:44:47 AM UTC+2, Wayne Rasmuss wrote:
I've been working on file uploading to AppEngine using the blob store. I
would like to do so in the background using elemental (no suggestions for
3rd party libraries please.) I think I have it mostly figured out but I
can't figure out the code to get the form data from the form element.
The java script should look like this:
var formElement =
document.getElementById(formElementID);
var request = new XMLHttpRequest();
request.open(POST, urltopostto);
request.send(new FormData(formElement));
Here's my java code with elemental. The last line has the part I can't
figure out.
FormElement formElement = (FormElement)
Browser.getDocument().getElementById(uploadForm);
XMLHttpRequest request =
Browser.getWindow().newXMLHttpRequest();
request.open(POST, uploadUrl);
request.send(!!!NEED FORM DATA FROM MY FORM
ELEMENT HERE);
General guidance on how to map JS to Elemental code would be great.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Re: GWT 2.7.0 is here
Hi Daniel how to i convert my application which is in 2.3 version to 2.7 ? plz provide me some steps to convert the version to 2.7. On Thursday, 20 November 2014 16:29:06 UTC+5:30, Daniel Kurka wrote: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
Damn it, Safari crashed. So now a shorter version of my answer: First I agree that the current design has become quite confusing. Personally I really dislike the single @Js annotation approach because: - can be applied everywhere so you throw away some compile time checks provided by Java's @Target annotation - exports vs. export is a bit misleading. One must be used with interfaces/classes the other with methods. That issue only exists because @Js alone has no real meaning. - You have to type more because it is always annotation name + property + value if you can't stick with the default @Js. - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export a class I want to export its public API. Personally what describes JsInterop best is the alternative using the import/export concepts. So I would stick with: Import/Export types: @JsImport: can only be applied on interfaces. @JsExport: always exports all public API in a given scope (package, class, method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore can be used to opt-out selectively. Configure import/export: @JsNamespace: import/export from/to namespace @JsName: workaround reserved keywords @JsProperty: mark method as JS property @JsIgnore: opt-out of export. Might even be useful for import, e.g. do not generate trampoline for annotated default method. Special constructs: @JsLiteral @JsFunction (currently it seems not to be a real function which breaks interop https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ ) I guess that is the cleanest you can get. Not sure what @JsOpaque is good for?! -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
Goktug, I though we were keeping @JsType and others as syntactic sugar? On Tue, Apr 21, 2015 at 5:40 PM, Jens jens.nehlme...@gmail.com wrote: Damn it, Safari crashed. So now a shorter version of my answer: First I agree that the current design has become quite confusing. Personally I really dislike the single @Js annotation approach because: - can be applied everywhere so you throw away some compile time checks provided by Java's @Target annotation - exports vs. export is a bit misleading. One must be used with interfaces/classes the other with methods. That issue only exists because @Js alone has no real meaning. - You have to type more because it is always annotation name + property + value if you can't stick with the default @Js. - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export a class I want to export its public API. Personally what describes JsInterop best is the alternative using the import/export concepts. So I would stick with: Import/Export types: @JsImport: can only be applied on interfaces. @JsExport: always exports all public API in a given scope (package, class, method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore can be used to opt-out selectively. Configure import/export: @JsNamespace: import/export from/to namespace @JsName: workaround reserved keywords @JsProperty: mark method as JS property @JsIgnore: opt-out of export. Might even be useful for import, e.g. do not generate trampoline for annotated default method. Special constructs: @JsLiteral @JsFunction (currently it seems not to be a real function which breaks interop https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ ) I guess that is the cleanest you can get. Not sure what @JsOpaque is good for?! -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
Yes and no depending what you mean. Before answering that I think there might have been some confusion the way I listed the options in the doc so let me try to summarize it again. There are 3 options. Option 1 uses @Js annotation everywhere. There is no other annotation. The @Js annotation can be applied to a class and in general it will behave similar to applying the annotation to all public members (if that is what you meant as syntactic sugar). This is the one that is described first in the doc and it is the direction we are heading right now. Option 2 uses @JsType/@JsFunction/@JsLiteral for types and @JsMember for members. @JsExport, @JsProperty, @JsMethod etc. are still gone (if that's what you meant with syntactic sugar). @JsNamespace is still used for setting namespaces where needed. So this is more or less the same design as Option 1 but separates the annotation used at class level from the one used at members. This is listed as Alternative 1 in the doc. Originally this was the direction we were heading and it was described at the beginning while Option 1 was listed as Alternative 1. I changed the order because John and Roberto both argued having single annotation (i.e. @Js) is simpler. Option 3 uses @JsImport/JsExport and it is completely separate design from the first two options. This is listed as Alternative 2. Personally I am more towards Option 2 (see the pros and cons for the Option 2 in the doc) but I am getting mixed signals from outside so I need more feedback from developers. On Tue, Apr 21, 2015 at 6:21 PM, 'Ray Cromwell' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: Goktug, I though we were keeping @JsType and others as syntactic sugar? On Tue, Apr 21, 2015 at 5:40 PM, Jens jens.nehlme...@gmail.com wrote: Damn it, Safari crashed. So now a shorter version of my answer: First I agree that the current design has become quite confusing. Personally I really dislike the single @Js annotation approach because: - can be applied everywhere so you throw away some compile time checks provided by Java's @Target annotation - exports vs. export is a bit misleading. One must be used with interfaces/classes the other with methods. That issue only exists because @Js alone has no real meaning. - You have to type more because it is always annotation name + property + value if you can't stick with the default @Js. - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export a class I want to export its public API. Personally what describes JsInterop best is the alternative using the import/export concepts. So I would stick with: Import/Export types: @JsImport: can only be applied on interfaces. @JsExport: always exports all public API in a given scope (package, class, method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore can be used to opt-out selectively. Configure import/export: @JsNamespace: import/export from/to namespace @JsName: workaround reserved keywords @JsProperty: mark method as JS property @JsIgnore: opt-out of export. Might even be useful for import, e.g. do not generate trampoline for annotated default method. Special constructs: @JsLiteral @JsFunction (currently it seems not to be a real function which breaks interop https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ ) I guess that is the cleanest you can get. Not sure what @JsOpaque is good for?! -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving
Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
On Tue, Apr 21, 2015 at 5:40 PM, Jens jens.nehlme...@gmail.com wrote: Damn it, Safari crashed. So now a shorter version of my answer: First I agree that the current design has become quite confusing. Personally I really dislike the single @Js annotation approach because: - can be applied everywhere so you throw away some compile time checks provided by Java's @Target annotation Agreed. - exports vs. export is a bit misleading. One must be used with interfaces/classes the other with methods. That issue only exists because @Js alone has no real meaning. Mostly agreed though @Js alone has meaning. As there are no exports, the methods can be pruned. This difference will be more significant when we change the output style to be more idiomatic javascript and have a closer integration with Closure compiler in the future. - You have to type more because it is always annotation name + property + value if you can't stick with the default @Js. I'm assuming you are comparing Option 1 and Option 2 (see my recent email). Based on that I'm not sure which part you are referring. Can you give an example? - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export a class I want to export its public API. Yes, that was my assumption as well and that's how I started. But looking at real life code inside Google, especially in places where the code is shared by different platforms, I see people choosing to only export instance members or static members. I will need to re-evaluate this after we migrate all Google code to new annotations. Personally what describes JsInterop best is the alternative using the import/export concepts. So I would stick with: Import/Export types: @JsImport: can only be applied on interfaces. @JsExport: always exports all public API in a given scope (package, class, method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore can be used to opt-out selectively. Configure import/export: @JsNamespace: import/export from/to namespace @JsName: workaround reserved keywords @JsProperty: mark method as JS property @JsIgnore: opt-out of export. Might even be useful for import, e.g. do not generate trampoline for annotated default method. Special constructs: @JsLiteral @JsFunction (currently it seems not to be a real function which breaks interop https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ ) This is the one I listed as Alternative 2 in the doc (Option 3 as I re-listed in the recent email). It doesn't hold water well; works well for simple but gets confusing quickly as there are many gotchas. I guess that is the cleanest you can get. Not sure what @JsOpaque is good for?! It is not committed: https://gwt-review.googlesource.com/#/c/12210/ The description in the patch needs an update but in most simple terms, it is used to mark parameters that are only intended to be used as opaque object in javascript side. This will prevent accidental passing of types that are not usable in javascript while it will give us more room in changing the behavior for non-jstype parameters in the future. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3tJODfbstJC%3DnUxd0-q_t%3DS0SuK4V%3DYgn-yRKdAH9T4w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: GWT web content from a Java servlet
Never mind. I think I have figured it out. I have to run the com.google.gwt.dev.codeserver.CodeServer class in the gwt-codeserver.jar. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
