Re: GWT Developer Plugin installed but (apparently) not recognized
I agree with Sergey Shpikin, with Super Dev Mode I can't debug my application effectively, there's no stacktrace to trace exceptions, no breackpoint, no variable value monitor, I have use console.log to trace variables (as you guess, it's wrong way). Anyway, you can't say we must use third-party tools to debug GWT application, so, please bring Dev Mode back or same thing better than Super Dev Mode. BTW, Deobfuscating the stacktrace on SDBG is only mostly working: - Deobfuscating the stacktrace. Works but does not look 100% like e.g. the JDT Debugger stacktrace. For example, the methods are not deobfuscated to their Java equivalents 2014-05-22 23:57 GMT+07:00 Sergey Shpikin radioanon...@gmail.com: Thanks for your answers! I know that the classic dev mode had to be replaced, just didn't expect this to happen so soon without an on par working analog. I'll try to dig into SDBG on my free time but until that I'll use Chromium 34 (it works fine btw, tried today without issues so far). Happy to hear that GWT is being worked on fine but devtools now need more love than ever. It's always a pain when you invest lots of time into some framework and then it suddenly becomes (partly) unusable and you're just lost. Especially if you develop at work. I also highly agree with Vassilis Virvilis. But I also want to expand this JS-hatred to HTML for webapps. It's really not suited for designing user interfaces but it's something we have to deal with. GWT relieves us from the pain of cross-browser design and JS trickery bringing every good Java-world thing to the web world. And that's what I'm grateful to it for. Java became popular because of *tools*, and so did GWT. Thank you for doing that, I hope SDM will catch up fast enough if CDM can't be ported. On Thursday, 22 May 2014 12:25:49 UTC+4, Thomas Broyer wrote: -- 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. -- 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: Google Chrome 35 GWT plugin incompatibility
Am Donnerstag, 22. Mai 2014 16:25:30 UTC+2 schrieb stuckagain: I tried out SuperDevMode yesterday in Chrome ... not impressed. I think this is going to be a nightmare unless they find a way to show objects and fields as we know them in Java. Explain, explain? :) I found every object I looking for inside the chrome tools. I don't think its a nightmare its just something new to work with. And sure, I would love to use CTRL + Left Mouse Click to navigate through my source-map classes :) I work with the SuperDevMode for 1-2 month now. The first few weeks, I hated to work with it too, but today, I don't want to got back to the DevMode. The main issue for us was the long compile time of our gwt project. Therefore, we had to split it into two projects and right now, our recompile time drops from 70 seconds to 15 seconds. Sure, you don't have the eclipse/intellij debugger, but the Chrome F12 Tool is pretty good and the debugging is much closer to your real application. For example, you can inspect your elements DOM-state while you hold your program in a breakpoint. Alex -- 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 ways to speedup UI development
Hello guys, I am doing intensive research for the question How to speedup forms development in GWT?. The figures shows itself, that most time consuming tasks are those related to UI building. I have a lot of form components (fields, listbox, textbox, calendards, etc.) and some custom validation framework. Once a time there is a not standard business requirement to provide some specific behavior in component, it could be field dependency (visibility or validation dependencies). Moreover, all logic is compacted in one library used by many application so I must be careful with changes due to the fact, that business requires just change in aplication X leaving Y,Z and V untouched. I tried: - GWT plugin for Eclipse, but without luck - Some XForms standard to include in GWT project, but without luck. Have you got some standard in UI development? Or some usefull tools, procedures? I am still suffering from consuming UI dev including not only GWT, but also CSS, UI.XML etc. I am looking forward for asnwer, Cheers. -- 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: Google Chrome 35 GWT plugin incompatibility
Try Chrome Portables: http://sourceforge.net/projects/portableapps/files/Google%20Chrome%20Portable/Google%20Chrome%20Portable%2034/ On Thursday, May 22, 2014 9:12:12 AM UTC-7, Blake wrote: I have spent the last hour looking for Chrome 34 (the last version to support dev mode on Linux - I believe). Apparently, Google has gone far out of their way to make sure nobody can find old version of Chrome. Even the sites that specialize in saving old versions of software just link to Google download. They don't store old versions either. (Since they don't have old versions of Chrome, and that is their business, I feel confident that Google made sure they don't!) Not only do they make finding old versions nearly impossible, but they also make it as difficult as they can to stop auto-updates. I think it is real pompous of Google to drop support of GWT debugging without making it possible for developers to stick with an old version. This would have given us time more time to improve SuperDevMode. I know they have been warning us, and that is fine. They can do as they please. The problem is them making it nearly impossible to get or use an older version. I understand and appreciate Google's problems with Oracle, and their subsequent pseudo abandonment of GWT, but they shouldn't punish all the people who have committed to Google's GWT when it was Google's. Anyway, I downloaded and saved a copy of Chrome 33 for all platforms. Does anyone have version 34? Thanks. Blake On Thu, May 22, 2014 at 4:48 AM, Алексей Волков sof...@gmail.comjavascript: wrote: Chrome just updated to 35.0.1916.114 and thats broke the GWT development plugin stating: Sorry, the GWT Developer Plugin no longer works with Chrome on Linuxccseferf I am running Linux Mint 16 with default depositories and autimatic updates, is it possible to get GWT plugin back to work? -- 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 javascript:. To post to this group, send email to google-we...@googlegroups.comjavascript: . 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 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: Google Chrome 35 GWT plugin incompatibility
I guess it is indeed caused by many years of working with the debugger in eclipse. I'm getting old :-) Being able to inspect DOM elements is definitely a bonus for Super Dev Mode. The nice thing about DevMode was that if you made client changes that you could test them straight away without a redeploy. (We are using -noserver because our server is Jboss Fuse). I will need to rebuild and redeploy the application now for every client code change (or am I understanding this wrongly ?) David On Fri, May 23, 2014 at 10:32 AM, Alex Ph alex.philipp...@googlemail.comwrote: Am Donnerstag, 22. Mai 2014 16:25:30 UTC+2 schrieb stuckagain: I tried out SuperDevMode yesterday in Chrome ... not impressed. I think this is going to be a nightmare unless they find a way to show objects and fields as we know them in Java. Explain, explain? :) I found every object I looking for inside the chrome tools. I don't think its a nightmare its just something new to work with. And sure, I would love to use CTRL + Left Mouse Click to navigate through my source-map classes :) I work with the SuperDevMode for 1-2 month now. The first few weeks, I hated to work with it too, but today, I don't want to got back to the DevMode. The main issue for us was the long compile time of our gwt project. Therefore, we had to split it into two projects and right now, our recompile time drops from 70 seconds to 15 seconds. Sure, you don't have the eclipse/intellij debugger, but the Chrome F12 Tool is pretty good and the debugging is much closer to your real application. For example, you can inspect your elements DOM-state while you hold your program in a breakpoint. Alex -- 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. -- 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: How to display an ampersand using UiBinder?
I'm trying to create a repro case... but strangely enough there seems to be more involved. A straightforward demo does not expose the problem. So there must be something else that is causing this. I'll keep on searching. On Wed, May 21, 2014 at 11:12 AM, Thomas Broyer t.bro...@gmail.com wrote: I think it's a bug though that HasSafeHtml works but not HasHTML. If you can provide a small repro case, please file a bug in the tracker. That said, it's really surprising that there's a difference, as there's no special parser for HasSafeHtml (that itself is probably a bug: that means a widget implementing HasSafeHtml but not HasHTML couldn't use child content and must use an HTML=foo bar attribute). There probably is some reflection in play that sees the setHTML(SafeHtml) and uses it instead of setHTML(String), but still the result is surprising. As for raquo; vs amp; I can understand it: those are evaluated by the XML parser and (I believe, haven't checked) UiBinder doesn't see them; but the cannot be output as is and must be escaped, contrary to ». I believe you won't find raquo; in the generated code, but ». On Wednesday, May 21, 2014 10:43:06 AM UTC+2, stuckagain wrote: It turns out that my custom widget was the root of the problem. It implements HasHTML but not HasSafeHtml (I thought I had it implemented). It is strange that the raquo; was properly showing, but not amp; or #38; that threw me off a bit. David On Wednesday, May 21, 2014 9:45:25 AM UTC+2, stuckagain wrote: I have to revive this thread. I just stumbled on the same problem in my UiBinder file. This really looks like a bug in GWT UiBinder. I am using a different widget than Label (my own custom Button class that extends HasHTML and HasSafeHtml). I include the entity line: !DOCTYPE ui:UiBinder SYSTEM http://dl.google.com/gwt/DTD/xhtml.ent; and then I have this in my UiBinder: w:Button ui:field=buttonView and manage all user roles (own amp; delegated) raquo;/w:Button The raquo; is properly showing the right double arrow sign, the is not properly showing. I also tried to use #38; instead of amp; but it gets printed as amp; So, this must be a bug in GWT UiBinder (not in SafeHtmlBuilder I tried that one already). David On Thursday, December 16, 2010 1:07:23 AM UTC+1, Hilco Wijbenga wrote: On 15 December 2010 15:06, Nick Newman nick.x...@gmail.com wrote: You say that using A B C obviously fails (because the ampersand is illegal in the XML). Does using a CDATA section to make it legal work? :-) Nice one! Yes, GWT finds that acceptable. Unfortunately, I still need to use g:HTML instead of g:Label as Mauro indicated. It's not a very big deal since the generated HTML is the same except for the CSS class name used. I just wish I could treat all labels the same. -- 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. -- 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: Google Chrome 35 GWT plugin incompatibility
The nice thing about DevMode was that if you made client changes that you could test them straight away without a redeploy. (We are using -noserver because our server is Jboss Fuse). I will need to rebuild and redeploy the application now for every client code change (or am I understanding this wrongly ?) You understand it wrong. When you make a client code change you hit the recompile bookmarklet of SuperDevMode (which you can drag in your browser's bookmark bar) to trigger a recompile of your app. After the app is recompiled the page reloads automatically and you will see the changes. You only need to redeploy if you make server changes. When you activate SDM through its bookmarklet all client side code will be downloaded from the SDM code server and not from your Jboss Fuse server. With GWT 2.6 the recompile time may take some time (its similar to a -draft compile)...how long that greatly depends on your app. However GWT trunk already has initial support for incremental/modular compilation. With incremental compilation turned on GWT will only recompile the GWT modules in which you have made changes and the ones that depend on them. So to make best use of incremental compilation your app should consist of multiple smaller GWT modules instead of a single large one. -- 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: Google Chrome 35 GWT plugin incompatibility
@David I improved the productivity using DCEVMhttps://github.com/dcevm/dcevm to reduce application redeploys when server side code is modified. There are another alternatives, but this is free. 2014-05-23 16:17 GMT-03:00 Jens jens.nehlme...@gmail.com: The nice thing about DevMode was that if you made client changes that you could test them straight away without a redeploy. (We are using -noserver because our server is Jboss Fuse). I will need to rebuild and redeploy the application now for every client code change (or am I understanding this wrongly ?) You understand it wrong. When you make a client code change you hit the recompile bookmarklet of SuperDevMode (which you can drag in your browser's bookmark bar) to trigger a recompile of your app. After the app is recompiled the page reloads automatically and you will see the changes. You only need to redeploy if you make server changes. When you activate SDM through its bookmarklet all client side code will be downloaded from the SDM code server and not from your Jboss Fuse server. With GWT 2.6 the recompile time may take some time (its similar to a -draft compile)...how long that greatly depends on your app. However GWT trunk already has initial support for incremental/modular compilation. With incremental compilation turned on GWT will only recompile the GWT modules in which you have made changes and the ones that depend on them. So to make best use of incremental compilation your app should consist of multiple smaller GWT modules instead of a single large one. -- 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. -- 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: Google Chrome 35 GWT plugin incompatibility
Hi,
I didn't know about DCEVM. Thanks for sharing.
In my poor old development machine I am employing hot-deploy on tomcat.
This works nicely because my webapp has zero initialization cost and the
time is actually consumed on war zip/copy/unzip. We are talking 7sec vs
21sec differences.
Here is the script I use. Your mileage may vary. Also take into account
that you will need some iterations to make sure that it actually hot
deploys in tomcat as it is more fragile than reploy. And AFAIR there was
also a tomcat configuration variable that enables hot deploy but I
cannot remember details.
Hint: Put some logs in the constructor of your service so that you know
the redeploy is triggered.
cut here hot-deploy.sh
#!/bin/sh -e
TOMCAT=$HOME/tomcat;
WEBAPPSDIR=$TOMCAT/webapps;
LOGDIR=$TOMCAT/logs;
WEBAPP=sn;
LOG=$LOGDIR/$WEBAPP.log;
[ -d war ] || { echo Cannot find war directory 2; exit 1; }
prev_line=`tail -n 1 $LOG`;
rsync -av war/ $WEBAPPSDIR/$WEBAPP;
[ $1 = -n ] exit 0;
touch $WEBAPPSDIR/$WEBAPP/WEB-INF/web.xml;
#echo $prev_line;
while : ; do
next_line=`tail -n 1 $LOG`;
/bin/echo -ne .;
sleep 1;
[ $prev_line = $next_line ] || break;
done;
echo ;
#echo $next_line;
On 05/23/14 22:35, Juan Pablo Gardella wrote:
@David I improved the productivity using DCEVM
https://github.com/dcevm/dcevm to reduce application redeploys when
server side code is modified. There are another alternatives, but this
is free.
2014-05-23 16:17 GMT-03:00 Jens jens.nehlme...@gmail.com
mailto:jens.nehlme...@gmail.com:
The nice thing about DevMode was that if you made client
changes that you could test them straight away without a
redeploy. (We are using -noserver because our server is Jboss
Fuse).
I will need to rebuild and redeploy the application now for
every client code change (or am I understanding this wrongly ?)
You understand it wrong. When you make a client code change you
hit the recompile bookmarklet of SuperDevMode (which you can drag
in your browser's bookmark bar) to trigger a recompile of your
app. After the app is recompiled the page reloads automatically
and you will see the changes. You only need to redeploy if you
make server changes. When you activate SDM through its bookmarklet
all client side code will be downloaded from the SDM code server
and not from your Jboss Fuse server.
With GWT 2.6 the recompile time may take some time (its similar to
a -draft compile)...how long that greatly depends on your app.
However GWT trunk already has initial support for
incremental/modular compilation. With incremental compilation
turned on GWT will only recompile the GWT modules in which you
have made changes and the ones that depend on them. So to make
best use of incremental compilation your app should consist of
multiple smaller GWT modules instead of a single large one.
--
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
mailto:google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to
google-web-toolkit@googlegroups.com
mailto: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.
--
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
mailto:google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to
google-web-toolkit@googlegroups.com
mailto: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.
--
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 Developer Plugin no longer works with Chrome on Linux
So what's the solution now for GWT developers who were using chrome? How are we going to develop with chrome now? On Thursday, May 22, 2014 3:52:38 PM UTC+5, Jens wrote: Chrome on Linux dropped NPAPI support which is needed for the GWT browser plugin, thus the plugin won't work anymore on Linux unless you use an older version of Chrome. Windows and Mac users will have the same issue in a couple of month. Firefox 24 ESR and the non ESR version up to version 26 should work. Just make sure to disable auto update. -- 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: GWT Developer Plugin no longer works with Chrome on Linux
So what's the solution now for GWT developers who were using chrome? How are we going to develop with chrome now? User SuperDevMode or use an older Chrome version and turn off autoupdate. -- 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: Google Chrome 35 GWT plugin incompatibility
FYI, I just use the maven plugins for tomcat or jetty which run the classes right from my projects (automatically recompiled by my IDE) with automatic app reload (or just a keypress away). See https://github.com/tbroyer/gwt-maven-archetypes for my setup. On a project with heavy jetty customization, we just had a dev config for jetty to load classes from our project, with automatic app reload. The same is available for tomcat. -- 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 ways to speedup UI development
Maybe look at Errai's HTML templates? -- 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 ways to speedup UI development
For me combination of UiBinder templates and Errai data bindings works perfectly fine. With UiBinder you can create reusable blocks/frames/components (I cannot find a proper description), i.e. for example FlowPanel with some different widgets can be considered as whole UI block. Then in other UiBinder templates just reuse this block as composite widget. On Friday, May 23, 2014 8:03:41 AM UTC-7, Mariusz Lewandowski wrote: Hello guys, I am doing intensive research for the question How to speedup forms development in GWT?. The figures shows itself, that most time consuming tasks are those related to UI building. I have a lot of form components (fields, listbox, textbox, calendards, etc.) and some custom validation framework. Once a time there is a not standard business requirement to provide some specific behavior in component, it could be field dependency (visibility or validation dependencies). Moreover, all logic is compacted in one library used by many application so I must be careful with changes due to the fact, that business requires just change in aplication X leaving Y,Z and V untouched. I tried: - GWT plugin for Eclipse, but without luck - Some XForms standard to include in GWT project, but without luck. Have you got some standard in UI development? Or some usefull tools, procedures? I am still suffering from consuming UI dev including not only GWT, but also CSS, UI.XML etc. I am looking forward for asnwer, Cheers. -- 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: SuperDevMode and APT
It's been two years. And, I was just push into this problem by Chrome dropping support for GWT plugin. i.e. I have to downgrade Firefox to version 24, or to struggle with super dev mode. However, both running a Firefox version 24, and a super dev mode lead me to the following exception, even with Paul's code to override RemoteServiceServlet. com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: This application is out of date, please click the refresh button on your browser. Is GWT going to get a death sentence? On Friday, June 15, 2012 3:49:13 PM UTC+8, Thomas Broyer wrote: On Friday, June 15, 2012 9:00:55 AM UTC+2, Paul Robinson wrote: Here are code fragments for you. It would be good if something like this could be built in to GWT rather than having everybody implement similar code. Keep in mind that SuperDevMode is experimental. It will probably evolve to the point where GWT-RPC won't be an issue, and this workaround won't be needed anymore, so there's no point in building it within GWT at this point. -- 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-contrib] Re: who discusses the next features and adopts feature requests?
On Friday, May 23, 2014 4:41:28 AM UTC+2, Zied Hamdi OneView wrote: * asks for a solution to an unknown problem, rather than exposing the problem and trying to find the best solution (which I believe is not the one suggested in the issue) * worse, it's not even a request for please make UiBinder extensible (for whatever definition of extensible), it's a please get out of my way so I can hack around * just Google *authorization in gwt* and you will see the problem doesn't have to be presented anymore, everyone knows it's not supported (it's definitely not an unknown problem Thomas) The issue of authorization in gwt is not unknown (BTW, I don't understand how it's a problem and even less how it's a problem in GWT; GWT doesn't provide tools specifically for that, but that doesn't mean it cannot be done, just that you have to do it yourself, or with third-party libraries such as AcrIS https://code.google.com/p/acris/wiki/SecurityClient – I never used it, just stumbled on it a few times). What I'm saying is that the issue doesn't state the problem you're trying to solve; it just says “I wanted to implement roles in my GWT application.” This is not enough of a problem description to me (just look back at the discussion with Jens to understand what I mean; different people have different expectations of what roles are and what they imply). * It's a pitty you interpreted the request for making the library extendable for the community as a personal attack, I didn't! I think it's legitimate to criticize code as long as it is constructive and can help have a better product * there had been previous decisions related to the (non-)extensibility of UiBinder So the problem is known and requested Yes, and the decisions were that @UiField(provided=true), @UiFactory, @UiConstructor and @UiChild were enough to support most use cases, and others could either be built on top of them or just not use UiBinder (at least for the cases where it doesn't fit) * UiBinder internals have changed dramatically in the past (e.g. when switching to SafeHtmlTemplates, almost everything got rewritten; then when introducing UiRenderer, then when tentatively introducing Renderable; there was also an attempt to replace the use of getElementById with walking the DOM, eliminating the use of temporary IDs on elements, or even placeholder elements in some cases); opening them for public consumption is a no-go on those grounds (similar to what you were saying) You're right, the source code has a lot of scenarios and is difficult to understand, but it shouldn't mean no one is allowed to use it apart GWT members, It's not even apart from GWT members. No one should try to re-use it (and I'm purposefully using re-use here). Everyone is free to fork it though. This doesn't apply only to UiBinder. Forks have a cost, but it's a cost for the maintainer of the fork, not for the maintainers of the original project (and by extension, the whole community: because that means time spent maintaining backwards-compatibility of some obscure APIs used by only a couple users cannot be spent on other things that would benefit everyone). And I'm not saying that specifically with my GWT maintainer hat; I also have to live with these decisions as a user of GWT; it's sometimes frustrating, but I believe it's the right thing to do. At work, I started bending RequestFactory to specific needs it wasn't designed for, and I had to maintain a fork and contribute patches. The patches took years (literally) to be accepted, and some of them only because I now am the maintainer of RequestFactory (co-maintainer, with Manolo). if we consent to use it despite its complexity and risk of having it changed, then we might have a good reason for that …and you could then just fork the code. I'm not talking about forking GWT, but, as you did, copy the classes in your own package and build your own enhanced version of UiBinder. The cost wouldn't be much different (trade the cost of having to adapt to breaking changes in new versions of GWT which can prevent you from upgrading, with the cost of integrating those changes into your fork at the time you choose to do it and without preventing you from upgrading GWT to benefit from other features and bug fixes). I believe (and I think it's the general feeling within the GWT team) those kind of forks are healthy; “duplication is far cheaper than the wrong abstraction”. -- 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/88602253-ac15-4925-b641-9e9fb3542d4a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Native Authorization in GWT
Hi, I want to talk about GWT authorizations to brainstorm an architecture that supports it natively. It's somehow surprising a framework that is in advance (adopted the Fog computing more than 5 years ago) doesn't provide a native support for security routines. Workarounds are naturally possible, but no real core solution is available, to specify how it should be done according to best practices and have developers immediately knowing what they do when they want to implement security in GWT. There are some open sources that already propose solutions for this subject, they or developers who used them are naturally welcome to discuss the even ad odd points from their feedback. Before I started this discussion I made a tour on the available solutions and I found all what I discovered either too intrusive (imposes its own architecture that might not be compatible with existing projects), or too superficial (means there is no central way of doing things). With the evolution of IT, many thinkers brought new ways of solving problems. All problems can't be solved with one only pattern and overusing a pattern can lead to bad architectures (hardly maintainable code). AOP is an example of these best practice ideas that couldn't be overused. It decomposes a layer (in a n layer architecture) into different logically splitted layers. In AOP the interceptor knows about his host but the host doesn't event know the AOP exists. This is a good approach to separate concerns. The logger, the security some visual adjustments etc... can intercept the program without this latter knowing about them. Another best practice pattern is the single access point: it is somehow related to the proxying because when all your program flow passes through a single object/method/facade, it is easy to intercept events and add logic. The event oriented programming is a direct iteration on these two patterns, it states that a shared event bus can make the entire application connected and make it possible to plug itself on the program without impacting it. I proposed a solution based on this approach to solve the security feature lack in GWT: an interception entry point to the creation of widgets to permit plugging into it and doing other interesting things GWT isn't obliged to be responsible of. My proposal is herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready happened in the user forum too about the subject. Your ideas and comments are welcome :) -- 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/73ffbe2a-e7fe-4be8-9e48-32631af6203b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: who discusses the next features and adopts feature requests?
Hi all, I created this post as I said because I was wondering about the evolution of the process of feature proposal acceptance. This was triggered by a feature proposal I made that was rejected, but it was only a trigger. So to avoid changing the subject and talking about why my proposal was rejected and forgetting to talk about: what is the best way to accept reject proposals, I created another discussion for the rejected feature request herehttps://groups.google.com/forum/#!topic/google-web-toolkit-contributors/Y_Cu_Nqzxv4 We stopped at my proposal to have a GWT official fork for incubating features (explaining that if any other entity than GWT does the fork, it won't be accepted by the community) -- 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/49603644-b215-4de7-b0b9-45c424523f14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Native Authorization in GWT
On Friday, May 23, 2014 3:59:35 PM UTC+2, Zied Hamdi OneView wrote: Hi, I want to talk about GWT authorizations to brainstorm an architecture that supports it natively. It's somehow surprising a framework that is in advance (adopted the Fog computing more than 5 years ago) doesn't provide a native support for security routines. Workarounds are naturally possible, but no real core solution is available, to specify how it should be done according to best practices and have developers immediately knowing what they do when they want to implement security in GWT. There are some open sources that already propose solutions for this subject, they or developers who used them are naturally welcome to discuss the even ad odd points from their feedback. Before I started this discussion I made a tour on the available solutions and I found all what I discovered either too intrusive (imposes its own architecture that might not be compatible with existing projects), or too superficial (means there is no central way of doing things). With the evolution of IT, many thinkers brought new ways of solving problems. All problems can't be solved with one only pattern and overusing a pattern can lead to bad architectures (hardly maintainable code). AOP is an example of these best practice ideas that couldn't be overused. It decomposes a layer (in a n layer architecture) into different logically splitted layers. In AOP the interceptor knows about his host but the host doesn't event know the AOP exists. This is a good approach to separate concerns. The logger, the security some visual adjustments etc... can intercept the program without this latter knowing about them. Another best practice pattern is the single access point: it is somehow related to the proxying because when all your program flow passes through a single object/method/facade, it is easy to intercept events and add logic. The event oriented programming is a direct iteration on these two patterns, it states that a shared event bus can make the entire application connected and make it possible to plug itself on the program without impacting it. I proposed a solution based on this approach to solve the security feature lack in GWT: an interception entry point to the creation of widgets to permit plugging into it and doing other interesting things GWT isn't obliged to be responsible of. My proposal is herehttps://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 https://code.google.com/p/google-web-toolkit/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsgroupby=sort=id=8727 A discussionhttps://groups.google.com/forum/#!topic/google-web-toolkit/wk9a3mCRliYalready happened in the user forum too about the subject. Your ideas and comments are welcome :) There's one big flaw with your proposal: it's not really “transparent”; the code “using” it has to know it's there (i.e. it's not AOP as you described it), because some @UiField could be 'null' or not visible (depending on actual implementation). I believe applying such a rule as “this widget might not be created at all” globally might solve some use cases, but opens other issues: e.g. how do I layout my screen depending on what's actually visible? Another rather big issue with the proposal is that it only applies to UiBinder. How do you solve the same problem when you're not using UiBinder? How about navigation in your app? (when you use History.newItem, or Places, or Activities, or a third-party solution such as GWTP – OK, GWTP has its own “security” feature) There's also the question of “what to do?” when a precondition is not met? Should the widget not be created at all? should it be hidden? should it matter to the user of the API? What if I'd prefer that my button be visible but disabled? Last, but not least, having such an API in GWT for widgets but nothing related to communications (GWT-RPC, RequestFactory) is likely to lead to applications that aren't actually secure, because developers have a false sense of security provided by the API that just doesn't create their widgets. So, my advice, as already given elsewhere, is: build what meets your immediate need (either from scratch, or on top of UiBinder, or as a fork of UiBinder), iterate on the API until you're satisfied, then (possibly) iterate again to try to solve other use-cases. If you forked UiBinder, try to come up with an extension API (preferably not extending/reusing the generator, but rather providing extensions to it, similar to how ResourceGenerator and CustomFieldSerializer allow modifying the generator's behavior) on which you could build your security-oriented feature and try to upstream the patch. When and if your library got enough traction, then you can propose it's made part
