[gwt-contrib] Re: Issue with development mode plugin and Custom selection script / hosted.html that allows separate debugging of multiple GWT applications on a single page
Hi Jamie,
I had the same problem. I implemented a very similar approach described by
you.
I introduced in a top level gwt.xml a property to enable the debuging which
will be inherit by all my application.
define-property name=debugPlugin values=false/
extend-property name=debugPlugin values=true /
set-property name=debugPlugin value=false/
In your custom Linker you can access this property:
for (SelectionProperty property : context.getProperties()) {
if (debugPlugin.equals(property.getName())) {
if (Boolean.valueOf(property.tryGetValue())) {
replaceAll(stringBuffer, __DEBUG_PLUGINS__,
context.getModuleName());
}
}
}
The isHostedMode() method looks now so:
function isHostedMode() {
var result = false;
try {
var query = $wnd.location.search;
var devPlugins = '__DEBUG_PLUGINS__';
if ($wnd.debugPlugin) {
$wnd.debugPlugins += devPlugins+;;
} else {
$wnd.debugPlugins = devPlugins;
}
var debugFlag = ($wnd.debugPlugins==null ? false :
$wnd.debugPlugins.indexOf('__MODULE_NAME__')!=-1);
return ((query.indexOf('gwt.codesvr=') != -1
|| query.indexOf('gwt.hosted=') != -1
|| ($wnd.external $wnd.external.gwtOnLoad))
(query.indexOf('gwt.hybrid') == -1) debugFlag);
} catch (e) {
// Defensive: some versions of IE7 reportedly can throw an
exception
// evaluating external.gwtOnLoad.
}
isHostedMode = function() { return result; };
return result;
}
In our production build the debugPlugin is false for all application.
During the development you can enable the debuging for the
modules/application you desire:
set-property name=debugPlugin value=true/
I hope this would you are looking for?
BR
Rocco
Am Donnerstag, 17. Oktober 2013 12:20:26 UTC+2 schrieb Jamie Cramb:
Hi Thomas,
Thanks for the reply and apologies for the delay, I must have missed the
email notification re: your reply.
Well its great to hear that it is already solved via the xsiframe linker,
but not a total loss, I learned a good deal about how the IFrame linker
currently works ;)
I gave the xsiframe linker a try with the following results:
- I had to deal with the xsiframe linker not supporting script /
tags (the Piriti library I use for JSON serialization has a script tag in
its *.gwt.xml module files); the workaround for this is well documented
but
something to consider when rolling this linker out as the default
(potentially a breaking change).
- I was unable to get this working in Firefox v24 on Win7 64bit but
was unable to get it working in Google Chrome v30.0.1599.101 m... *have
you tried this on Chrome recently*? I actually saw a similar behavior
to what I reported with my own solution (once, i was not able to
re-create)
which was that it would fail unless the gwt.codesvr without the module
name
was also in the URL.
The reason I'm working on this is primarily for Portal type
functionality; is there any work on the roadmap related to getting GWT to
play nicely inside a portal-type environment where:
1. Multiple GWT applications can be rendered on a single page and
debugged individually (looks like xsiframe linker is getting us there).
2. Multiple instances of the same GWT application can be rendered on
the same page but with different bootstrap params; e.g. being able to
pass in:
- Preferences to tell instance X of the widget to display a graph
over 12 months and instance y to display a graph over 3 months
- The div that the GWT application should attach itself to.
Thanks in advance.
Cheers,
Jamie
On Wednesday, October 9, 2013 8:50:45 AM UTC+1, Thomas Broyer wrote:
Too bad you started investing time in a solution to a problem that's
already solved!
You first have to use the xsiframe linker (which BTW is not a bad idea; I
think we should make it the default linker in some future release), then
just use gwt.codesvr.myModule instead of gwt.codesvr, where myModule is the
name of your module (same name as the folder and nocache.js)
See
https://code.google.com/p/google-web-toolkit/issues/detail?id=2079#c21
On Tuesday, October 8, 2013 7:07:40 PM UTC+2, Jamie Cramb wrote:
Hi all,
I have a page which has multiple GWT applications running on it. When
it comes to development mode / debugging from eclipse (using the dev mode
plugin in chrome) we start to hit issues because if we put the
gwt.codesvr param in the URL then all of the GWT applications on the page
will try to debug and will fail (because the debugger we have running only
has the source code for one of the applications in its classpath).
My goal is to update the implementation of the
[gwt-contrib] Re: Non-client apis and breaking changes
On Friday, October 18, 2013 7:21:48 AM UTC+2, Colin Alworth wrote: Just wandered by https://gwt-review.googlesource.com/#/c/1040/ and noticed that with this change, any downstream generator/linker using the static helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the other discussions going on about JRE and browser support, perhaps we could discuss something policy-like around 'internal' code like this? If the policy that internal public methods are not actually for public consumption, or subject to breakage across minor releases, we should note that somewhere to keep people away. My inclination is that we want to encourage downstream code to use utility methods like this rather than copying them into their own projects. This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. AFAICT, the rule has always been to first make those utilities private as incubators and then move them to a public place when they're ready for prime-time. Re. this specific change, we could do the move in 2 steps though: make the c.g.g.dev.util classes simply call to the new c.g.g.tools.util.shared ones, and deprecate them; and remove them in a later release. And again on the side of discouraging use of code like this, how far and wide can public code be expected to be 'usable by downstream'? The com.google.gwt.editor.rebind.model.ModelUtils class is very handy for getting specifics about generic types, but from its package it is clearly part of editor so could change with modifications to that framework, whereas Name and StringKey seem to be in the relatively 'safe' package of com.google.gwt.dev.util with other benign classes like Util. Thoughts? ModelUtils should clearly be moved to a util package and made public (possibly with some cleanup). It's used by AutoBeans and RequestFactory too. In the mean time, you should cherry-pick those classes into your own source tree. That's the current unwritten policy as I understand it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: IE10 and historic dates
I think one should use a DateTimeFormat, and we should leave Date.parse() as a thin wrapper around the JS equivalent. We might have an opportunity to make things different when we'll emulate JSR 310 (from Java 8) On Thursday, October 17, 2013 7:34:22 PM UTC+2, Daniel Kurka wrote: Hi all, IE10 does not handle dates the same way other browser do anymore. This breaks a test in the EmulSuite. // IE10 (Standards mode) new Date(Date.parse(3/31/2000)).toUTCString() Fri, 31 Mar 2000 07:00:00 UTC // IE9 (Standards mode) and previous versions of IE new Date(Date.parse(3/31/2000)).toUTCString() Fri, 31 Mar 2000 08:00:00 UTC MS now uses windows time zones to calculate historic dates, see: http://blogs.msdn.com/b/ie/archive/2013/03/25/spring-forward-advancing-historical-date-and-time-calculations-on-the-web.aspx On the Java side: http://docs.oracle.com/javase/7/docs/api/java/util/Date.html#parse(java.lang.String) Once the entire string s has been scanned, it is converted to a time result in one of two ways. If a time zone or time-zone offset has been recognized, then the year, month, day of month, hour, minute, and second are interpreted in UTC and then the time-zone offset is applied. Otherwise, the year, month, day of month, hour, minute, and second are interpreted in the local time zone. I appreciate input on this! -Daniel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] IE10 and historic dates
On Thu, Oct 17, 2013 at 8:34 PM, Daniel Kurka danku...@google.com wrote: Hi all, IE10 does not handle dates the same way other browser do anymore. This breaks a test in the EmulSuite. // IE10 (Standards mode) new Date(Date.parse(3/31/2000)).toUTCString() Fri, 31 Mar 2000 07:00:00 UTC // IE9 (Standards mode) and previous versions of IE new Date(Date.parse(3/31/2000)).toUTCString() Fri, 31 Mar 2000 08:00:00 UTC MS now uses windows time zones to calculate historic dates, see: http://blogs.msdn.com/b/ie/archive/2013/03/25/spring-forward-advancing-historical-date-and-time-calculations-on-the-web.aspx On the Java side: http://docs.oracle.com/javase/7/docs/api/java/util/Date.html#parse(java.lang.String) Once the entire string s has been scanned, it is converted to a time result in one of two ways. If a time zone or time-zone offset has been recognized, then the year, month, day of month, hour, minute, and second are interpreted in UTC and then the time-zone offset is applied. Otherwise, the year, month, day of month, hour, minute, and second are interpreted in the local time zone. GWT's emulation of java.util.Date already doesn't interpret time-zone or time-zone offsets during parsing, right? The only thing, the emul java.util.Date does is fixing DST if non-String constructors are used. On the other hand, we do our own parsing in DateTimeFormat. So we haven't been really fixing browser differences in Date.parse. On the other hand, if there is a behavior difference for DateTimeFormat in different browsers, that is a different story, and we should probably fix that. I appreciate input on this! -Daniel -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Non-client apis and breaking changes
On Fri, Oct 18, 2013 at 12:10 PM, Thomas Broyer t.bro...@gmail.com wrote: On Friday, October 18, 2013 7:21:48 AM UTC+2, Colin Alworth wrote: Just wandered by https://gwt-review.**googlesource.com/#/c/1040/https://gwt-review.googlesource.com/#/c/1040/and noticed that with this change, any downstream generator/linker using the static helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the other discussions going on about JRE and browser support, perhaps we could discuss something policy-like around 'internal' code like this? If the policy that internal public methods are not actually for public consumption, or subject to breakage across minor releases, we should note that somewhere to keep people away. My inclination is that we want to encourage downstream code to use utility methods like this rather than copying them into their own projects. This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. AFAICT, the rule has always been to first make those utilities private as incubators and then move them to a public place when they're ready for prime-time. Re. this specific change, we could do the move in 2 steps though: make the c.g.g.dev.util classes simply call to the new c.g.g.tools.util.shared ones, and deprecate them; and remove them in a later release. Actually, I'm not sure if the compiler guys were treating c.g.g.dev.util as public. And again on the side of discouraging use of code like this, how far and wide can public code be expected to be 'usable by downstream'? The com.google.gwt.editor.rebind.**model.ModelUtils class is very handy for getting specifics about generic types, but from its package it is clearly part of editor so could change with modifications to that framework, whereas Name and StringKey seem to be in the relatively 'safe' package of com.google.gwt.dev.util with other benign classes like Util. Thoughts? ModelUtils should clearly be moved to a util package and made public (possibly with some cleanup). It's used by AutoBeans and RequestFactory too. In the mean time, you should cherry-pick those classes into your own source tree. That's the current unwritten policy as I understand it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Reminder: GWT 2.6 feature complete is Nov 4
I really would like to see some of these make the cut. Most of the which are trivial fixes, some have patches proposed. title set on parent TreeItem appears also on its children http://code.google.com/p/google-web-toolkit/issues/detail?id=1393 HeaderPanel setHeaderWidget is broken http://code.google.com/p/google-web-toolkit/issues/detail?id=7037 BorderStyle enum is missing values http://code.google.com/p/google-web-toolkit/issues/detail?id=8071 Inconsistent TextArea border-top style http://code.google.com/p/google-web-toolkit/issues/detail?id=8176 Vertical MenuBar popup is always left aligned even if there is not enough right-space to do so. http://code.google.com/p/google-web-toolkit/issues/detail?id=3888 Add max-height and max-width support to Style http://code.google.com/p/google-web-toolkit/issues/detail?id=7905 I don't necessarily care about this one but it is just a documentation fix... Documentation for TabBar doesn't list gwt-TabBarItem-disabled *http://code.google.com/p/google-web-toolkit/issues/detail?id=4050*http://code.google.com/p/google-web-toolkit/issues/detail?id=4050 On Thursday, October 17, 2013 1:22:56 PM UTC-4, Matthew Dempsky wrote: Hi all, Just writing to remind everyone that the GWT 2.6 feature complete deadline is November 4th. On that day I'll fork the GWT 2.6 release branch, and I'll only approve patches for release critical bug fixes. The GWT 2.6 Release Planhttps://docs.google.com/a/gwtproject.org/document/d/1ZdMwcTjc4rkWg6nntCY1BDB1xI2PHPwaCnTYw-9uAKE/edit# contains the handful of outstanding issues that I know we still want to get in for 2.6, and I'll be following up with people to try to make sure they're merged in time. If there are other features you think should be included but aren't listed, please speak up now so I can add them and track their progress. Thanks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Non-client apis and breaking changes
On Friday, October 18, 2013 1:53:46 PM UTC+2, Goktug Gokdogan wrote: On Fri, Oct 18, 2013 at 12:10 PM, Thomas Broyer t.br...@gmail.comjavascript: wrote: On Friday, October 18, 2013 7:21:48 AM UTC+2, Colin Alworth wrote: Just wandered by https://gwt-review.**googlesource.com/#/c/1040/https://gwt-review.googlesource.com/#/c/1040/and noticed that with this change, any downstream generator/linker using the static helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the other discussions going on about JRE and browser support, perhaps we could discuss something policy-like around 'internal' code like this? If the policy that internal public methods are not actually for public consumption, or subject to breakage across minor releases, we should note that somewhere to keep people away. My inclination is that we want to encourage downstream code to use utility methods like this rather than copying them into their own projects. This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. AFAICT, the rule has always been to first make those utilities private as incubators and then move them to a public place when they're ready for prime-time. Re. this specific change, we could do the move in 2 steps though: make the c.g.g.dev.util classes simply call to the new c.g.g.tools.util.shared ones, and deprecate them; and remove them in a later release. Actually, I'm not sure if the compiler guys were treating c.g.g.dev.util as public. I do believe they treated it as private (see the javadoc for c.g.g.dev.util.Util) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Reminder: GWT 2.6 feature complete is Nov 4
Hi, I really like to see following issues reviewed. All of them have proposed patches. As for now, I have to implement workarounds in my projects. Elemental json works not properly in super dev mode: https://code.google.com/p/google-web-toolkit/issues/detail?id=8306 MapFromStringTo.values() throws exception: https://code.google.com/p/google-web-toolkit/issues/detail?id=7655https://code.google.com/p/google-web-toolkit/issues/detail?id=7655can=5colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars Support for NavigableMap/NavigableSet: https://code.google.com/p/google-web-toolkit/issues/detail?id=4236https://code.google.com/p/google-web-toolkit/issues/detail?id=4236q=navigablemapcolspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Reminder: GWT 2.6 feature complete is Nov 4
Hi, I really like to see following issues reviewed. All of them have proposed patches. As for now, I have to implement workarounds in my projects. Elemental json works not properly in super dev mode: https://code.google.com/p/google-web-toolkit/issues/detail?id=8306 MapFromStringTo.values() throws exception: https://code.google.com/p/google-web-toolkit/issues/detail?id=7655https://code.google.com/p/google-web-toolkit/issues/detail?id=7655can=5colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars Support for NavigableMap/NavigableSet: https://code.google.com/p/google-web-toolkit/issues/detail?id=4236https://code.google.com/p/google-web-toolkit/issues/detail?id=4236q=navigablemapcolspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Stars Thanks -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Non-client apis and breaking changes
On Fri, Oct 18, 2013 at 3:21 PM, Thomas Broyer t.bro...@gmail.com wrote: On Friday, October 18, 2013 1:53:46 PM UTC+2, Goktug Gokdogan wrote: On Fri, Oct 18, 2013 at 12:10 PM, Thomas Broyer t.br...@gmail.comwrote: On Friday, October 18, 2013 7:21:48 AM UTC+2, Colin Alworth wrote: Just wandered by https://gwt-review.**googlesourc**e.com/#/c/1040/https://gwt-review.googlesource.com/#/c/1040/and noticed that with this change, any downstream generator/linker using the static helper methods in Name will no longer build across 2.5.1 to 2.6.0. With the other discussions going on about JRE and browser support, perhaps we could discuss something policy-like around 'internal' code like this? If the policy that internal public methods are not actually for public consumption, or subject to breakage across minor releases, we should note that somewhere to keep people away. My inclination is that we want to encourage downstream code to use utility methods like this rather than copying them into their own projects. This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. AFAICT, the rule has always been to first make those utilities private as incubators and then move them to a public place when they're ready for prime-time. Re. this specific change, we could do the move in 2 steps though: make the c.g.g.dev.util classes simply call to the new c.g.g.tools.util.shared ones, and deprecate them; and remove them in a later release. Actually, I'm not sure if the compiler guys were treating c.g.g.dev.util as public. I do believe they treated it as private (see the javadoc for c.g.g.dev.util.Util) Yeap. We should make this more explicit by using naming conventions similar to the rest of the SDK (i.e. impl). I actually asked this from Roberto but can't remember his response at the moment (adding to cc). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Where is gwt-customchecks.jar?
Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Where is gwt-customchecks.jar?
Hello. I found it in the old svn repository. Sorry can't provide the link right now, but you'll find it with your preferred search engine ;-) Hope this helps, Michael -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Where is gwt-customchecks.jar?
Thanks Michael! I will search it. - Andrés Testi El viernes, 18 de octubre de 2013 12:51:40 UTC-3, Michael Vogt escribió: Hello. I found it in the old svn repository. Sorry can't provide the link right now, but you'll find it with your preferred search engine ;-) Hope this helps, Michael -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Non-client apis and breaking changes
On Fri, Oct 18, 2013 at 5:10 AM, Thomas Broyer t.bro...@gmail.com wrote: This is what the c.g.g.util is for AFAICT, with c.g.g.util.tools.shared being for things usable on server-side (included in gwt-servlet); and as a rule of thumb any class not listed in the javadocs we generate should be considered private. I disagree with that -- I think unless the package includes impl or the name or Javadoc clearly indicates it is an implementation class, any public class should be considered public. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
