Re: GWT 2.7.0 is here
Great!!! Excited to get to try JSInterop , albeit experimential Am Donnerstag, 20. November 2014 11:59:06 UTC+1 schrieb Daniel Kurka: 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.
Re: [POLL RESULTS] Maven project layout, what to standardize?
Am Freitag, 16. November 2012 21:08:16 UTC+1 schrieb Thomas Broyer: Le 16 nov. 2012 17:59, Daniel Kurka kurka@gmail.com javascript: a écrit : Hi Thomas, I have been out on devoxx and haven`t had time to cast a vote yet. I think its a good idea to go with a separate package like src/main/super for super sourcing. Why are we thinking of moving resources out of src/main/java, Depends where you come from ;-) Maven users where (almost) ALL complaining when GPE didn't see their files in src/main/resources. If you think of src/main/java as the set of files processed by javac, then gwt.xml, ui.xml and the like should obviously go to resources (or some other, GWT specific, folder). what is the main advantage here? Separation of concerns (even though java sources will end up processed the same as gwt.xml, they're also processed by javac, and generally not filtered), filtering, freedom (e.g. one might want to put the gwt.xml at the root of resources and define targetPath to relocate them in the appropriate package in the generated JAR, it'd make navigation easier in Eclipse – IntelliJ has a package presentation which makes this pointless –; I could see me doing that for super-sources in case I have a single module in my lib) Honestly, it's mostly a matter of taste, and both would work and in 99% of the cases, but src/main/resources feels more mavenish (note: I was a proponent of src/main/java some time ago, I now believe it was mostly due to tooling). I went the other way... having used maven before and being new to gwt i had the *.gwt.xml intially in src/*/resources ... after a while i moved them to the src/*/java mostly because i felt they had much to do with the java code and package structure... -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/1OY6W4ygXMoJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [POLL] Maven project layout, what to standardize?
I am not quite sure why super-sources should / must be treated differently? Back i am probably lacking experience and knowledge here I like the notion the *gwt.xml files are actuallly part of the sources and not resources for gwt libraries. So that would be Option 1, without understanding the motivation for super sources into src/main/resources also why not if necessary src/main/super? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/QQ2nrNMXYPwJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Mapping EntityProxies to Domain Interfaces
Works perfectly. Thank you very much. ufff i'm glad: less code for us! Am Dienstag, 9. Oktober 2012 19:42:06 UTC+2 schrieb Manuel Carrasco: On Tue, Oct 9, 2012 at 4:38 PM, Christoph Henrici chhe...@gmail.comjavascript: wrote: Great! Sorry i don't know that much about patches which one should i download ... and can i run them against jars? i have'nt the source code dist of gwt, i working with eclipse. If it's not to much work, you could give me a couple instructions and i ll test ? ;-)) - Download the original ReflectiveServiceLayer.java [1] from the gwt repository - Save it in your project in the folder: [your_src_folder]/com/google/web/bindery/requestfactory/server/ - Download the patch I sent for this file [2] from the review site - patch your file, if you are running unix $ cd [your_src_folder] $ patch -p2 [path_to_the_downloaded_diff_file] - if you don't have the patch command, you can use eclipse or make the modifications in [3] by hand - compile and run your project, it should use the patched class (because it is firt in your classpath) instead of the original one [1] http://google-web-toolkit.googlecode.com/svn/trunk/user/src/com/google/web/bindery/requestfactory/server/ReflectiveServiceLayer.java [2] http://gwt-code-reviews.appspot.com/download/issue1764804_15003_7004.diff [3] http://gwt-code-reviews.appspot.com/1764804/diff2/9009:15003/user/src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/3K-VwifKpiUJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Mapping EntityProxies to Domain Interfaces
Forgot to ask: the patch will be in a upcoming version? Am Mittwoch, 10. Oktober 2012 09:26:51 UTC+2 schrieb Christoph Henrici: Works perfectly. Thank you very much. ufff i'm glad: less code for us! Am Dienstag, 9. Oktober 2012 19:42:06 UTC+2 schrieb Manuel Carrasco: On Tue, Oct 9, 2012 at 4:38 PM, Christoph Henrici chhe...@gmail.comwrote: Great! Sorry i don't know that much about patches which one should i download ... and can i run them against jars? i have'nt the source code dist of gwt, i working with eclipse. If it's not to much work, you could give me a couple instructions and i ll test ? ;-)) - Download the original ReflectiveServiceLayer.java [1] from the gwt repository - Save it in your project in the folder: [your_src_folder]/com/google/web/bindery/requestfactory/server/ - Download the patch I sent for this file [2] from the review site - patch your file, if you are running unix $ cd [your_src_folder] $ patch -p2 [path_to_the_downloaded_diff_file] - if you don't have the patch command, you can use eclipse or make the modifications in [3] by hand - compile and run your project, it should use the patched class (because it is firt in your classpath) instead of the original one [1] http://google-web-toolkit.googlecode.com/svn/trunk/user/src/com/google/web/bindery/requestfactory/server/ReflectiveServiceLayer.java [2] http://gwt-code-reviews.appspot.com/download/issue1764804_15003_7004.diff [3] http://gwt-code-reviews.appspot.com/1764804/diff2/9009:15003/user/src/com/google/web/bindery/requestfactory/server/ResolverServiceLayer.java -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/80Rj3g7RfwkJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Mapping EntityProxies to Domain Interfaces
Appreciate you guys great work! Thanx! Am Mittwoch, 10. Oktober 2012 09:59:55 UTC+2 schrieb Thomas Broyer: On Wednesday, October 10, 2012 9:27:24 AM UTC+2, Christoph Henrici wrote: Forgot to ask: the patch will be in a upcoming version? Maybe 2.6, or 2.5.1 (if there's one). No ETA yet. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/cuam90fcSSkJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory in a offline Szenario?
Best thanx. Szenario 1, would mean that you have to deal with two
different sets of data structures online = entityproxies and offline
something else. or you have to develop your own layer above request
factory which to avoid was the rational behind using requestfactory.
Szenario 2 seems like a interesting approach, but i must confess i not
knowlegable enough of the internals of Requestfactory to really be able to
see what that means. Also for adressing the issue with the potential
confict resolution this is probably not the right layer
So probably you need something above RequestfFactory, which deals with a
higher level batching and offline / online awareness etc...
Am Montag, 8. Oktober 2012 19:04:10 UTC+2 schrieb Jens:
I think I would store data changes locally and when the device is back
online I would send everything to the server and let the server synchronize
it with its server database. The server can send conflicts back to the
client and then let the user choose which version of the conflicted data
should be used. So I would not store the specific requests, but only the
data (along with some meta data like timestamp, isDeleted, etc.).
So its pretty much:
if(online) {
// requestfactory
} else {
// use local data cache
}
I am not sure if its possible to implement a custom RequestTransport for
RequestFactory, e.g. OfflineRequestTransport, that parses the RF payload
and executes/applies all the invocations/operations locally using a local
data cache. If it would be possible you could switch to an
OfflineRequestTransport as soon as you are offline and you dont need that
if(online) block everywhere in your code.
-- J.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/HhBDMGHWLNgJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Mapping EntityProxies to Domain Interfaces
I solved this with a InterfaceResolvingServiceLayerDecorator basically a copy of the ResloverServiceLayer with one line different: In the method resloveClientType the line: Class? toSearch = domainClass; ist substituted with: Class? toSearch = InterfaceUtils.getEntityInterfaceIfExits(domainClass); where InterfaceUtils is application specific. Not quite sure of the approach seems lots of code copied for one little change ... ;-/ ? Am Freitag, 5. Oktober 2012 11:22:34 UTC+2 schrieb Christoph Henrici: By default it seems to me that EntityProxies can't be mapped with @ProxyFor to Domain Interfaces, since the Deobfuscator.getClientProxies via ResolverServiceLayer by the Implementing Class name.. ResolverServiceLayer dies with The domain type %s cannot be sent to the client. Generally i think it would be a good idea to be able to map Proxies to Domain Interfaces, or am i missing something? Is there a way of achieving this? Christoph -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/nSM4ikzr5EIJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Mapping EntityProxies to Domain Interfaces
Great! Sorry i don't know that much about patches which one should i download ... and can i run them against jars? i have'nt the source code dist of gwt, i working with eclipse. If it's not to much work, you could give me a couple instructions and i ll test ? ;-)) Am Dienstag, 9. Oktober 2012 09:55:52 UTC+2 schrieb Manuel Carrasco: There are two issues in gwt, related with this http://code.google.com/p/google-web-toolkit/issues/detail?id=5762 http://code.google.com/p/google-web-toolkit/issues/detail?id=7509 I submitted a patch a couple of months ago which should fix your issue http://gwt-code-reviews.appspot.com/1764804/ It should be nice if you could test the fix with your projects and give feedback. - Manolo On Tue, Oct 9, 2012 at 9:09 AM, Christoph Henrici chhe...@gmail.comjavascript: wrote: I solved this with a InterfaceResolvingServiceLayerDecorator basically a copy of the ResloverServiceLayer with one line different: In the method resloveClientType the line: Class? toSearch = domainClass; ist substituted with: Class? toSearch = InterfaceUtils.getEntityInterfaceIfExits(domainClass); where InterfaceUtils is application specific. Not quite sure of the approach seems lots of code copied for one little change ... ;-/ ? Am Freitag, 5. Oktober 2012 11:22:34 UTC+2 schrieb Christoph Henrici: By default it seems to me that EntityProxies can't be mapped with @ProxyFor to Domain Interfaces, since the Deobfuscator.getClientProxies via ResolverServiceLayer by the Implementing Class name.. ResolverServiceLayer dies with The domain type %s cannot be sent to the client. Generally i think it would be a good idea to be able to map Proxies to Domain Interfaces, or am i missing something? Is there a way of achieving this? Christoph -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/nSM4ikzr5EIJ. To post to this group, send email to google-we...@googlegroups.comjavascript: . To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/tmtPzP2N9W8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: RequestFactory in a offline Szenario?
Am Dienstag, 9. Oktober 2012 12:59:19 UTC+2 schrieb Thomas Broyer: On Tuesday, October 9, 2012 9:03:35 AM UTC+2, Christoph Henrici wrote: Best thanx. Szenario 1, would mean that you have to deal with two different sets of data structures online = entityproxies and offline something else. or you have to develop your own layer above request factory which to avoid was the rational behind using requestfactory. Szenario 2 seems like a interesting approach, but i must confess i not knowlegable enough of the internals of Requestfactory to really be able to see what that means. Have a look at http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/web/bindery/requestfactory/shared/ProxySerializer.htmlbut beware that there are issues with it (known and probably unknown too). Great pointer, thanx! Also for adressing the issue with the potential confict resolution this is probably not the right layer So probably you need something above RequestfFactory, which deals with a higher level batching and offline / online awareness etc... Synchronization (and conflict resolution) is hard. In the end, it's probably easier to either use the last write wins (possibly at the property level rather than object level; that would make it more of less equivalent to OT) or to simply store duplicates and then provide a mean to reconcile/merge data. It seems to be more or less what Google does for the contacts for instance. Very true the approach with secondary unconsolidated data structures, which are consolidate in a second step might a sound approach -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/pAFI2YlLHMgJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Request Factory Server Generated Entity Attribut Values
Best thanx. So it's basically i can - if i understand correctly - return the changed Attributes in for example a ValueProxy with a Reciever.onSuccesd Paramrter or usethe PropertyChangeEvent mechansim... where one would requery the Entity from the server, since the PropertyChangeEvent itself does'nt carried the changes? Am Montag, 8. Oktober 2012 16:38:11 UTC+2 schrieb Thomas Broyer: On Monday, October 8, 2012 4:20:46 PM UTC+2, Christoph Henrici wrote: Probably very trivial, but i have searched the Group and havn't found anything. How are Server generated Values propagated back to the EntityProxies, specially also the Id values of newly created and inserted Objects. Can anybody help? Have a look at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts Also, the domain object is stored as a tag on the proxy AutoBean, and there's a map of domain objects to proxies for the reverse mapping. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/A6l8kOveOIQJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Request Factory Server Generated Entity Attribut Values
Probably very trivial, but i have searched the Group and havn't found anything. How are Server generated Values propagated back to the EntityProxies, specially also the Id values of newly created and inserted Objects. Can anybody help? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/7owI9MgQ_e0J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
RequestFactory in a offline Szenario?
What be the best approach to develop a offline capable Application using ReqeustFactory? By Storing Request on locally on the Device and firing later when online? Or is RequestFactory not recommendable to use, if offline capability is a requirement? Best Thanx for any advice. Christoph -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/AtvLnOlY_eMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Mapping EntityProxies to Domain Interfaces
By default it seems to me that EntityProxies can't be mapped with @ProxyFor to Domain Interfaces, since the Deobfuscator.getClientProxies via ResolverServiceLayer by the Implementing Class name.. ResolverServiceLayer dies with The domain type %s cannot be sent to the client. Generally i think it would be a good idea to be able to map Proxies to Domain Interfaces, or am i missing something? Is there a way of achieving this? Christoph -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/eqDS8SShNJoJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Generic Method Support of RequestContext Specializations
Do specializations of the RequestContext interface support generic methods in the following form: public T extends EntityProxy RequestListT query(String typeUniqueId); with a Server Interface like: public T ListT query(String typeUniqueId); It doesn't look like since our testcase throws an exception of the following form: [ERROR] Line 46: T.com cannot be resolved to a type [ERROR] Line 46: Syntax error on token extends, . expected [ERROR] Line 58: T.com cannot be resolved to a type [ERROR] Line 58: Syntax error on token extends, . expected Interestingly enough the Validator used by Eclipse doesn't mind.. Is there any way to support method level generics in a RequestContext Interface? Any feedback, remarks... greatly appreciated Chris -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/9nApP2k6_LAJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
