Re: Compiling a single Java class to a plain JavaScript file
rapodaca: Reread my original post. Even if you turn the mangling off, the name would then become: com.mypackage.MyClass::hello() Instead of what you probably want: hello Due to the parens, you'd need to call it like so: window.[com.mypackage.MyClass::hello()](); instead of like so: hello(); 'unwieldly' doesn't really cover the ridiculousness of working with this. 'utterly ridiculous' is a bit closer to the mark. The above is WITHOUT the mangling. -style pretty is a bit less unwieldy, but, really, you'd have to get in there and write your own identifier formatter that does saner things, and that's just one thing that comes to mind. I'm fairly sure its not going to be the only hurdle. On Jan 8, 1:26 am, rapodaca rich.apod...@gmail.com wrote: On Jan 7, 12:20 am, ReinierZwitserlootreini...@gmail.com wrote: What you want can't really be done. Java isn't javascript. Take your example just to illustrate the problem here: How would that even translate to javascript? Javascript doesn't have classes. It has prototype based inheritance. Here are your fundamental problems: Reinier, thanks for the info. Actually, a class isn't the thing I'm after. What I really want to create are objects. So I thought it could translate something like this: html ... script src=hello.js/script ... script type=text/javascript var hello = new Hello(); hello.talk // returns hello /script ... /html What am I missing? 1. Javascript's namespacing and object model is so different, that GWT internally generates completely different and unwieldy names for objects and classes. These names are then mangled to unrecognizable shortcodes to reduce the size of the output JS. So, your public void hello method is either going to be called: com.mypackage.Hello::talk () (yes, including closing parentheses to indicate that this version takes no parameters; unlike javascript, in java two methods with the same name but different parameter lists are completely separate, in javascript you can't do that), or it's going to be called something small and effectively random, so something like 'xYq' or some such. There's no code to pick a sane name for interaction, so nothing there that would even think to generate just a function called hello. I thought it was possible to turn off the mangling by setting compiler flags. I've also read about JSNI in this context. Wouldn't one or both of these help? 2. There's a base set of functions that all GWT projects start out with. The GWT compiler assumes this basis is there. That wouldn't be a problem for me. 3. GWT does something called platform targeting. That's why it generates a number of JS files - one for each target platform. Out of the box, there are already multiple platforms (1 for each major supported browser, so there's an Opera, an IE, a Gecko, and a Webkit). I'm not entirely sure but I believe the base, talked about in #2, is already written specifically for each target browser platform. Also not a problem. If you are in the market to build such a tool, The GWT sources are a great place to start, but unless you're willing to dig in for a few weeks and do a lot of dev work, I don't think GWT can do what you want. Sounds way above my head. I have to say, though - I'm very surprised this hasn't been done already. It seems like such an obvious use of GWT. NB: I'm not an expert on the GWT internals so I might have made a few mistakes, but I'm fairly sure the above is true. #1 is certainly true, and already a big deal for you. On Jan 7, 7:20 am, rapodaca rich.apod...@gmail.com wrote: On Jan 6, 5:58 pm, Ziyod ziyod2...@gmail.com wrote: Use GWTCompiler it's part of the com.google.gwt.dev.GWTCompiler package Create a gwtCompiler.cmd file and insert this command: @java -cp %~dp0\gwt-user.jar;%~dp0\gwt-dev-windows.jar com.google.gwt.dev.GWTCompiler %* Hello Ziyod, Thanks for the information. I'm on Linux, but my best guess for translation is (creating file GWT_INSTALL/gwtCompiler): java -cp $HOMEDIR/gwt-user.jar:$HOMEDIR/gwt-dev-linux.jar com.google.gwt.dev.GWTCompiler $@; This is based on the projectCreator script provided in the installation. I notice that HOMEDIR is not set so I go: $ export HOMEDIR=~/tmp/gwt-linux-1.5.3 Then I try: $ ./gwtCompiler com.example.Test Loading module 'com.example.Test' [ERROR] Unable to find 'com/example/Test.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source? [ERROR] Build failed I'm not sure what happened or what the com/example/Test.gwt.xml file refers to. Any ideas of how to generate it and where to save it? Find out more:http://www.screaming-penguin.com/GWTDocs That's a good command summary, but unfortunately, I don't see any example usage. --~--~-~--~~~---~--~~ You received this
Re: Programmatically Generating Physical Key
I assume you meant faking the pressing of a key on the keyboard. You can't do that directly, no, but you can sort-of call the keylisteners on any particular object. For example, let's say you have a TextBox instance called 'textBox', and you want to simulate pressing the 'X' button. You'll need to do two things: 1) Simulate the effect of the X button on the textBox itself, which means updating the text inside by inserting an X at the current cursor position. 2) Call all keyboardlisteners on textBox. #2 can be done with some technically nonsupported hackery - each implementation of SourcesKeyboardEvents in GWT at least has an internal private object of type 'KeyboardListeners', called 'keyboardListeners'. While its private, you can still get at it via JSNI (look that up) which doesn't know about 'private' and thus allows it. Once you have the keyboardListeners, which is really just an ArrayList, you can loop through them and fire the appropriate call (e.g. onKeyPress) on all of them. The reason GWT doesn't support this directly is because javascript doesn't support it either. GWT isn't magic; it cannot make things that are impossible on the target platform possible. On Jan 2, 2:26 pm, Anurag Tripathi anurag...@gmail.com wrote: Can we programmatically generate physical keys in GWT ? Scenario : I want to generate some key on clicking in Button ! If anyone has any idea on this, please let me know - _Anurag --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Compiling a single Java class to a plain JavaScript file
rapodaca: The GWTCompiler is simply what drives the myProject-compile command; it does the same thing (translates a whole bunch of things into a single JS file), so I doubt its what you're looking for. What you want can't really be done. Java isn't javascript. Take your example just to illustrate the problem here: How would that even translate to javascript? Javascript doesn't have classes. It has prototype based inheritance. Here are your fundamental problems: 1. Javascript's namespacing and object model is so different, that GWT internally generates completely different and unwieldy names for objects and classes. These names are then mangled to unrecognizable shortcodes to reduce the size of the output JS. So, your public void hello method is either going to be called: com.mypackage.Hello::talk () (yes, including closing parentheses to indicate that this version takes no parameters; unlike javascript, in java two methods with the same name but different parameter lists are completely separate, in javascript you can't do that), or it's going to be called something small and effectively random, so something like 'xYq' or some such. There's no code to pick a sane name for interaction, so nothing there that would even think to generate just a function called hello. 2. There's a base set of functions that all GWT projects start out with. The GWT compiler assumes this basis is there. 3. GWT does something called platform targeting. That's why it generates a number of JS files - one for each target platform. Out of the box, there are already multiple platforms (1 for each major supported browser, so there's an Opera, an IE, a Gecko, and a Webkit). I'm not entirely sure but I believe the base, talked about in #2, is already written specifically for each target browser platform. If you are in the market to build such a tool, The GWT sources are a great place to start, but unless you're willing to dig in for a few weeks and do a lot of dev work, I don't think GWT can do what you want. NB: I'm not an expert on the GWT internals so I might have made a few mistakes, but I'm fairly sure the above is true. #1 is certainly true, and already a big deal for you. On Jan 7, 7:20 am, rapodaca rich.apod...@gmail.com wrote: On Jan 6, 5:58 pm, Ziyod ziyod2...@gmail.com wrote: Use GWTCompiler it's part of the com.google.gwt.dev.GWTCompiler package Create a gwtCompiler.cmd file and insert this command: @java -cp %~dp0\gwt-user.jar;%~dp0\gwt-dev-windows.jar com.google.gwt.dev.GWTCompiler %* Hello Ziyod, Thanks for the information. I'm on Linux, but my best guess for translation is (creating file GWT_INSTALL/gwtCompiler): java -cp $HOMEDIR/gwt-user.jar:$HOMEDIR/gwt-dev-linux.jar com.google.gwt.dev.GWTCompiler $@; This is based on the projectCreator script provided in the installation. I notice that HOMEDIR is not set so I go: $ export HOMEDIR=~/tmp/gwt-linux-1.5.3 Then I try: $ ./gwtCompiler com.example.Test Loading module 'com.example.Test' [ERROR] Unable to find 'com/example/Test.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source? [ERROR] Build failed I'm not sure what happened or what the com/example/Test.gwt.xml file refers to. Any ideas of how to generate it and where to save it? Find out more:http://www.screaming-penguin.com/GWTDocs That's a good command summary, but unfortunately, I don't see any example usage. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Newbie Question on GWT/JSON
Whoops, forgot my footnote: [1] http://www.ietf.org/rfc/rfc4627.txt I don't know if that makes it official. I believe the official entity that vets mime types is IANA, but on their site I couldn't quickly get to an official list of recognized mime types. Still, if Doug Crockford says the type is application/json, and almost everyone uses that, that's the standard. That's how the internet works; standards bodies can wax rhapsodic about whatever they fancy, but if no one does it, it's not something you should be doing either, regardless of whether or not its the 'official standard', so, there you have it. Oh, and martykube: Be careful that your soul doesn't waft out the window that is giving you that fresh air. As a general rule, if PHP is a good fit for you, grails, rails, or django are usually an even better fit. On Jan 4, 11:48 pm, rakesh wagh rake...@gmail.com wrote: You probably got your answer by now. Think this way. JSON string is like any other string. The transport mechanism does not have to know weather it is json or text or number or binary or otherwise. With that said, you can use forms with get or post(knowing the advantages drawback of each will help you select the right mechanism) and simply posting it to your php page. In your php page, read the request parameters as if they were any other parameters. As a matter of fact you can even append the json string as part of your target page url with a variable name and expect the json string (with a hyperlink click) to reach its destination as expected. Good luck! Rakesh Wagh On Jan 3, 9:09 pm, Ian ikra...@gmail.com wrote: I am new to the Web application world; I am trying to encapsulate my set of data in a JSONObject, convert to string, and send it (async POST) to a PHP page using GWT's RequestBuilder. GWT's tutorial discusses the trip from the server back to the client and not the other way around where I am unclear about. Do I need to set the header? Currently I set it to: builder.setHeader(Content-Type, application/x-www-form- urlencoded); However, this works fine as long as am sending key1=value1key2=values where I can retrieve variable via $_POST ['key1'] or $_POST['key2'] But I am not sure how to send a JSON string where it can be retrieved in a php page. I have tried sending myvar=MyJsonString but cannot retrieve in my php page. How should $_POST reference the JSON object? Any clarification would be much appreciated. Thanks, Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Performance overhead of virtual methods
Assuming you meant 'virtual' in the C++ sense, then, nothing. On Jan 3, 1:09 pm, Jason Morris lem...@gmail.com wrote: nathan.r.matth...@googlemail.com wrote: Hi GWTers I'm writing some performance sensitive code for GWT. I'm wondering how GWT compiles virtual functions to JavaScript. What's the associated performance overhead? Obviously I'd like to use proper polymorphism but if there's a significant performance overhead it may be worth re- factoring various parts of the code-base. Regards, Nathan Hi Nathan, Someone else can correct me if I'm wrong, but after taking a look at the generated code, it seems that virtual methods shouldn't incur any additional performance overhead in GWT. Basically the bottom level method is given the top-level declared name in each object instance, thus the lookup expense is the same as that of a non-virtual method. Like I said, if I'm wrong on this, someone should correct me. ;) Cheers, Jason. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Newbie Question on GWT/JSON
Whatever possessed you to send the application/x-www-form- urlencoded as mime type? JSON is nothing like form-encoded. That's like sending your HTML as image/jpeg just for kicks. Don't do that. JSON's mimetype is application/json (see [1] below). If you want to be nice, you should actually set that in the header (as follows: Content-type: application/json; encoding=UTF-8 - note that JSON is defined to be UTF-8 encoded, so you're just clarifying there, you can't pick your own encoding). And, yes, of course, in PHP you would have to get the entire request body, instead of letting PHP try to parse it as form data. Possibly PHP is presuming that the data IS form encoded when there is no header at all. Is file_get_contents(php://input); really the only feasible way to get the entire body in PHP? Oh, PHP. Every single time someone posts a code snippet written in PHP, my aesthetic sense blows its brains out in sheer despair. And this one is up there, which is really saying something. I think its a conspiracy by the zend folks to make the inner child of developers worldwide die a little inside every time they come in contact with it. Sadistic bastards. On Jan 4, 6:52 am, Ian ikra...@gmail.com wrote: For those who might be facing a similar problem and others who might be interested in my previous question I have come up with an answer. First my disclaimer: the solution below may not be the proper one but it does work. Now on to the solution: On the GWT Client Side: JSONObject jObject = new JSONObject(); jObject .put(propA, new JSONString(valA)); jObject .put(... RequestBuilder builder = new RequestBuilder(RequestBuilder.POST, YOUR_PHP_URL); builder.sendRequest(jObject.toString(), new YourReponseHandler()); Note that there is no setHeader. On the PHP side: Get the raw data instead of $_POST $jsonReq = file_get_contents(php://input); Decode the json request $request = json_decode($jsonReq); Cheers, Ian On Jan 3, 10:09 pm, Ian ikra...@gmail.com wrote: I am new to the Web application world; I am trying to encapsulate my set of data in a JSONObject, convert to string, and send it (async POST) to a PHP page using GWT's RequestBuilder. GWT's tutorial discusses the trip from the server back to the client and not the other way around where I am unclear about. Do I need to set the header? Currently I set it to: builder.setHeader(Content-Type, application/x-www-form- urlencoded); However, this works fine as long as am sending key1=value1key2=values where I can retrieve variable via $_POST ['key1'] or $_POST['key2'] But I am not sure how to send a JSON string where it can be retrieved in a php page. I have tried sending myvar=MyJsonString but cannot retrieve in my php page. How should $_POST reference the JSON object? Any clarification would be much appreciated. Thanks, Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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 -~--~~~~--~~--~--~---
[gwt-contrib] Am I going nuts? JavaScriptObject fields not accessible in JSNI.
I tried to do something fairly simple:
package testpackage;
public class MyClass {
@SuppressWarnings(unused)
private JavaScriptObject rawMap = JavaScriptObject.createObject();
private native void setSomething(String x) /*-{
th...@testpackage.client.myclass::rawMap[foo] = x;
}-*/;
private native String getSomething() /*-{
return th...@testpackage.client.myclass::rawMap[foo];
}-*/;
}
but it doesn't work - 'rawMap' doesn't exist according to GWT. (member
not found; expect subsequent errors). Yet when I replace my rawMap
with an identical line, except making rawMap an int, the error goes
away. I've worked around it with non-JSNI wrapper methods that pass
the JSO into and out of JSNI methods, but shouldn't the above code
just work?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Am I going nuts? JavaScriptObject fields not accessible in JSNI.
I swear I looked for 30 seconds+ for typos and even copypasted the
package name, but, of course, I typoed the field name. Ignore this, my
bad.
On Jan 4, 8:23 am, Reinier Zwitserloot reini...@gmail.com wrote:
I tried to do something fairly simple:
package testpackage;
public class MyClass {
@SuppressWarnings(unused)
private JavaScriptObject rawMap = JavaScriptObject.createObject();
private native void setSomething(String x) /*-{
th...@testpackage.client.myclass::rawMap[foo] = x;
}-*/;
private native String getSomething() /*-{
return th...@testpackage.client.myclass::rawMap[foo];
}-*/;
}
but it doesn't work - 'rawMap' doesn't exist according to GWT. (member
not found; expect subsequent errors). Yet when I replace my rawMap
with an identical line, except making rawMap an int, the error goes
away. I've worked around it with non-JSNI wrapper methods that pass
the JSO into and out of JSNI methods, but shouldn't the above code
just work?
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Re: jsp + javascript code not working. why?
The bit you posted isn't the problem. On Jan 1, 11:07 pm, Hasan Turksoy hturk...@gmail.com wrote: Hi all, i want to change my main html page to a jsp page - to get some request parameters to process in gwt code. But its not working... Below is a simple test code which is working on tomcat but not working on shell... script language=javascript % String str = TEST; % var s=%=str%; alert(s); /script Anybody knows the reason? Thanks and regards, Hasan... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Login security question
akutz: ** YOU COULDNT BE MORE WRONG ** SSL protects against many things, but it does *NOT* protect against XSRF. Which is -exactly- what you're opening yourself up to if you only rely on the cookie automatically sent by the browser in the form of the 'Cookie' header - which is the mechanism that tomcat et al generally use for session management. I'll repeat that, one more time: ** SSL IS NO DEFENSE TO XSRF; TOMCAT SESSION MANAGEMENT IS NOT XSRF PROOF. ** It is absolutely imperative that you send the SID along with every request. You aren't doing this to avoid 'people replacing the cookie'. Who replaces cookies? If someone has the power to replace your cookie, but only replace it, there isn't much to worry about, in general. Worst case leak is the paypal credit card harvester scheme (scroll down to the appendix of this post to read more about it), but even then this is a very complex attack: There's no simple way for any web page to set a cookie for another domain. It is easy, of course, if someone has direct access to the machine of the user, _but_, if someone has that access, then all security discussions are moot: He could also install a keylogger. Which you can't protect against at all. So no sense worrying about that case. To put it another way: Akutz - why do you think that reading the cookie from the SID is an 'obvious security flaw'? So, we're back to: Send the SID along with every request. Be aware that this is what happens anyway; how else does tomcat track state, you think? It reads the SID off of the cookie, that the browser sends in *every request*. Tomcat does this *every time* and uses the SID to look up your session (be it a db or other persistent store, or just from memory, that is an irrelevant detail for the security aspect of this discussion). Configuring it to 'share state in a persistent store', or any other setting, doesn't change this. At best, you can configure tomcat to not use cookies and instead use URL rewrites. This won't work in GWT, and is even less secure. I don't want to go into depth as to why that isn't secure, but just consider this: Digg, reddit, tipit, delicious, stumbleupon, and many other bookmarklets and browser bars offer ways to share websites. It has no idea about an SID in the URL; it'll instead happily share them. Resulting in other users of those sites logging in as you. Not to mention your SID showing up in referral logs when you follow links on the idiotic site that uses URL rewriting that lead to other websites. I've held this discussion every month or so on this forum and I'm sick and tired of it. Go do your research, or just search this newsgroup for previous posts. If you want to be pigheaded and do things your own way, you deserve the grief and the pain that's invariably coming to you when someone figures out you aren't XSRF proof. I've been fighting the good fight not so much for your sake, but for your users'. But even I have limits. Do me, and all your users, a favour, and send the session ID in the BODY of EVERY REQUEST, or you Fail At Security. Appendix: The paypal harvester scheme. Paypal's login page used to lack XSRF protection. If you had asked any security expert back then, he or she probably would have mentioned that it makes no sense to protect against XSRF -before- even logging in. After all, the pre-login page is the same for everyone. However, some enterprising soul 'hacked' paypal anyway: They created a link of the form: https://paypal.com/login?username=hackersnamepassword=hackerspass which was then opened in an invisible iframe. The poor user that browsed to the hacker's website (or a website hacked by the hacker) would unwittingly log into paypal as hackersname, invisibly. Nothing would happen though, and that by itself is not dangerous.. UNTIL this user visits paypal.com, intending to make a transaction, or, perhaps, to add a new credit card. *THIS* was what the hackers were after. Every so often someone would go to their paypal page, fail to notice that they weren't logged in as themselves, and add a credit card, THEIR credit card, to hackersname account instead of to their own. This didn't just allow the black hat to transfer money from your credit card to his own account, but it also allowed him to steal the full credit card info, as paypal listed all information back then, under the presumption that its the owner of the credit card that wants to know his own credit card's information. They had a simple bot running that checked every 5 minutes if a new CC had been added, and if so, grabbed the relevant information and removed the card from the paypal account. That issue has been fixed, but it is a rare example of a hack that involves XSRFing the login page itself. If you need to protect against it, send a random token to the user's page in cookie form along with the login form, and make sure it is parrotted back to you, in BOTH the body *AND* the header of the login. This means you need javascript, but, then,
Re: Login security question
So I'm not to reply to you but you do engage in a long missive to explain your situation and then ask for help? Let me know how calling people an ass before asking for help works out for you. On Dec 30, 12:47 am, akutz sak...@gmail.com wrote: I appreciate the response, but you're a complete and total ass. I do not know why people let you get away with acting the way you do. We come here for help, not abuse. We're not idiots, we simply don't understand the subject as well as you do. I've seen your other responses, and you are just as rude. While I am sure that you understand this subject better than anyone else, I would appreciate it if you could refrain from responding to this thread until you learn to display tact and manners. That said... I understand how the server identifies which state bag to relate to a client request (JSESSIONID). What I don't understand is how sending a unique ID along with each RPC request does anything since I am not looking up the session state on the server side, it is automatically provided to me via the HttpServletRequest.getSession() method. If I was looking up values in a database based on the client identifier (for authorization let's say), then I realize that it is better to have the application provide the unique ID instead of relying on the client sending the Tomcat server a JSESSIONID. However, I am ONLY using the session for a state bag. The authentication is happening against another server (for example's sake, say LDAP) and I simply get back an authentication token that I persist into the session. For example, let's say there are 4 GWT-RPC methods: 1) boolean login(String username, String password) 2) boolean logout() 3) boolean isLoggedIn() 4) String getFoo() Now, imagine this series of events: 1) The GWT app loads and isLoggedIn() is called to see if the user already has logged into the back-end server via the GWT Impl class. The Impl class checks to see if there is a valid logon token for the user stored in a Session attribute. If there is it returns true; otherwise false. 2) If the user is not logged in they are presented with a login view. The user enters their username and password and the login(String, String) method is invoked. The Impl class calls the LDAP server and the login succeeds, returning a token. The token is stored in the session and a true value is returned to the client. 3) The user then clicks on a button that invokes the getFoo() method which cause the Impl class to use the previously obtained logon token to invoke an operation on an LDAP-enabled service somewhere. 4) The user logs out, and the session is invalidated. Now, in this scenario the user isn't logging into the GWT app so much as they are validating credentials with a third-party authentication mechanism. If they are valid then they can move beyond the login view to some meaningful controls. If their session expires then they are forced to login again. This may happen if they close their browser, or however it happens. I am not concerned with persisting the login beyond the length of their browser session because the lifetime of the login token that the LDAP (not really LDAP in my case) server returns isn't infinite, and even if I let the user stay logged in for 2 weeks according to the web app, they would still need to re- authenticate to the LDAP server after X amount of time (likely to be much shorter than the interval that I would set). That is the scenario I am faced with. I am HAPPY to send along the unique client ID each time that could be returned by the login operation, however, what would I do with it? Basically check to make sure that the ID that subsequent requests send me is the same that was originally generated? If this is case then I can see Reinier's point and am happy to implement said feature. I am just trying to understand the situation. Thank you! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: Making a request to another page
RequestBuilder makes an AJAX call. It doesn't redirect the browser. use setLocation for that, which I think is in the standard GWT API someplace. Otherwise, use some JSNI to do: window.location.href = http://whatever.com/;; if you really meant to make an AJAX call: Yes, you need a callback. You don't have to put anything in it, though. On Dec 22, 11:06 pm, Suri sviswanad...@gmail.com wrote: Hi all, I'm trying to do the following. As part of how I'm modeling my exception handling, I decided that to be consistent with my current Struts model - I would redirect the user to a generic error page in case of an error. Thus, any exceptions in the GWT should also be handled in the same manner. I figured I could just use the RequestBuilder to send my request along. However, I see that the problem here is that it requires a RequestCallback instance in order to make the request. I probably could fake a callback and let it pass, but I wanted to check with the experts to see if there was a more appropriate way to do this. Does this mean that there is no way of making a request/call to the server without providing a callback? Thanks Suri --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. 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: What am I misunderstanding about the event model?
1) You can use something called 'anonymous inner classes'. google it.
They look something like this:
someButton.addClickListener(new ClickListener() { public void onClick
() {
/* code that runs when someButton is clicked goes here. */
}});
This does produce 2 class files, but this is an utterly irrelevant
implementation detail of the JVM. GWT doesn't even give a crap about
these; it generates JS files directly from the java sources, and the
class files are there only because some IDEs don't work well without
them, and the hosted mode debug tool needs them. Whining about this is
pointless, as its a fact of life of the JVM platform. It also seems a
bit pointless to whine about: Who cares about how many class files are
involved?
2) the web doesn't work with generic 'I want every event ever' style
event catching. You can only sign up for a few events. The ones GWT
has nice abstractions for (all the 'specific' listeners) are the ones
that work reliably and similarly on all supported GWT platforms. There
are a select few event types that are non-standard and aren't
generally available on GWT's widget (the most famous one is probably
doubleclick), and there are a few widgets that don't have an
addXListener for something they do support. EventListener and the
Event class are LOW LEVEL SUPPORT classes - you do not use them in
normal code, only in library code. They are used by GWT's own widgets.
You should use them if you're building your own widget from scratch
(but not when you're compositing them from other GWT widgets). If you
aren't doing that, then you shouldn't be using them. They aren't drop
in replacements to do 'catch all events' code.
In general, you should not use the stuff that isn't supported. If,
however, you must, then you can. This involves messing with the DOM.*
utility methods and generally means you need to know what you're
doing. Remember, GWT is a *LEAKY* abstraction. Using GWT when you
don't have a clue about how html, the dom, and javascript work, is not
a supported use case. GWT is useful because it makes web development
easier. That's a long way of saying: Tough cookies, go learn how the
web works, then come back.
Once you've figured that all out, this is how you can hack GWT:
1. use DOM/Widget.sinkEvents to set up a listener on the DOM side for
the specific event you're interested in.
2. Use the EventListener raw interface / override onEvent from the
Widget class and check the Event code to know what just happened. The
'Event' class is a javascript/java interactivity tool, just like the
JavaScriptObject class. You are NOT supposed to do anything with it in
java code; you pass it into JSNI methods and then the JSNI code does
something with it. This interface also provides you with a few useful
parameters, such as the sending object.
3. As a general rule, using one event listener to handle events coming
from multiple objects, is bad design. Use as many anonymous inner
classes as you need, instead. This is only acceptable in certain
situations that involve arrays of 100% similar widgets (such as a blog
engine where you have a list of checkbox widgets, one for each tag,
where the tags on any given post are completely dynamic - for example,
set by the user when he wrote the post. Then it can make sense to have
just one event listener for the whole lot, and check which widget
caused the event to respond appropriately).
4. When using anonymous inner classes for event handlers with more
than one method (such as the keyboard listener which has keyUp,
keyDown, keyPress), but you only care about one of those, use the
XListenerAdapter class instead of the interface. Make sure you use the
@Override annotation on the one method you're overriding when you do
this, or bad things happen when you typo the method name
(specifically: nothing happens at all, which means you have to go on a
bug hunting spree to figure out why nothing is happening. It can take
a while to realize you typoed the method name. With an @Override in
place, the compiler will refuse to compile your code right from the
get go. Much easier to find that mistake now.)
Example situation: I have a cancel button and an ok button.
DO THIS:
cancelButton.addClickListener(new ClickListener() { public void onClick
(Widget w) {
dialog.close();
Messaging.flashWarning(Sign-up cancelled.);
}});
okButton.addClickListener(new ClickListener() { public void onClick
(Widget w) {
okButton.setEnabled(false);
dialog.showSpinner();
sendRegistrationRequest(emailBox.getText(), new
RegistrationRequestHandler() {
@Override public void requestAccepted() {
dialog.close();
Messaging.showMessage(Congratulations! You've signed up
to our service!);
}
@Override public void requestDenied(String reason) {
dialog.close();
Messaging.showError(Whoops - we can't process your sign
up request, because + reason);
}
});
}});
do NOT do:
myClickListener =
Re: GWT 1.5.3 with Eclipse
You don't really need a plugin. The getting started guide (it's right there on the main GWT website) shows how to run the projectCreator/applicationCreator scripts. These already generate the .project file that eclipse needs (make sure you follow the 'I have eclipse' part of the getting started guide). What would you envision a plugin to even do? On Dec 9, 10:01 pm, Patrick Goovaerts [EMAIL PROTECTED] wrote: BTW, i am using Eclipse v3.2.2 2008/12/9 pgoovaerts [EMAIL PROTECTED] Hi, After a session at Devoxx, Antwerp, i got interested in GWT. I'm using Eclipse-IDE for java and web programming, so i'm searching for an eclipse-plug-in to test GWT with this current IDE. Who can give my a link for such? Any good starting points? Manuals / turorials? thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Size of code download in GWT
To be a bit more verbose about it: Exactly one individual ASKDJALSDJASLKDJSAD.js.html file is downloaded in its entirety by any given user visiting your site. Which one gets downloaded depends on the browser used, and if you're using localization or other generator splits, that too. It certainly won't download individual -parts- of a js file. Each individual js file is carefully stripped of everything that isn't needed. If your js files are 500k, you're doing something wrong. - style pretty or -style detailed will certainly do it. Adding some known very heavy libraries such as one of the many varieties of ext- gwt or gwt-ext (I forgot which one) will also add to the size, but 500k is exceptional. Remember that you can (and should) configure your webserver to zip these up. On Dec 7, 12:07 am, funwithgwt [EMAIL PROTECTED] wrote: Hi, I have a question about the size of downloaded code for GWT applications. I notice that the Modlename.js file that is included in the ModuleName.html file is quite small. I am looking at 5K approx. However the generated html files, which are generated on a per browser basis are quite large -on the order of 500K. I am assuming that only the portion of code in 500K file that is required based on the dependencies starting from Module.java file are downloaded from server. For example if the there are 1000 widgets in the generated code but only one widget is instantiated then only the code for that one widget is downloaded to the browser. Is this correct? -FunWithGWT --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Discussion on security-for-gwt-applications
krona: If you are getting the session ID from the cookie, your web service is still vulnerable to XSRF (wikipedia it). Make GWT send the session ID in the body of requests (such as a parameter to GWT-RPC or stuff it in the JSON you're sending to your PHP). On Dec 4, 1:24 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The approach I'm taking, and I'm hoping it is a good one, is to divide the operations on the server cleanly in to read and write. I'm using php on the server and GWT on the client. The client cannot execute any write operation on the server without a unique Session ID, the only way that the client can get a Session ID is by providing correct log in credentials to the server. Once the client has provided correct login credentials the server creates a Session ID and binds it to an IP address. Any write requests coming in to the server will not be honoured if they do not come from the IP address/Session ID combination that the server understands as being 'safe'. Obviously once write access is granted on the server all string data is stripped/ escaped as appropriate. The philosophy is that the server will never send anything to the client that could be intepreted as anything but plain text. I cannot protect against fishing, but then this is only for a cat club website! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Your opinion sought: Jetty or Tomcat?
Not Ken Shabby: Imagine here your -exact- reply, except swap 'tomcat' (note: it's not an acronym, you don't need to capitalize it. Jetty isn't either) with 'jetty' and vice versa. In other words, your argument is only relevant for you. It makes for an excellent reason to switch for those running the end result on jetty. On Nov 26, 3:55 am, Not Ken Shabby [EMAIL PROTECTED] wrote: I will be using TOMCAT as the target server for the foreseeable future. My concern with switching to JETTY within the development environment is that bugs / issues with the interaction of GWT and TOMCAT may not be seen / address as quickly as they might otherwise be. There may also be some psychological / political effect --- oh, GWT is something that works with Jetty, it used to work with Tomcat but they changed it On Oct 20, 10:46 am, John [EMAIL PROTECTED] wrote: Manuel Carrasco wrote:The most annoying issue with GWT is performance in development mode. I mean, compiling, startng hosted mode and running GWT Unit tests. So any action that improves these is welcome. So my vote if for jetty +1 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
quentin: URLs aren't designed to be protected. At all. Cookies aren't exactly locked away in Fort Knox on your harddrive, but browsers at least have the good sense to understand that they shouldn't send arbitrary pieces in the cookiefile to arbitrary servers. Not so for URLs. To wit: 1) 'aggregator' websites such as Digg, Reddit, stumbleupon, and even just del.ico.us or just mailing a link around because you want to show 'something cool' to a friend, always grab the entire URL and spill this out to the world at large. This is obviously really really bad. One 'fix' is to make these sessions time out fast, but this annoys users, and having your account accessible by anyone following a story on an aggregator for 'just half an hour' is still pretty bad. 2) Referral. When browsing to another domain, your browser will add a Referrer: header which contains the URL that the user came from. This is handy for analysis flow on your own site, and to figure out where people are coming from when visiting your site. If you run a website and you're using google analytics or some other traffic analyser, you may have noticed a '% of traffic from google' indicator. This thing works by checking how many incoming requests have a Referrer: (www\.)? google\.com.* - this referrer system does not discriminate and will happily toss over the ENTIRE URL, which would include your session. I could -easily- make a webserver that'll check if it looks like there's a session ID in a URL, then report it and the website via chat to me, so I can quickly see if I can log in as this person. 3) Bookmarks. web-based bookmarking was covered in #1, but even a local bookmark is relatively bad, because in general bookmarks are far easier to leak to another person than your cookiefile. sharing bookmarks is actively encouraged by many browsers. No user except a real geek would cut his URL down to eliminate the session ID from it (and even more pathetic, if this geek does do that, using the bookmark is near useless because he'll have to log in again. d'oh). 4) It's a giant sore thumb that both says: Geez, I'm ugly, and: OMG, I have absolutely zip squat idea about web security, so whatever info you give to me, consider it yelled from the rooftops. Boy, my webmaster is a thick headed clot. Most other security leaks aren't nearly as visible, which isn't much comfort, but it does count for a little that this one is so obvious. Just look at the address bar. NB: Yes, yes, the official java servlet spec, even the very latest version, officially declares that URL rewriting is amongst the strategies. Sun evidently considers background compatibility with dangerous code more important than security, which, to say it mildly, / annoys/ me just a tad. On Dec 2, 2:21 pm, quentin [EMAIL PROTECTED] wrote: Reiner, Thanks for the reply. Call me naive/ignorant/stupid/whatever but what are the security risks associated with using ;jsessionid? The reason i ask is because GWT cookie support in safari 4 appears completely broken. (It's actually not GWT's fault. in safari 4, the js statement document.cookie = doesn't seem to work). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Your plan to use an interface extending RemoteService to be consistent
in how you read the sessionID out of the request body and not the
cookie sounds excellent.
SSL does not protect against XSRF by itself. However, it does turn
moot the general issue of having session IDs hit the line. The long
talks about attempting to hide the sessionID by hiding the cookie and
using some whacky crypto scheme are experimental craziness without
SSL, and if you're already using SSL, utterly pointless.
In other words, SSL + your XSRF protection plan = security sweetness.
I run my website that way. (tipit.to)
You could hack in some sort of exception-over-JSON protocol, where you
build a custom class in between the HttpServlet and YourOwnServlets
class inheritance, which makes it easier to output JSON (for example
by allowing you to output a hashmap), as well as wrapping the actual
doGet()/doPost() calls (by overriding service()) in try/catch, and
having a standard way of conveying the exception to the client. e.g:
{ error: true, errorType: java.io.FileNotFoundException,
errorMessage: /foo/bar }
Going JSON with your API isn't really better than using GWT-RPC
unless you have very specific needs (such as: I'll be accessing my
servlets from something other than GWT as well), so only do this if
you really really need it.
One last security note on tossing exceptions across the line
automatically: That can be a security leak, in the sense that you tend
not to think about the exception when considering the type of data
that a servlet will send out onto the internet. It's rare that useful
info leaks out that way, but it does happen, and often it helps a
cracker determine fruitful attacks. Unless you run a very security-
sensitive app, I would accept the risk, but think about what info
might be available in an exception, and if its really bad, do
something about it. Example:
You need to read the password to the database off of disk, because you
use some horribly outdated database layer. The filename contains the
name of the db server and db name. This is info a cracker didn't have
before, but if that file doesn't exist or can't be read, now he does,
because FileNotFoundException, IIRC, has as message the filename. So,
the cracker sees /dbPasswords/localhost_1234_myServerDB or some such.
More info than he had. If he's found a different app on your site that
can be coerced into returning any given file anywhere on the system,
but not directory listings, he now has his puzzle complete and knows
the location of your db and the password. Again - don't abandon the
idea of swapping exceptions across the wire, just try to be aware that
it happens and that exceptions thrown by your servlet is essentially
public info.
NB: Bedankt :)
On Dec 1, 9:58 am, Patrick Ratelband [EMAIL PROTECTED] wrote:
Hey everyone,
thanks for the big replies. There is a lot of info in there, but I
still have some questions.
I understand that Mallory will always be a problem and that Eve might
be one, however, defeating them is not part of what I want to do. The
only thing I want to guard against are XSRF attacks. I understand that
to prevent these I must put some identifier (let's use sessionID) and
store it in a cookie to survive browser reload and I must pass it
inside my GWT RPC request and not rely on the cookie in the header.
So far so good, this is exactly what I am implementing right now.
Gregor suggested that I create an interface that would extend the
RemoteService, this is along the lines of what I was thinking as it
would make the whole XSRF system transparent to the programmer, I have
also understood from the later posts between you and Reinier that the
visibility of the actual sessionID on the wire is not a problem here,
so is there any substantial objection to use this approach?
Shawn suggested I use his implementation with JSON, however, I have
read the readme and the fact that exceptions are not thrown over the
line is too big of a drawback for me as I use these in the app
already.
Reiner, you really seem to know your stuff, thank you for your
clarifying posts and your enjoyable cynical take on the world. I think
I understand what you are saying.
Last question, would using SSL (which will be implemented on the
server within a week or two) also prevent XSRF? From what I have read,
I cannot draw a conclusion one way or the other.
With thanks, Patrick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: GWT with non-Java backend
Yes, tons of people have used GWT on the front and something that isn't java on the back-end. You can transfer data using JSON, XML (but, really, don't. XML is stupid as a wire protocol), or whatever binary format you think is useful. The only caveat (and this applies to using GWT-RPC as well), is that GWT apps can only receive data 'whole'. You can not stream. So, if you were thinking of pumping 50 megabytes worth of data down to the client, you need to split it up into pieces and have the GWT client app request and process each piece one at a time. The general idea of processing 50 MB worth of stuff in a javascript app also doesn't sound like a good idea in general, as javascript isn't really fast enough to do it unless you're on WebKit+SquirrelFish, Google Chrome+V8, or Firefox 3.1 beta + tracemonkey. (Those are all beta or small market share browsers with amazing javascript interpreters). On Dec 1, 10:01 am, Peter Ondruška [EMAIL PROTECTED] wrote: I use GWT with Google App Engine backend with RequestBuilder. 2008/12/1, ajay jetti [EMAIL PROTECTED]: This should help i think http://angel.hurtado.googlepages.com/tutorialgwt2 yours Ajay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
You're asking me if some Reinier Approved algorithm would meet with my approval? Uh, yes. I have a question for you, though: Does a gregor approved method of shooting a puppy meet with your approval? If not, can you explain why? On Nov 28, 9:02 pm, gregor [EMAIL PROTECTED] wrote: @Reinier gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. Suppose I replaced: sessionID = someSessionIDCookieGrabbingMethod(); with: sessionID = someReinierApprovedEncryptionAlgorithm(); would this meet with your approval? If not can you explain why? regards gregor It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband [EMAIL PROTECTED] wrote: Hey everyone, I have been working a while now on properly defending my GWT app against Cross Site Request Forgery (XRSF) with a minimal change in the code of the application itself. My idea has been to create a new RPC call that will be the same from the programmers points of view as the normal, but which will add some value (a sessionID for instance) to the list of supplied parameters just before the call is send. Then, on the server side, the programmer would extend the SecureRemoteServiceSevlet (SRSS) instead of the normal one. This secure version will simply remove the extra paramater, check it's validity and only execute the requested method if the authentication succeeds. So far I have been able to subclass the RemoteServiceServlet (RSS) into the SRSS. It overrides the processCall(String payload) method to implement the verification (in my case the last argument, but that can easily be changed), thus working exactly the same as the normal RSS without any change needed in the code other than changing the extend. The problem is that I really do not understand where I might add the code to modify the sending of the request client side. I have studied the RPC diagrams and almost everything I could find on the group concerning RPC, but I still do not understand what I need to change or override to create a custom RPC call. I have thought about making a subclass of the ServiceDefTarget so that the calling URL could be modified, but this is an interface and not a class, so is not going to work. Does anyone have any idea's on this? Patrick PS: If I succeed at making something useful, I will create a package and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Timer In Gwt
Not A Problem - Just Add The Timer Behaviour To Your Custom Subclass
Of Label. For Example, You Could Add A SetVisible Method To This Label
Subclass That Also Includes a Milliseconds Parameter (The Time To
Display The Message). All Your Method Does Is Call Super.SetVisible
(X), And Then Start The Timer. The Timer Code You Pasted Looks Fine,
So You Can Just Use That. If You Are Concerned That Thirty Timers Are
Too Much To Handle, I Wouldn't Worry Too Much. However, If Practical
Testing Really Reveals That Is A Problem, You Can Do This. I'd Still
Go The Route Of A Custom Class, though. Basically, Create A Mapping Of
Event Times (The Time In Milliseconds When The Message Should
Disappear) And Store This In A TreeMap. Then, Set Up A Single Timer
That Waits Until The First Time In The Mapping Is 'Up'. The Code Sort
Of Writes Itself From There. If A New Timer Is Added, You Should Check
If It's Up Sooner Than The First Thing In The Map, And If So, Cancel
And Restart The Timer With The New Shorter Time.
NB: It Is More Common In The English Language To Capitalize The Word
I And The First Letter In Every Sentence. Your Style Of Capitalizing
At Random Is Not So Much Of A Standard. I Admit, It Looks Hilarious
Though. Ta!
On Nov 29, 7:48 am, jagadesh [EMAIL PROTECTED] wrote:
Hi Guys,
I am Working On A Screen Where i Need to Display some Error Message
and Some Success Messages.What i did is i created my own widget of
some Label type . when ever i need to show a message i would set the
text to label and display it on the top of the screen much like gmail.
the issue i added a timer for the label so that it disappears
automatically after some time.
i have written the code like this,
Timer t = new Timer() {
public void run() {
header.setErrorMessage(Error
Message);
header.setVisible(true);
setWidget(0, 1, header);
}
};
t.schedule(500);
header is my label type of element. i was displaying some 30 types of
different message. so my timer code has increased a lot . can any one
suggest me how to use a single timer class for all.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: TextArea cannot be resolved to a type
Go through the GWT Getting started guide. You've screwed up your installation somehow, or you're not using the right command line. It's not a matter of code, it's just that some tool in the chain can't find the TextArea class code. For the rest - really, this is a forum, not a university. Just go through the getting started guide and learn GWT. You should also have a look at the javadoc for all GWT classes. For example, the TextArea javadoc has a getText() method, and a setText() method. You can not use URL in GWT. The GWT Documentation (Notice a pattern?) has a nice listing of which classes are supported. java.net.* is not in it. This isn't because the GWT team is lazy, it's simply because javascript simply can't do this, so there's no way the GWT compiler can compile that code for you. If the URL you want to read in is from the same server that served the webpage (the EXACT same server. Same protocol, same exact server name, same port), then you can use RequestBuilder (A GWT class. Look it up in the .. (drum roll please!) documentation!) which is capable of downloading the contents. On the web, you can pretty much only ever download everything in one go, there are no streams, just complete data. If you need to process a couple megabytes on the client... you're out of luck, then. Maybe your server can download the big data in chunks and pass it to the client in a flurry of requests instead. On Nov 29, 7:50 am, moe374 [EMAIL PROTECTED] wrote: Hello. I have just begun learning java (about 2 months ago) and am now trying to develop a couple applications for the web using java and the GWT. I am having some difficulty and hoping someone can help me out. My first problem I am having is I am getting this error message TextArea cannot be resolved to a type when I am trying to create a text area. I get the error message twice, and for the same line in my code which is TextArea ta = new TextArea(); Is there a line (or multiple lines) of code I have to implement before I can implement the TextArea object? Also, I need to allow the user to paste some information into this text box and allow me to store that information in a variable, and then do something with the information, and then output some information to the user (even in the same text box is fine). Can some one please help me get started on this? Finally, I was wondering if the GWT supports reading the HTML file of a URL, which would normally be done by something like this: URL results = new URL(http://www.some-url.com;); BufferedReader in2 = new BufferedReader( new InputStreamReader( results.openStream())); String inputLine = in2.readLine(); Thank you very much. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
Replies inline... On Nov 29, 2:08 pm, gregor [EMAIL PROTECTED] wrote: a) Don't send sessionID as cookies - deliberately configure app server to stop it using cookies for tracking sessionIDs This does mean that sessions don't survive the user reloading the page or closing his browser. This is generally speaking not acceptable to most GWT developers. My point was: They are in the cookie -anyway-, so worrying about the session ID hitting the wire, while fruitful and of some concern, is outside of the norm. 99% of all websites take this risk. The Sheep Routine (be like everybody else) is *NOT* in general a wise path to take in regards to security, but unless there are a non- trivial amount of non-insane security gurus preaching doom and gloom, you should be okay. In this case, I'm saying that sharing session IDs is generally okay, and I'm not aware of any security gurus preaching doom and gloom. So, session IDs hitting the wire is no (practically solvable) problem. If you have a very sensitive app, you should obviously use SSL, and you may want to invalidate them once in a while. Many sites do this (google invalidates biweekly (fair enough), paypal invalidates every time you breathe to the general annoyance of all, ebay every 24h (similarly ridiculous), et cetera). General Rule: Security does not trump user friendliness. Don't invalidate sessions unless you have a pressing reason to do so. If a tiny, rarely used part of your app is sensitive but the rest isn't, use time-sensitive servlets: Give servlets the time since the session was created and allow a servlet to say that this is no good, which should lead to a login screen. b) Don't send sessionID as request parameters - or am I wrong here DO send sessionID as parameters. ALWAYS do this. The cookie is there ONLY for the benefit of the client GWT code so that it can fish the sessionID out of the cookie in order to survive reloads and browser quits. If we could tell the browser to stop sending the cookie along, we would. In practice you shouldn't do this (you CAN take down the cookie and add a window closing hook to put it back, but the window closing hook is more of a prayer / hopeful suggestion than something that gets reliably called). You could more reasonably take out the cookie right before you send a request and put it back right after if you're sufficiently paranoid, but there's no serious benefit here unless you also go for the other outside-of-the-norm maneuvre of cryptographically hiding the session ID. So, let me make this perfectly clear: Attempting to keep the session ID out of the hands of people listening on the line is technically possible but something you SHOULD NOT DO unless you are a security expert and/or in the mood to tinker and experiment. It's not something anybody really does right now, though being the first is nice. If you are a tinkerer / experimenter / guru. Not if you're just trying to get on with your project. The reason you, as a server, look ONLY at the session ID transfered in the BODY of the incoming request (instead of the cookie, which would also be there), is to avoid XSRF (a.k.a. seasurf a.k.a. Cross Site Request Forgery, see wikipedia) attacks. In order to properly protect against XSRF, you should also NOT use x-www-form-encoded as your wire format. Use JSON (add session ID as a key/value pair in the top-level map), GWT-RPC (Add it as a field in the class you are passing along the wire), or some non-x-www-form-encoded-fakable format of your own devices, if you have very weird requirements or some such. Don't use XML, obviously - as wire format it's ridiculous. It would be good if you are consistent with this mechanism (for JSON, always call it 'sessionID' and always transfer dictionaries, not arrays, and for GWT-RPC, make everything extend something simple that contains just a getSessionId() method). This way, you can write one generic session ID checker that passes the session ID onwards to your server framework's session system. That's a lot better than forcing every individual servlet to manually fish out the session ID and chat to the session system. It helps ensure that you don't forget to use this alternative session mechanism if you can somehow tell your framework's session system to not mess with cookies (neither write nor read them). Instead, your login servlet will manually generate one (e.g. HttpSession.newSession), send it along to your GWT code, and then your GWT code uses the GWT Cookie class to set the cookie. Similarly, it will retrieve the cookie via GWT's Cookies class, and send that right away to the server if its there (in its entrypoint). This comes back to the reason you're using the cookie in the first place: To let the session survive browser shutdowns and reloads. It's not a reliable authentication mechanism due to XSRF. c) You could send sessionID as part of a, say, RPC payload object, but it should be hashed or otherwise encrypted otherwise it's still easily read by a
Re: Problems adding a Digg This link
I doubt digg's js thingie is written by an intelligent developer (digg has a track record of sorts). There IS a way to write such widget scripts so they work in all situations, including the peculiar way GWT builds webpages, but not many web widgets work this way. So, assuming for a moment that won't fly, here's the easiest alternative: Use com.google.gwt.user.ui.HTML. On Nov 29, 1:48 pm, Charlie Collins [EMAIL PROTECTED] wrote: Can't you just add the script element to your host page, the same way you would in HTML? That is to say, don't try to recreate the script element in Java and have GWT insert it, just put it on the host page (the same place you put the gwt script tag, etc). On Nov 27, 11:33 pm, mayop100 [EMAIL PROTECTED] wrote: I'm trying to add a Digg This link to my gwt website. If my website were just an html page, all I would need to do is include this line in my HTML: script src=http://digg.com/tools/diggthis.js; type=text/ javascript/script I've tried adding a new element to the page with DOM.createElement (script), but it ends up replacing the entire contents of the page with my digg link. I've also tried a JSNI solution, but with no success. It seems to me there should be an easy solution for this... anyone? Thanks - -Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: TextArea cannot be resolved to a type
Do it on the server. If that is no option, write desktop software (something you install and that doesn't run in a browser at all). You can also use web based platforms that allow signing / trusting, such as applets, but be aware that users will need to hand the keys to the kingdom to your app, and in general, the vomitous stream of text filled with red, screamy words, and dangerous looking symbols in the popup that shows up when you ask for this trust makes users have a mild heart infarction, and blame you for it. On Nov 29, 9:06 pm, moe374 [EMAIL PROTECTED] wrote: Thank you for your response. I did actually find the getText() and setText() methods before writting this, I was just a little unsure as to how to implement them. the URL feature is an essential element of the program I am trying to write. Since I can't do this with GWT and I can't do this using an applet either (applets can only connect to the same server as well i believe), I think I have hit a dead end. What other options do I have? What do you recommend I use to create this type of web application? Thanks for your help. On Nov 29, 11:40 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: Go through the GWT Getting started guide. You've screwed up your installation somehow, or you're not using the right command line. It's not a matter of code, it's just that some tool in the chain can't find the TextArea class code. For the rest - really, this is a forum, not a university. Just go through the getting started guide and learn GWT. You should also have a look at the javadoc for all GWT classes. For example, the TextArea javadoc has a getText() method, and a setText() method. You can not use URL in GWT. The GWT Documentation (Notice a pattern?) has a nice listing of which classes are supported. java.net.* is not in it. This isn't because the GWT team is lazy, it's simply because javascript simply can't do this, so there's no way the GWT compiler can compile that code for you. If the URL you want to read in is from the same server that served the webpage (the EXACT same server. Same protocol, same exact server name, same port), then you can use RequestBuilder (A GWT class. Look it up in the .. (drum roll please!) documentation!) which is capable of downloading the contents. On the web, you can pretty much only ever download everything in one go, there are no streams, just complete data. If you need to process a couple megabytes on the client... you're out of luck, then. Maybe your server can download the big data in chunks and pass it to the client in a flurry of requests instead. On Nov 29, 7:50 am, moe374 [EMAIL PROTECTED] wrote: Hello. I have just begun learning java (about 2 months ago) and am now trying to develop a couple applications for the web using java and the GWT. I am having some difficulty and hoping someone can help me out. My first problem I am having is I am getting this error message TextArea cannot be resolved to a type when I am trying to create a text area. I get the error message twice, and for the same line in my code which is TextArea ta = new TextArea(); Is there a line (or multiple lines) of code I have to implement before I can implement the TextArea object? Also, I need to allow the user to paste some information into this text box and allow me to store that information in a variable, and then do something with the information, and then output some information to the user (even in the same text box is fine). Can some one please help me get started on this? Finally, I was wondering if the GWT supports reading the HTML file of a URL, which would normally be done by something like this: URL results = new URL(http://www.some-url.com;); BufferedReader in2 = new BufferedReader( new InputStreamReader( results.openStream())); String inputLine = in2.readLine(); Thank you very much.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: SecureRemoteService and Servlet. The battle against XSRF.
The solution is simple: Rewrite the session management part of your web stack so that it doesn't look at the cookie (it should completely ignore the cookie - it is there only to let the session survive when the user reloads the page / closes their browser), instead lifting the session out of the parameters. You don't need to remove it, really - any framework or servlet engine that gives unfettered access to the parameters also gives unfettered access to the cookies, so there's no point. gregor: What do you mean 'bad idea because the session ID would be visible on the wire'? All session IDs are visible on the wire, unless you set up a scheme where the client javascript does some hashing or encryption. It's been floated as an idea many times on this forum, and it is certainly feasible, but its very much outside of the norm. Virtually nobody on the entire web is doing this today. There are a number of issues I don't really want to get into. Suffice to say: Yes, doable. Yes, very cool. No, not standard or required by any stretch of the imagination. Such a scheme would still be significantly less secure than SSL, because it won't hold up to a man in the middle attack (the man in the middle will just modify your GWT code to send the password to his secret server in nigerussomania. On Nov 28, 12:52 pm, Patrick Ratelband [EMAIL PROTECTED] wrote: Hey everyone, I have been working a while now on properly defending my GWT app against Cross Site Request Forgery (XRSF) with a minimal change in the code of the application itself. My idea has been to create a new RPC call that will be the same from the programmers points of view as the normal, but which will add some value (a sessionID for instance) to the list of supplied parameters just before the call is send. Then, on the server side, the programmer would extend the SecureRemoteServiceSevlet (SRSS) instead of the normal one. This secure version will simply remove the extra paramater, check it's validity and only execute the requested method if the authentication succeeds. So far I have been able to subclass the RemoteServiceServlet (RSS) into the SRSS. It overrides the processCall(String payload) method to implement the verification (in my case the last argument, but that can easily be changed), thus working exactly the same as the normal RSS without any change needed in the code other than changing the extend. The problem is that I really do not understand where I might add the code to modify the sending of the request client side. I have studied the RPC diagrams and almost everything I could find on the group concerning RPC, but I still do not understand what I need to change or override to create a custom RPC call. I have thought about making a subclass of the ServiceDefTarget so that the calling URL could be modified, but this is an interface and not a class, so is not going to work. Does anyone have any idea's on this? Patrick PS: If I succeed at making something useful, I will create a package and a tutorial to share my knowledge. No need to reinvent the wheel. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: New to the GWT
It has no user interface other than the command line. If you're on windows, run 'cmd', that'll get you a command line. In order to learn how to use it - google for some tutorials, it's not too difficult. Most programming tools work off of the command line, so its time well spent. On Nov 25, 10:44 pm, Jorge Muralles [EMAIL PROTECTED] wrote: Hi there, how are you, is this the only way to run the createproject application. Once is running, does it have a user interface? I really do not know how to run it from the coomand promtp. how would I gt to it? Sincerely yours; Jorge Muralles 401-849-5323 401-855-1335 www.locopro.com --- On Tue, 11/25/08, Isaac Truett [EMAIL PROTECTED] wrote: From: Isaac Truett [EMAIL PROTECTED] Subject: Re: New to the GWT To: Google-Web-Toolkit@googlegroups.com Date: Tuesday, November 25, 2008, 2:32 PM Open a command prompt and run it from there. On Tue, Nov 25, 2008 at 1:31 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I just downloaded the GWT, I understand that there is no installation file, but I click on the application creator and it starts up a command screen that goes away. How do i start up the application creator? What am I doin wrong? Thanks Jorge --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How do I get browser autocomplete on a login form
I'm just going off of what I've heard elsewhere.
On Nov 23, 10:57 am, tieTYT [EMAIL PROTECTED] wrote:
I've already tried doing this and it doesn't solve the problem at
hand. IE(s) don't seem to ask you to save the username/password when
you do this. Here are the things I've tried with your idea:
Wrapping these inputs in a form in the HTML
Wrapping these inputs in a form in AJAX
Submitting the HTML/AJAX form when the login button is clicked.
Adding a submit button to the form in HTML
Clicking that submit button via js when the form is submitted
Lots of other things I can't really remember (I've been trying for a
few days) and all sorts of combination's of what's mentioned above.
IE(s) are very particular about when they allow autocomplete. The
only way I've been able to do it is when my form has no dom
manipulation whatsoever. If you've actually gotten this to work,
could you show a full example?
Thanks a lot,
Dan
On Nov 22, 1:07 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote:
You can wrap existing elements in GWT 1.5:
new TextBox(DOM.getElementById(loginUsernameBox));
new PasswordTextBox(DOM.getElementById(loginPasswordBox));
then you can do the usual GWT shenanigans and add whatever listener
you like.
If you don't have GWT 1.5 Then, obviously, shame on you.
On Nov 21, 11:27 pm, tieTYT [EMAIL PROTECTED] wrote:
I saw a faq that made the same recommendation. The problem is, I need
to capture the onKeyUp and onClick events of the input's inside the
form. I could only figure out how to bind to the form OR bind to
its children. I couldn't figure out how to bind to both. GWT threw a
variety of exceptions over the issue. Could you show me some sample
code that does this?
On Nov 21, 2:18 pm, Reinier Zwitserloot [EMAIL PROTECTED] wrote:
These features generally only work if the textbox and passwordbox are
in the initial HTML.
In GWT's normal modus operandi, the boxes are added dynamically by the
javascript.
The solution is to have the boxes in the static HTML file that
bootstraps GWT (normally auto-generated by the applicationCreator), in
a div that makes them hidden (use visibility and not display: none).
From GWT, re-visibilize them if you need em. That should work.
On Nov 21, 11:04 pm, tieTYT [EMAIL PROTECTED] wrote:
Hello,
I'm trying to replicate browserautocompleteon a login form. For
example, every time you go to the login page, I'd like the username
and password field to be prepopulated with the username/password you
used last. Not only that, but if you clear the username and double
click the field, the list of previous usernames you've entered should
show up. If you select one, the password field gets populated with
that.
Fortunately, with normal HTML the browser handles all of this for
you. But I can't figure out how to get this to work on IE6/7 on an
GWT app. In these browsers, it doesn't offer to save the usernames.
I'll provide the code I have so far (this works in FF):
public class Sandbox implements EntryPoint, ClickListener,
KeyboardListener {
private Label label;
private FormPanel formPanel;
/**
* This is the entry point method.
*/
public void onModuleLoad() {
formPanel = new FormPanel();
final VerticalPanel basePanel = new VerticalPanel();
formPanel.add(basePanel);
TextBox loginTB = new TextBox();
//without this, FF doesn't know where to place the data
loginTB.setName(name);
basePanel.add(loginTB);
PasswordTextBox passTB = new PasswordTextBox();
//without this, FF doesn't know where to place the data
passTB.setName(password);
basePanel.add(passTB);
Button loginBT = new Button(Submit);
basePanel.add(loginBT);
RootPanel.get(slot1).add(formPanel);
loginTB.addKeyboardListener(this);
passTB.addKeyboardListener(this);
loginBT.addClickListener(this);
label = new Label();
RootPanel.get(slot2).add(label);
}
public void onClick(Widget sender) {
//Without this, FF doesn't offer to remember the data
formPanel.submit();
if (label.getText().equals()) {
SandboxService.App.getInstance().getMessage(Hello,
World!, new MyAsyncCallback(label));
} else
label.setText();
}
public void onKeyDown(Widget sender, char keyCode, int modifiers)
{
}
public void onKeyPress(Widget sender, char keyCode, int modifiers)
{
}
public void onKeyUp(Widget sender, char keyCode, int modifiers) {
// If enter is pressed lets forward the request to onClick
Re: Your opinion sought: Jetty or Tomcat?
To summarize Alex' complaint: Your plans will add hardship to my work. Please don't do that. That's a fair point, but I believe this point was understand from the start. What size app do you have, if the 4 second bootup time for tomcat doesn't bother you? It must be enormous. Hosted mode doesn't compile anything, it interprets, that's why it starts up so much faster than actually compiling it. OOPHM is still being worked on actively by the core GWT team, if the chatter in gwt-contributors is any indicator. It hasn't been abandoned. On Nov 22, 12:54 am, Alex Epshteyn [EMAIL PROTECTED] wrote: Bruce, I might be too late in replying to this thread, but I want to phrase my objections to what you've proposed. A. Regarding Jetty: I think this will be a waste of time for everyone. Switching underlying servers is a no value added task (using Six Sigma vocabulary). 1). Many developers are using -noserver so for them this will make no difference. 2). Many other developers have customized the embedded Tomcat to suit our needs (I spent hours customizing it so that I don't have to run with -noserver). It will take hours to re-adjust again if you switch underlying servers. 3). Why? What's the benefit of switching to Jetty? Tomcat startup is like 5 seconds tops, which accounts for maybe 10% of the hosted mode startup time. You should speed up the compiler if you want to speed up hosted mode. I don't understand what Jetty has to offer here. I'd be happy if you proved me wrong here, though. B. Regarding the output directory structure: I feel the same way about this as I do about Jetty. I think this is a waste of time - no real value added to GWT. Most of us will have to re-tweak our ant build configs which is always a waste of time. C. Final thoughts I'm really looking forward to seeing something of substance in the roadmap for 1.6, because between what you've written here and what's marked with 1_6_RC on the issue tracker, I see nothing of any value except minor bug fixes. Here are the top 3 features that I think would add real value to GWT: 1). A way to get meaningful Java line number from Javascript exceptions thrown in a deployed production app (compiled with -style OBF) 2). Out-of-process hosted mode (to enable using different browsers in hosted mode). 3). A Declarative UI framework (one was started by Joel W. but seems to have been abandoned). 4). Speed up compilation Java 5 support would have been #1 on this list a year ago. You guys did a great job with GWT 1.5 - it included at least 2 giant leaps (Java 5 and the JSO/DOM framework), and I hope to see another big leap like that on the roadmap instead of features that add little value to GWT, like Tomcat vs. Jetty. In the end, if you decide to go forward with Jetty, I can come to terms with that, but I will need a good reason to upgrade to 1.6, like one of the 4 items on my list. Thanks for your time, Alex On Oct 13, 4:48 pm, Bruce Johnson [EMAIL PROTECTED] wrote: Hi everyone, Hope you're enjoying 1.5. The GWT team has started putting together a 1.6 roadmap, which we'll publish as soon as we have it nailed down. Two of the areas we want to work on for 1.6 are some improvements tohostedmodestartup time and a friendlier output directory structure (something that looks more .war-like). As part of this effort, we've all but decided toswitchthehostedmode embeddedHTTPserverfromTomcattoJetty. Would this break you? (And if so, how mad would you be if we did it anyway?) We figure most people who really care about the web.xml and so on are already using -noserver to have full control over theirserverconfig. Thanks, Bruce --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: load property file from a list of property files
Zujee, that's not how you solve this problem. Make the client download the properties from the server. Basically, have a simple servlet that takes one parameter and returns the appropriate properties, e.g. as a HashMap which you transfer via GWT- RPC. If you don't know what GWT-RPC is, its one of the systems you can use to chat between client and server. There's plenty of documentation available from the main GWT site about how to use it. On Nov 21, 5:34 am, zujee [EMAIL PROTECTED] wrote: Yes.. I want deffered binding.. Bcoz according to each customer comes, we just want to add a property file for that customer. Not to compile the entire application. How can it be possible? Is there any example or sample document available which will help to achive that. pls help On Nov 20, 2:21 pm, Thomas Broyer [EMAIL PROTECTED] wrote: On 20 nov, 07:58, zujee [EMAIL PROTECTED] wrote: Hi, I have a number of property files according to our clients like myapp_compny1_en.propertis,myapp_compny2_en.propertis,...etc..etc.. For each compny , property files contents might vary.. Can some one suggest me in which way i need to achive this... Currently im trying with immutableResourceBundle. Is thats the right approch? is there any thing i need to take when i put name for each property files? How is the company selected? If you package your app for each company and deploy them separately (each company has its own version of the app), then its just a matter of packaging. Otherwise (deferred binding), you might want to write your own generator (inheriting an existing one and adding your own logic to select the appropriate properties file depending on the company for the processed permutation) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How do I get browser autocomplete on a login form
These features generally only work if the textbox and passwordbox are
in the initial HTML.
In GWT's normal modus operandi, the boxes are added dynamically by the
javascript.
The solution is to have the boxes in the static HTML file that
bootstraps GWT (normally auto-generated by the applicationCreator), in
a div that makes them hidden (use visibility and not display: none).
From GWT, re-visibilize them if you need em. That should work.
On Nov 21, 11:04 pm, tieTYT [EMAIL PROTECTED] wrote:
Hello,
I'm trying to replicate browser autocomplete on a login form. For
example, every time you go to the login page, I'd like the username
and password field to be prepopulated with the username/password you
used last. Not only that, but if you clear the username and double
click the field, the list of previous usernames you've entered should
show up. If you select one, the password field gets populated with
that.
Fortunately, with normal HTML the browser handles all of this for
you. But I can't figure out how to get this to work on IE6/7 on an
GWT app. In these browsers, it doesn't offer to save the usernames.
I'll provide the code I have so far (this works in FF):
public class Sandbox implements EntryPoint, ClickListener,
KeyboardListener {
private Label label;
private FormPanel formPanel;
/**
* This is the entry point method.
*/
public void onModuleLoad() {
formPanel = new FormPanel();
final VerticalPanel basePanel = new VerticalPanel();
formPanel.add(basePanel);
TextBox loginTB = new TextBox();
//without this, FF doesn't know where to place the data
loginTB.setName(name);
basePanel.add(loginTB);
PasswordTextBox passTB = new PasswordTextBox();
//without this, FF doesn't know where to place the data
passTB.setName(password);
basePanel.add(passTB);
Button loginBT = new Button(Submit);
basePanel.add(loginBT);
RootPanel.get(slot1).add(formPanel);
loginTB.addKeyboardListener(this);
passTB.addKeyboardListener(this);
loginBT.addClickListener(this);
label = new Label();
RootPanel.get(slot2).add(label);
}
public void onClick(Widget sender) {
//Without this, FF doesn't offer to remember the data
formPanel.submit();
if (label.getText().equals()) {
SandboxService.App.getInstance().getMessage(Hello,
World!, new MyAsyncCallback(label));
} else
label.setText();
}
public void onKeyDown(Widget sender, char keyCode, int modifiers)
{
}
public void onKeyPress(Widget sender, char keyCode, int modifiers)
{
}
public void onKeyUp(Widget sender, char keyCode, int modifiers) {
// If enter is pressed lets forward the request to onClick
method
if (keyCode == '\r') {
onClick(sender);
}
}
static class MyAsyncCallback implements AsyncCallback {
public void onSuccess(Object object) {
DOM.setInnerHTML(label.getElement(), (String) object);
}
public void onFailure(Throwable throwable) {
label.setText(Failed to receive answer from server!);
}
Label label;
public MyAsyncCallback(Label label) {
this.label = label;
}
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: java.net.InetAddress
You CAN make a browser go to another server, but there's no way to receive information from it. Its possible there's some hacky way to figure something out, but this is just doomed to failure, because email servers don't have to be webservers, and vice versa. For example, there are still loads of servers that don't direct FOOBAR.com port 80 to the webserver, only www.FOOBAR.com. And yet email address are virtually always [EMAIL PROTECTED] and not [EMAIL PROTECTED] Thus, the answer is not only - no, you can't do this, but the answer is: No, you're Doing It Wrong. You don't validate email addresses by checking if there's a webserver running on it. If you must check it... you send an email to it, with a link in it. On Nov 20, 6:21 am, Ian Petersen [EMAIL PROTECTED] wrote: The same origin policy (SOP) prohibits all network traffic except traffic back to your own website so the kind of validation you're trying to do can only be done on the server. Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: JSON
Sure.
public native String getDirectorOfMovie(String movie) /*-{
return this.movies[movie].director;
}-*/;
As I said, you need to know javascript to do this. Go learn the
basics, you'll figure this out in no time.
On Nov 19, 11:12 pm, Jose Santa Elena [EMAIL PROTECTED] wrote:
Thanks again Reinier.
I've being tryign with by this way, but my problem is accessing associative
arrays. There is one way to do that?!
On Wed, Nov 19, 2008 at 6:43 PM, Reinier Zwitserloot [EMAIL PROTECTED]wrote:
Yeah, I kinda sorta did with my new proposed JSON library.
But you can go even faster.
Create a java class which mimics essentially exactly the structure of
your JSON - with getter methods for everything relevant.
Give this class NO fields whatsoever, just getters. Then let it extend
JavaScriptObject.
Make each getter native and grab the data straight from the JSON
structure. e.g. if you have:
{'name' = foobar, 'age'=10}
you could make:
public final class Name extends JavaScriptObject {
public native String getName() /*-{ return this.name; }-*/;
public native int getAge() /*-{ return this.age; }-*/;
}
This is exactly as fast as it can possibly be in javascript, as this
whole hullabaloo gets eliminated entirely by the compiler. A call to
name.getName() will be translated directly to 'name.name' in the
javascript.
You can get arbitrarily funky with your JSON, but you'll need to write
all your accessors in javascript, so you'll need to know a thing or
two about javascript to build yoru accessor class. Good luck.
Make extends JavaScriptObject.
On Nov 19, 6:51 pm, Jose Santa Elena [EMAIL PROTECTED] wrote:
Hi all...
Has someone addressed the performance problem on parsing large JSON
files?
I created one Wrapper to do a latter bind...
public class JSONMap implements Map {
private JSONObject wrappedJSONObject;
public JSONMap(JSONObject jsonObject) {
if (jsonObject == null) {
throw new WrongUseException(Invalid JSONObject);}
this.wrappedJSONObject = jsonObject;}
public void clear() {
throw new UnsupportedOperationException();}
public boolean containsKey(Object key) {
throw new UnsupportedOperationException();
}
public boolean containsValue(Object value) {
throw new UnsupportedOperationException();
}
public Set entrySet() {
throw new UnsupportedOperationException();}
protected String getKey(Object key) {
String keyValue;
if (key instanceof String) {
keyValue = (String)key;} else {
keyValue = key.toString();
}
return keyValue;
}
public Object get(Object key) {
JSONArray jsonArray;
JSONBoolean jsonbBoolean;
JSONNumber jsonNumber;
JSONObject jsonObject;
JSONString jsonString;
JSONValue jsonValue = wrappedJSONObject.get(getKey(key));
if ((jsonArray = jsonValue.isArray()) != null) {
return new JSONList(jsonArray);} else if ((jsonbBoolean =
jsonValue.isBoolean()) != null) {
return new Boolean(jsonbBoolean.booleanValue());} else if ((jsonNumber =
jsonValue.isNumber()) != null) {
return new Double(jsonNumber.doubleValue());} else if ((jsonObject =
jsonValue.isObject()) != null) {
return new JSONMap(jsonObject);} else if ((jsonString =
jsonValue.isString()) != null) {
return jsonString.stringValue();} else {
return null;
}
}
public JSONMap getMap(String key) {
return new JSONMap(wrappedJSONObject.get(key).isObject());}
public String getString(String key) {
return wrappedJSONObject.get(key).isString().stringValue();}
public Double getDouble(String key) {
return new Double(wrappedJSONObject.get(key).isNumber().doubleValue());}
public JSONList getList(String key) {
return new JSONList(wrappedJSONObject.get(key).isArray());
}
public boolean isEmpty() {
return wrappedJSONObject.size() == 0;
}
public Set keySet() {
return wrappedJSONObject.keySet();
}
public Object put(Object arg0, Object arg1) {
throw new UnsupportedOperationException();
}
public void putAll(Map arg0) {
throw new UnsupportedOperationException();
}
public Object remove(Object key) {
throw new UnsupportedOperationException();
}
public int size() {
return wrappedJSONObject.size();
}
public Collection values() {
throw new UnsupportedOperationException();
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: authentication in GWT
walden, please, pretty pretty please, stop confusing GWT users with your very bad advice. You just restated your earlier arguments without taking into consideration anything I wrote. Sticking your fingers in your ears and singing loudly doesn't really work, and I request the common courtesy that you stop doing that. Thanks. Just in case you are clueless to the ways of HTTP standardization, I'll get this out the way up front: RFC Stands for Request for Comments, and a large stack of RFCs form the standards of the internet. This includes HTTP, which is where HTTP Basic Authentication is defined. Thus, anytime I say 'RFC', you can replace that with 'the official standard', and it'll be semantically correct, even though technically, HTTP does not really have a universally recognized official spec that is called 'the official spec'. The RFC is as close as you can get. And now, with no further ado... replies inline. On Nov 20, 3:40 pm, walden [EMAIL PROTECTED] wrote: In answer to the criticisms of HTTP authentication: 1. The generalilzations above about user experience don't click with my experience with users. My experience is different. Perhaps more pointedly, name me 1 public web app that uses HTTP-Basic. When experiences conflict, go with what is most common. 2. It's not that HTTP Auth is better than what you can build with cookies. I don't know if it is or it isn't. I do know. It's worse. And I've explained, in lengthy detail, why HTTP Auth sucks. I even mentioned that the authors of HTTP Auth (or as close as you can get - the RFC) strongly suggest you don't actually use it for authentication, just for identification. Please reread the thread for the complete treatment about why HTTP Auth is technically pretty bad. It's about not reinventing a stack that's already there and functioning. There is no stack. Specifically, HTTP Auth doesn't let you keep your login across browser restarts, which is something that every single webapp that has any sort of success actually has, and is something users obviously want. Even the security sensitive apps do this, just so they can at least customize the things you see pre-login with non- sensitive personal data, such as your username. (why the heck are you using the security-broken HTTP Auth, again, according to the RFC itself, if security is important enough to force re-logging in that often anyway?) Thus, you have to 'implement' a session ID anyway. You're still not spilling the beans on how you log out with HTTP Auth, which is quite interesting, because the RFC specifically says that you CANNOT log out. Going with what another poster kindly explained, you're actually invalidating the session, which means you've 'reinvented the wheel' according to your own definition just the same. I also find it insulting to say that the standard session management- via-cookies principle is 'reinventing the wheel' somehow. If every webapp this decade has been using it, then calling that 'reinventing the wheel' is frankly facetious. You can't toss out terms with a negative connotation when they don't apply. A decade ago HTTP auth was not well implemented across browsers, but that was a decade ago. Actually, absolutely nothing changed in the way browsers implement HTTP Basic Auth. The reason nothing changed is twofold: 1) HTTP Basic Auth was so extremely broken that it isn't fixable. There' a new standard (HTTP Digest Auth), but it sees absolutely zero use. I have no idea which browsers, if any even implement it. It doesn't matter, because 2) Everyone and their uncle was using forms instead of http basic auth to relay user/pass to the server, so by the time either the slowish RFC process, or the even slower browser evolution process in the 6 years after IE6 was released, caught up with the notion that HTTP Basic Auth totally sucked - it was no longer relevant. 3. Digest Authentication does not send plain text, and is as easy to setup as Basic. it isn't even remotely as simple to set up. No one uses this. Browser support dubious. The last paragraph, Reinier, the one that starts There really is no problem here..., I'm not getting your meaning. That wasn't in reply to you, that was in reply to the original post. He was worried that a servlet wouldn't check the authentication and in that way leak data. I merely mentioned that this can't usually even happen, because there is no data to leak without first knowing who requested the information. And the only way to do that is to check the session data, which implies the session data was deemed valid, security-wise. If his setup does not work that way, he's doing something very weird, and he's doing it very wrong. I also mentioned there are some exceptions to the rule - for example, non-personalized data which is nevertheless only meant for people with login credentials. This only applies if the app isn't a public webapp that anyone can create an account for, obviously. HTTP Auth is just
Re: Using GWT to draw line
+ on the gwt-diagrams suggestion. Doing line drawings or drag and drop in a webbrowser are both rather difficult (but doable) proposals that come with a boatload of caveats, idiosyncrasies, and other curious perversions. You are far better off using a well tested library written by an expert than trying to roll your own. On Nov 18, 4:24 pm, mok sara [EMAIL PROTECTED] wrote: Hello, You can find it out in this link.http://code.google.com/p/gwt-diagrams/ Hope that will help you. Regards, Mok On Tue, Nov 18, 2008 at 10:58 PM, Pete Kay [EMAIL PROTECTED] wrote: Hi, I wouls like to use GWT to make a very simple drag and drop flow chart object. Is it possible? The part that I can't figure out is how to use GWT to create a LINE that I can use to connect two rectangular images. Any suggestion will be greatly appreciated. Thanks, Pete --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: JSON
Yeah, I kinda sorta did with my new proposed JSON library.
But you can go even faster.
Create a java class which mimics essentially exactly the structure of
your JSON - with getter methods for everything relevant.
Give this class NO fields whatsoever, just getters. Then let it extend
JavaScriptObject.
Make each getter native and grab the data straight from the JSON
structure. e.g. if you have:
{'name' = foobar, 'age'=10}
you could make:
public final class Name extends JavaScriptObject {
public native String getName() /*-{ return this.name; }-*/;
public native int getAge() /*-{ return this.age; }-*/;
}
This is exactly as fast as it can possibly be in javascript, as this
whole hullabaloo gets eliminated entirely by the compiler. A call to
name.getName() will be translated directly to 'name.name' in the
javascript.
You can get arbitrarily funky with your JSON, but you'll need to write
all your accessors in javascript, so you'll need to know a thing or
two about javascript to build yoru accessor class. Good luck.
Make extends JavaScriptObject.
On Nov 19, 6:51 pm, Jose Santa Elena [EMAIL PROTECTED] wrote:
Hi all...
Has someone addressed the performance problem on parsing large JSON files?
I created one Wrapper to do a latter bind...
public class JSONMap implements Map {
private JSONObject wrappedJSONObject;
public JSONMap(JSONObject jsonObject) {
if (jsonObject == null) {
throw new WrongUseException(Invalid JSONObject);}
this.wrappedJSONObject = jsonObject;}
public void clear() {
throw new UnsupportedOperationException();}
public boolean containsKey(Object key) {
throw new UnsupportedOperationException();
}
public boolean containsValue(Object value) {
throw new UnsupportedOperationException();
}
public Set entrySet() {
throw new UnsupportedOperationException();}
protected String getKey(Object key) {
String keyValue;
if (key instanceof String) {
keyValue = (String)key;} else {
keyValue = key.toString();
}
return keyValue;
}
public Object get(Object key) {
JSONArray jsonArray;
JSONBoolean jsonbBoolean;
JSONNumber jsonNumber;
JSONObject jsonObject;
JSONString jsonString;
JSONValue jsonValue = wrappedJSONObject.get(getKey(key));
if ((jsonArray = jsonValue.isArray()) != null) {
return new JSONList(jsonArray);} else if ((jsonbBoolean =
jsonValue.isBoolean()) != null) {
return new Boolean(jsonbBoolean.booleanValue());} else if ((jsonNumber =
jsonValue.isNumber()) != null) {
return new Double(jsonNumber.doubleValue());} else if ((jsonObject =
jsonValue.isObject()) != null) {
return new JSONMap(jsonObject);} else if ((jsonString = jsonValue.isString())
!= null) {
return jsonString.stringValue();} else {
return null;
}
}
public JSONMap getMap(String key) {
return new JSONMap(wrappedJSONObject.get(key).isObject());}
public String getString(String key) {
return wrappedJSONObject.get(key).isString().stringValue();}
public Double getDouble(String key) {
return new Double(wrappedJSONObject.get(key).isNumber().doubleValue());}
public JSONList getList(String key) {
return new JSONList(wrappedJSONObject.get(key).isArray());
}
public boolean isEmpty() {
return wrappedJSONObject.size() == 0;
}
public Set keySet() {
return wrappedJSONObject.keySet();
}
public Object put(Object arg0, Object arg1) {
throw new UnsupportedOperationException();
}
public void putAll(Map arg0) {
throw new UnsupportedOperationException();
}
public Object remove(Object key) {
throw new UnsupportedOperationException();
}
public int size() {
return wrappedJSONObject.size();
}
public Collection values() {
throw new UnsupportedOperationException();
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Can't figure saving out.
Loki, like the compiler error says:
make them final.
e.g.:
final textArea text = new TextArea();
final Button save = new Button(whatever);
On Nov 18, 5:29 am, Loki [EMAIL PROTECTED] wrote:
Perhaps my brain is just fried-- the longer I code, the less sense
coding seems to make to me, so maybe I just need a break, but I'll
list my problem just in case I'm wrong.
Okay, so I have a setup where a user enters data into a bunch of
various textboxes, and there's a button labeled Save waiting for the
user at the end of it all. However, with the way the button is set
up--
Button save = new Button(Save,
new ClickListener() {
public void onClick(Widget sender) {
}
});
And then later,
panel.add(save);
it seems to me that I can't really put anything in the onClick()
method that will actually allow me to access all those various
textboxes I have elsewhere without making, like, EVERY textbox a
global variable, which is just nonsense.
SUMMARY: wut do i do guyz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Body Background disappear
Try using CSS:
body {
background-image: url(images/backgrnd.jpg);
}
On Nov 16, 11:41 am, Michi_de [EMAIL PROTECTED] wrote:
Hi!
I've a strange bug when using the GWT:
my body background=images/backgrnd.jpg
seems not to work anymore!
I see the background image for a second and when the GWT Script is
loaded it just disappear!
o_O?
Whats wrong with my code? Or is it a GWT Bug?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: authentication in GWT
HTTP Authentication? Don't make me laugh - it's ridiculous design, and more importantly, users don't get it. at all. They think your app is broken and try to browse away (only they can't, that authentication dialog box is modal). There's also no better security there than what you can do with cookies, as it boils down to sending the username and password in plain text to the server. I know, I know, its base64 encoded so it doesn't look like it on first glance, but -any- sniffer - anywhere- can see that its a Authorization header and de-base64 it. It's the same thing from a security perspective. There really is no problem here. If your developer can serve the content without knowing the user's session information (which presupposes that the session ID was checked and validated in the first place), then its rather unlikely to be relevant,security wise. In corporate settings there are some exceptions (downloading static files / global uncustomized information which is still not meant for outside eyes), but not too many. Also, walden: You're a bit of a jackass. If someone makes a comment that asserts a widely perceived truth (you can't log out with HTTP basic authentication), don't answer with But I can! Ha! Neener neener neener!. Explain how instead of being so dense. Thanks, on behalf of everyone else. On Nov 18, 7:29 pm, walden [EMAIL PROTECTED] wrote: Olivier, * session expiration, because the GWT RPC will fail soon (401). * forbiden because the GWT RPC will fail soon (403). * activation of widget when authority is granted. I'm scratching my head wondering what those mean. In my app, RPC's are secure and they don't fail. As for widget activation, you're talking authorization, and I don't see any difference among the proposals on that. * logout (not possible with HTTP Basic). And yet I have it. Go figure. Walden --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: authentication in GWT
@Rick:
Ahh, that makes sense. However, its not logging out of HTTP Basic. Its
just invalidating a session ID. I also doubt that it'll work properly
if done in one browser session - the browser will keep re-sending the
Authorization header regardless of your invalidated session. The
browser doesn't know anything about the way sessions are stored on
your computer. You can perhaps do some hackery by generating a random
realm everytime but now you're hacking an inferior system - what's the
point?
For 'proof', see RFC2616. It specifically does not mention anything
about keeping the username/password entered around, however it is
quite specific about suggesting (which in RFC speak, is a strong
encouragement to do it) that you save this information, as a
webbrowser, because the browser may assume that all URLs 'below' the
URL that needed authentication also need authentication, and thus the
browser may pre-emptively send the header.
Most browsers don't store this information beyond a single session,
but in this day and age, people can go for many weeks without ever
closing their browser, so that is of little comfort. There's also no
rule that states that browsers aren't allowed to do it. The RFC, as I
mentioned, is deliberately low on detail, which is really bad for
security purposes. The followup RFC (2617) is also fairly specific
about never using HTTP-Basic to do serious authentication and strongly
suggests that you generate passwords for the user. Riiight - that's
going to go over real well in today's world.
Let's recap:
- Its such a weird and rarely used device that your average user will
flip out, and
- It is far more insecure than cookies and has dubious logout
capability.
- The official web standard urges you not to use it for what we're
talking about.
Ah, yes. That's why nobody uses it.
On Nov 18, 10:28 pm, Rick [EMAIL PROTECTED] wrote:
To logout from HTTP authentication use:
public void logout() {
HttpSession session = this.getThreadLocalRequest().getSession();
session.invalidate();
}
You can do this in your ServiceImpl class.
I kind of agree with Reinier, but might have used language that was
less strong.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Tor: Awesome.
Uh, wrong newsgroup. My bad. On Oct 26, 6:33 pm, Reinier Zwitserloot [EMAIL PROTECTED] wrote: Just downloaded the beta python for netbeans. -awesome-. One thing that is seriously borked in this install, though: whitespace. Backspacing to go back to previous levels is all screwed up and tends to jump in steps of 4, right in the middle of indents. So, if for example I have a method indented 2 spaces, and inside it, a for loop, with the body of the for loop indented 6, and I hit backspace, it'll first go back to 4 spaces in, which is not an indent at all, and another backspace will then go to 0, which isn't where I wanted to be either. Manually lining up spaces is getting old. Am I doing something wrong, or should I just take the plunge and swap to the nightly/hg trunk? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Basic login security/session management question
inline responses... On Oct 1, 4:22 am, nogridbag [EMAIL PROTECTED] wrote: 1) If we can't trust cookies, what's the point of using cookies at all? As a storage space to save the session ID between sessions. Users do sometimes close their web browsers, or at least the tab with your page on it. I know. Those bastards! Incidentally, those same blasted users get very miffed if they have to enter a password every time they revisit your page. 2) That leads me to my next question, how should the sessionID be stored in the client? Do I just store it in some class, let's say User.java as a String or whatnot in plain text? Yes. 3) Then, in any RPC request that needs the user to be logged in, I pass this session ID along with the rest of the objects? Well, usually you pass one object, which might contain a number of other objects, -and- the sessionID. Your server, in turn, looks only at that and completely ignores the cookie. In fact, if you want to get real fancy, you kill the cookie, and add a window closing hook, and re- add it, but because that hook doesn't get called with certainty when your page is going away, that's a bad idea. You could get fancy and kill the cookie, send your request AND start a 5 millisecond timer, and re-add it. I haven't tried this myself yet, seemed overkill given that my server is 100% SSL. 4) How does the server then take this sessionId and authenticate it? Depends on your framework. Don't let your framework run its own session id management; they stuff it and look at the cookie, or they add it to all generated URLs. (if they do this without you telling it to in a setting, get rid of this framework right now. It's a blatent security issue that's been known for years. If they haven't fixed that, I really wouldn't trust them with anything else). If your framework doesn't support manual session ID management, then you'll have to manually manage the entire session. Annoying. Consider mailing your framework authors to add the ability to manually manage just the session tokens. (e.g: two methods - one with: generate me a new session ID please, and another with: Here's a session ID. Fetch me the session object. Or, if session querying is built in, a method with: Here's a session ID. Consider that this request has been sent with this session ID from here on out). 5) Finally, is there any situation where you would store the username/ pass on the client in order to authenticate each RPC call? If so, what would be the security implications of this? They wouldn't be very good. Don't do this. First of all, its very inflexible: Without both SSL and a requirement to re-login everytime you revisit the page, you've got a serious security issue, for example. Maybe you want your webapp to work that way, but what are you going to do if your client says: Well, turns out we do want logins to persist, at least for a little while. Or even: We want the ability to open a link in a new tab (that's a new 'session' after all!) - then you need to hack in a session system. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Tor: Awesome.
Just downloaded the beta python for netbeans. -awesome-. One thing that is seriously borked in this install, though: whitespace. Backspacing to go back to previous levels is all screwed up and tends to jump in steps of 4, right in the middle of indents. So, if for example I have a method indented 2 spaces, and inside it, a for loop, with the body of the for loop indented 6, and I hit backspace, it'll first go back to 4 spaces in, which is not an indent at all, and another backspace will then go to 0, which isn't where I wanted to be either. Manually lining up spaces is getting old. Am I doing something wrong, or should I just take the plunge and swap to the nightly/hg trunk? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: possible emulation bug: sinh
I'd create an issue and toss that one-liner in there too, after
checking that there isn't one already there, of course.
google lucky gwt issue tracker.
On Sep 25, 11:27 am, Thomas Broyer [EMAIL PROTECTED] wrote:
On 25 sep, 06:53, rjcarr [EMAIL PROTECTED] wrote:
Looking at GWT Math.java, I see:
public static native double sinh(double x) /*-{
return Math.sinh(x);
}-*/;
But according to the mozilla javascript reference (which I'm sure is
the same for any reference you find):
http://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_...
There is no sinh() function available. So that makes me pretty sure
this is an emulation bug.
Right, it should probably read (with a potential loss in precision):
public static double sinh(double x) {
return (exp(x) - exp(-x)) / 2;
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: question about Constants and Messages
You can create the singleton inside the interface. e.g:
public class MyImages implemens AbstractImageStoreThingie {
AbstractImagePrototype closeButton();
... more AIPs.
public static MyImages STORE =
(MyImages)GWT.create(MyImages.class);
}
Then you can just go:
MyImages.STORE.closeButton();
Looks a lot better than endless GWT.create() calls, regardless of
whether GWT optimizes it or not.
On Sep 24, 10:31 pm, Alex Rice [EMAIL PROTECTED] wrote:
I have subclassed Constants and Messages and am finding the facility
to very useful. I have started to put code like this in many of my
classes:
public void useMyConstants() {
MyConstants myConstants = (MyConstants)
GWT.create(MyConstants.class);
Window.alert(myConstants.helloWorld());
}
Would it make sense to wrap MyConstants and MyMessages in a Java
singleton, or is GWT already optimizing this behind the scenes? I am
just imagining *lots* of strings getting re-created every time the
above type of code is called.
Thanks in advance
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: iPhone toggle switch implementation
That's not how stylesheets work.
You have two options:
A) change the style of a given element. e.g. use add/removeStyleName,
to change the styling info of your widget. for example:
myWidget.setStyleName(someStyleClassThatIsAlwaysApplied);
if ( toggledOn ) {
myWidget.removeStyleName(toggledOn);
myWidget.addStyleName(toggledOff);
} else { /* you can guess what goes here */ }
B) Have two widgets, one for each 'toggle', and alternatively hide/
show them. Use the widget's .setVisibility(bool) method to do it.
On Sep 20, 12:10 am, Bear [EMAIL PROTECTED] wrote:
Can anyone help me implement iPhone style toogleswitch in GWT? I've
been trying to use the iUi CSS style sheets and I have a question on
how I would implement this in GWT?
fieldset
div class=row
labelShuffle/label
div class=toggle onclick= toggled=truespan
class=thumb/spanspan class=toggleOnON/spanspan
class=toggleOffOFF/span/div
/div
fieldset
I assume I can use a HorizontalPanel and setStyleName(row) and then
add a button with style toggle but how do I send the toggled=true
info to the CSS and add the 3 span elements?
Thanks in advance
Bear
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: GWT 1.5 Now Available
It's not, there's a known problem with the google download link, for some people it just screws up. I suggest you try to download it from another network. On Sep 18, 12:52 pm, vector [EMAIL PROTECTED] wrote: Hi. I have tried to download latest version for windows. The file is corrupted. I performed it from several places, but result is always the same. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: questions on Login Security FAQ
I don't know jasypt, so I can't make guarantees (actually, nobody can, but you know what I mean). However, there are two good signs: 1) The API is specifically for password checking. This is a lot better than using a generic hasher and doing the salting yourself. The authors of the library had password hashing in mind when they wrote it. If they did their job right, it should be good for password hashing. 2) The API call is checkPassword(thePassword, theHash). This is the 'right' form of such a library. Contrast to e.g. hash(thePassword).equals(theHashFromTheDB), which is the -wrong- form (because there's no salt in that mix at all), or even hash(saltFromDB +thePassword).equals(hashFromDB), which is probably okay, but requires more acts on behalf of the library user, including generating a cryptographically secure salt somehow. So, that very shallow review says: It's all good. But no guarantees on the jasypt author's security chops. On Sep 19, 12:27 pm, Ed [EMAIL PROTECTED] wrote: Like Rob mentioned, always interesting to read Reinier's post :)... B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously. Don't think about it, you failed the test. Use tools written by the experts) - is a better take on a technique called 'salt hashing', I noticed you mentioned this a few times before in this forum. The tool I use:http://www.jasypt.org/. I hope this is written by experts as well :( -- Ed --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: questions on Login Security FAQ
Answers inline... On Sep 19, 3:12 pm, JasonG [EMAIL PROTECTED] wrote: First of all, I don't understand your (A) response. I said you don't need to worry so much about passing session IDs since the app server will pretty much handle that for you... and your response seems to just reiterate what I said - but you stated it in a manner as though you were disagreeing with me. I don't get it. From a security point of view, which is what this thread is about, who does the sessionid passing is mostly immaterial. It should also be noted that the first servlet engine for tomcat started the boneheaded 'sessionid in the URL' security fart, so the userbase size of a j2ee container is no guarantee that the security is sorted out properly. Secondly, BCrypt is not mentioned in the original author's post at all, nor does it seem to be mentioned in the linked guide to security. Huh? (j)BCrypt is the first link mentioned on the LoginSecurityFAQ. I didn't just add that - that's been there since I posted the second draft, a long long time ago. It wasn't mentioned in the original author's post, which is exactly why *I* mentioned it. BCrypt is a fantastic idea. You should be using it when storing passwords in a database. I was not intending to write an all encompassing guide here but perhaps I should have been a little more clear. I said in addition to what others have said and regardless of which hash algorithm. Put those two together and this was meant to be taken as: it doesn't hurt to concatenate the username+password+some-other- string on hashed passwords stored in the DB, regardless of algorithm. No - you don't get it, evidently. 1) You -cant- query the database for HASH(username+password), because if that worked, you by definition have really bad saltless hashing. So what's the point, then? Why store the username as well? You're just making it harder to rename usernames (bad), and... 2) You risk collisions. Assuming that the idea is that this username +password combo is somehow a unique key, collisions can happen, and that's no good. But mostly: 3) my advice is: Use BCrypt. Your advice is: hash on username+password instead of just password, which is much worse than listening to me. Your point is basically: If you forget to listen to any (good) advice, then listen to MY advice. This makes no sense; the premise was already: Programmer did not listen to ANY advice. We've got three options here: A) Programmer doesn't listen to advice. Okay. We can chat here until the end of days, but he's not listening. Shame, but, we can't stop him. B) Programmer listens to the only advice that mattered: He uses BCrypt. Peachy. Your advice is now irrelevant and in fact slightly bad: He just lost the ability to rename his username and needs the username in his check routine which clutters his parameter lists. C) Programmer wanted to listen to advice but the chatter is starting to confuse him, and he turns into #A: He stops reading and just goes his own way, most likely doing it very wrong. This is important, as java tends to suffer a lot form this principle: Don't overwhelm people with 15 answers. Just give the best answer, and if that particular answer doesn't fit the asker's needs, let him get back to you about that. Don't throw half a book at him, especially if most of the advice in it is pretty much irrelevant or useless. That's another very good reason why you shouldn't mention your username+password hashing scheme. It doesn't add anything useful to the discussion: Either the user is doing his salt/hashing correctly, and your scheme doesn't add anything, or he's not doing it correctly, and your scheme adds very very little. Why? Because if you happen to be using a weak algorithm or even a strong one for which a weakness is later discovered, you are better off Just to set you straight on this one: If BCrypt's salt/hash concept is somehow broken, then a username+password hash is equally or even worse broken; BCrypt already uses different source material for the same passwords by different users. This is like screwing a highschool locker padlock on a $10,000 dollar safe door. If someone is going to get access to the safe's contents, you can be certain the padlock didn't stop the criminal for even a second. He either bypassed the lock entirely, or he got the code from someone, or he actually can pick locks; and if he can pick a safe, he can open that padlock in an instant. In the mean time, the padlock, which has added absolutely no value to your security setup, IS annoying you everytime you want access to the safe. Hence, just get rid of the bloody thing, it's making it harder for you in operation, and its making it harder for a security analyst because it obscures the true protection measures with irrelevancy. A time could come when BCrypt was as well. Again, your scheme adds nothing. Stop confusing people with fearmongering talk about BCrypt someday failing. DES never failed; it's just
Re: questions on Login Security FAQ
JasonG: Thanks for being a nice example of the cluelessness of your
average programmer. You've got it all, totally, 100% backwards. Don't
feel too insulted, you're like almost everyone else out there.
However, you should most definitely stop handing out security advice.
Seriously.
A) J2EE doesn't magically work without session keys. It just handles
them for you; they are still stuck in a cookie someplace. HTTP is
stateless. A session is by necessity involved.
B) BCrypt (and you should use BCrypt, or you Fail Security. Seriously.
Don't think about it, you failed the test. Use tools written by the
experts) - is a better take on a technique called 'salt hashing',
invented a few decades ago. With salt hashing, two people with the
same password do not have the same hash in the database. The fact that
you don't even know the principle of salt hashing means you're a few
decades behind the times.
C) You don't check HASH(username+password), because BCrypting 'abc123'
and BCrypting 'abc123' again does NOT result in the same hash value!
That's the whole point. You BCrypt('abc123') exactly once, and then
later, you get the hash from the db and ask BCrypt to verify that
'abc123' was used to generate that hash. Even if you somehow solved
this problem (by removing the salting from the equation which is very
stupid), then there's still the birthday paradox (wikipedia that) to
ensure that there are actual serious odds of a collision. In case of a
collision, some random user will log in as someone else, or if you add
a unique constraint, some user will someday pick/change his password
and get a persistent server error. Big whoops.
On Sep 18, 3:48 pm, JasonG [EMAIL PROTECTED] wrote:
Hi Cresteb,
I have a couple of things to add to what others have said.
1 - I presume all of the session talk in this thread is in regards to
non-Java languages for the server-side. If you are using a J2EE
application on the back end you don't need to worry so much about
passing session IDs since the app server will pretty much handle that
for you once authentication has been established. In fact, you are
encouraged not to.
2 - When generating a password hash to store in a DB, regardless of
what hash algorithm is used I will typically hash the (username
+password) and place that in the password field. This offers a couple
of advantages. a) you get a single ticket by which a user can be
looked up if both values are known. b) if your data gets compromised,
even the passwords of users who stupidly use the same common password
(i.e. password, secret, etc...) won't show up the same in the
database. To make it even better you can add another element to the
mix (secret+username+password) so that the same username+password in
different applications shows up differently in the database.
On Aug 19, 10:11 pm, cresteb [EMAIL PROTECTED] wrote:
Hello!
I have some basic questions on the Register + Login + Keep session
alive process described on the Login Security FAQ.
I know this is a little bit offtopic, but it would be really helpful
for me and other newbies if anyone can clarify some issues.
This is how I see the process with some questions attached, please
correct it where necessary!
Register:
1) Send username and password from client to server.
Q: I guess all the sites make this step over https so anyone can sniff
the password, right?
2) Store in the DB the username and the hash of the password.
Login:
1) Send username and password from client to server (again over SSL).
2) Calculate the pasword's hash and look for a register in the DB that
contains that username and hash combination.
3) Return a session ID from server to client.
Q: Is this also done through https? If not, can't it be this session
id intercepted and used later to make a query as if you were other
user?
During the session:
1) For every request from the client, include the session id, so the
server knows which user is sending the request and it is able to check
if the session is still active.
Q: Is secure enough just sending the session ID in order to identify
the user?
Q: The same as above...should it be sent through https?
2) Check if the session ID is valid or not. If its valid, send the
response with the data of the associated user.
Q: Is it also recommended to send a new session ID on each request so
we increase the security?
Please, feel free to suggest me any document related with this topic.
Thanks is advance!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: questions on Login Security FAQ
We need to invent a TCP/IP compatible cluestick on the double! On Sep 18, 6:36 pm, Ian Petersen [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 11:31 AM, Rob Coops [EMAIL PROTECTED] wrote: Always fun to read a Reinier comment to pretty much anyone. Seriously Reinier though you usualy are quite correct with your facts and knowledge you might try to leave the baseball bat on the filed and not bash someonce head in for a change. I would not be surprized if people are scared to post here for they fear the wrath of the ever present Reinier. I don't know--Reinier was away from this group for a while and I wasn't the only one that missed him enough to say so publicly. I've even experienced the pointy end of Reinier's missives and lived to tell the tale. I think he's a valuable contributor and security is, as you mention below, one of those subjects that needs tough love. On the other hand I am still looking forward to the day when fingers will automaticaly be broken every time a developer codes a well known and described security flaw into their application. Indeed. A small tasering might be a good idea, too. Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT's HTTPS design consideration and guideline?
yes, there are differences. Testing: Use -noserver. Google for it on this newsgroup for more info on how that works. SSL has three notable differences. These aren't the only ones, but probably the biggest surprises: CACHING: Web browsers were designed to cope with idiot web server maintainers. This was a phenomenally stupid move, as you should never underestimate the ingenuity of idiots, but, alas, we're stuck with this bass ackwards principle, and it screws you over when you use SSL. The first culprit is caching. In SSL mode, you can push 'please cache me' all you want, but in general web browsers will ignore you. You should still try, but, take it with a grain of salt, and make sure you're set up to handle quite a bit of bandwidth. I've got an item on my todo list I should really get to, and that's to create a table to list which HTTP headers, if any, will make a browser cache stuff in SSL mode. REFERRAL: Web browsers will not send a referrer header if you link from https to http. The thinking here is that in the olden days, not everyone had cookies enabled, so you faked it by storing the session ID in the url itself, and you inspected the URL instead of the cookie to figure out a user's session id. This was not just a flagrant abuse of the whole concept of HTTP, but also a gaping security hole, because browsers tend to litter URLs all over the place. In caches, history data, and, yes, referral links. Instead of recognizing that this behaviour is simply security broken and spreading the word to stop doing it, the SSL standard edicts that HTTPS pages should not be sent as referrer to non-http pages, evidently in some sort of screwed up belief that sites running on https are more trustworthy in case an https page did use the session id in the URL trick to get around disabled cookies. D'ooh. You can fix it by bouncing all links through plain http on your own server, letting it redirect. But that's an ugly hack, and I won't get into how to set that up in this post. MIXED MODE WARNING: IE is especially sucky at this. You're free to swap the document domain between http and https all day long,but load one non-https piece of content in an https loaded page and the user gets an awkwardly huge warning dialog that no one understands and make them run for the hills. In practice there's rather little security leakage in e.g. loading user avatar images off of non-https, but, again, the SSL standard thinks it knows better than you and stubbornly gets in your way. Not to mention the rather stark difference between proctecting yourself against eavedroppers and the harder task of keeping out man-in-the-middle attacks. SSL acts as if the first (just protect against eavesdroppers) is somehow beneath it. Argh. No solution to this one as far as I know. Load it all over SSL. Yet another reason why so many people use SSL only for login and then move out, to avoid these issues, not because it costs a little more CPU. FORK OUT SOME DOUGH: https sans a signed certificate is like a party without booze. What's the point? Unfortunately, in order to be considered signed on all major browsers, you need to shell out some cash, about 100 dollars for a single domain, 500 for all subdomains to one domain. This step isn't optional - the security dialog that pops up when your SSL cert isn't signed properly is a lot scarier for a user than no https at all, and for once for good reason, as there's no way to verify that you're really talking to whatever's in your location bar without it. Just don't give your money to those bastards at verisign. They'll kill the internet if it were up to those freedom haters. That means, avoid verisign, thawte, and GeoTrust. Consider Comodo, or Entrust. I strongly urge you to heed this warning; verisign's control of the universally accepted root cert market is around 80% nowadays. If they control all of it, expect your yearly costs (oh, yeah, that 100 bucks is a yearly payment, sorry) to go sky high. It's in all of our best interests if that does not come to pass. Good luck, Hez. On Sep 17, 6:20 pm, hezjing [EMAIL PROTECTED] wrote: Hi I have a GWT application, and it is running without HTTPS. What need to be done if I want this GWT application to run with HTTPS? Is there any changes in the code and configuration? Can I test HTTPS in hosted mode? Is there any difference when designing a GWT application for HTTP and HTTPS? -- Hez --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Question on parsing JSON string
Yah, my new JSON library will. But it's not ready quite yet. Well, the
reading bit's ready - still working on writing. If you want to beta
test it, mail me. The core contributors are more or less agreed that
the current offering is a bit weak so you might see it as part of the
core GWT library in GWT 1.6. You're in luck - because of my attempt to
get the library introduced as part of GWT proper it has even more unit
tests than I'd usually write, so it should be pretty robust.
On Sep 17, 11:19 pm, ceeed [EMAIL PROTECTED] wrote:
Hi,
I am gettiing a hash/dictionary from the server as a JSON string. This
looks some thing like:
{a: bar, b: foo, c: [x, y, z], d: {1: xxx, 2:
yyy}}
Is there some class that can convert this to a HashMap?
Thanks,
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Problems with gwt 1.5
Your classpath is screwed up. Half the classes are being loaded from an older version of GWT, and half are loaded from a newer version. Double check your classpath; possibly you're picking up a gwt-user.jar from one place and a gwt-dev-XYZ.jar from another. If you installed GWT 1.5 by unzipping over the previous version, perhaps you unpacked gwt-user.jar at some point to hack around with some of the code. At any rate, try and install GWT 1.5 by deleting what's there first, then unzipping. On Sep 10, 12:36 pm, MikeTheQuick [EMAIL PROTECTED] wrote: Hi.. i have a problem with the new gwt library... When i compile my gwt application i have this error : java.lang.VerifyError: Cannot inherit from final class [java] at java.lang.ClassLoader.defineClass1(Native Method) [java] at java.lang.ClassLoader.defineClass(Unknown Source) [java] at java.security.SecureClassLoader.defineClass(Unknown Source) [java] at java.net.URLClassLoader.defineClass(Unknown Source) [java] at java.net.URLClassLoader.access$000(Unknown Source) [java] at java.net.URLClassLoader$1.run(Unknown Source) [java] at java.security.AccessController.doPrivileged(Native Method) [java] at java.net.URLClassLoader.findClass(Unknown Source) [java] at java.lang.ClassLoader.loadClass(Unknown Source) [java] at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) [java] at java.lang.ClassLoader.loadClass(Unknown Source) [java] at java.lang.ClassLoader.loadClassInternal(Unknown Source) [java] Exception in thread main The only things i changed are the gwt libraries With gwt 1.4 I don't have this problem... can someone tell me the reason? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: is communication over GWT-RPC secure
harimack: all https is as safe as you can make it, with the following caveats: 1. you NEED a signed cert from a root cert authority. This costs 100 dollars or more. 2. The designers of the https spec made some serious screwups way back when but are now afraid to fix their mistakes. You may experience some undue hardship because of this: A. you don't show up in referral logs; anytime a https site has a link to a non-http site, and you click on it, the browser will not send a referrer header. B. Many browsers just don't cache when https is involved, even if you, the server, are saying that its perfectly all right to do so. This can get annoying for your users and expensive on your bandwidth bill real fast. C. You should dive into your https settings on the jboss server and just turn off the really old encryption standards - you should just support TLS (SSL3 is an alias for that, I think), with at least 1024 bits for the handshake and 128 bits for the rest of the connection. Really old SSL clients only support 40-bit encryption, which any modern PC can brute force in a few hours. If such a client finds your site, it's unlikely to work with GWT anyway, but they might just get far enough to log in which isn't good at such a low encryption, of course. Hence: Tell your JBoss server to not even offer that old standard. It may already be configured that way, I don't know the specifics. On Sep 11, 12:11 am, harimack [EMAIL PROTECTED] wrote: Thomas, Charlie, thanks much for the details and pointers. I agree keeping sign-in and signup separate from GWT app is a good approach, thanks for the suggestion. also, i tried this approcah today, if i switch on HTTPS/SSL on my Jboss server which i am using to deploy my gwt app ( and turnoff http ), all communication can happen over https. this will ensure all comunication btw my client and server are safe, gwt or servlet. am i correct in my assumption, please let me know. thanks Hari On Sep 8, 3:07 am, Charlie Collins [EMAIL PROTECTED] wrote: As Thomas stated, make sure you use HTTPS. Also, I am not sure if this is the one you read or not -http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecur... - but it has some useful info (and notes https at the bottom, pointing to another useful thread as well). On Sep 7, 11:02 pm, harimack [EMAIL PROTECTED] wrote: Hi All, i am a new to Security, i am using GWT-RPC for login, i read the GWT LoginFAQ, and see that they are recommending using GWT-RPC for login, but my concern is, how secure is GWT-RPC over the wire, if some one is sniffing, is the data protected over the wire ?. Can you please let me know how would you approach login if you were using GWT-RPC. thanks for the help Hari --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Download file with GWT
1. The server has to send the file with a data type of application/ octet-stream. 2. You can't use an AJAX call (RequestBuilder / HttpRequest / GWT- RPC), those will never generate a save as box on the user's client. Use: 1. A link that a user clicks on. 2. open a new window using Window.open 3. redirect the current page to your excel page. I'm not sure if there's a GWT way, but with JSNI it's a matter of window.location = http://whatever;'; 4. Like #3, but do this in an iframe you just created, so that the user doesn't lose the GWT page. On Sep 11, 11:08 am, Folke [EMAIL PROTECTED] wrote: Plan A: Storing the file on the server. 1. Submit the data to the server 2. The server converts and stores the Excel data (temporarily) and assigns an ID 3. ID is sent back to the client 4. Open a new window or use an iframe with the download URL containing the ID as GET parameter 5. Server sends the Excel data with MIME type application/octet- stream. 6. Save as ... dialog opens. 7. ??? 8. Profit! Plan B: IFrame with form submit 1. Create an invisible IFrame containing a form with your data in a hidden field 2. Submit the form via Javascript. 3. (magick) 4. Save as ... dialog opens. 5. ??? 6. Profit! On Sep 11, 10:34 am, Simon Rydberg [EMAIL PROTECTED] wrote: I'm having the same problem.. I have a servlet that I make a POST ( I can't do a GET request because I send a lot of data to the servlet ) request with the RequestBuilder to the servlet and it recives all the data, creates, in my case an excel file and then the client recives the responce in a RequestCallback. And then nothing happens, except that the status of the responce is OK with code 200.. I want the user to see the download file form when the responce comes. I have searched this group and via google with an answer to my problem. Found some answers when you are making a GET-request, but nothing when you make a POST request... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[gwt-contrib] Re: New JSON API proposal
I can filter out newlines in string literals to translate to invalid JSON, but alternative non-standard methods to terminate string literals - there's no way I can safeguard against this. On Sep 8, 5:07 pm, Scott Blum [EMAIL PROTECTED] wrote: I think string literals need special scrutiny. If there is any way to get the parser to break out of a string literal where your checker doesn't notice, it would be a big problem For example, if there are parsers that will allow a carriage return to terminate a string literal and continue evaluating code, your checker could miss it. Or if there are alternate ways to end a string literal, like somehow encoding a character that will be recognized as an end quote. On Sun, Sep 7, 2008 at 6:38 PM, Reinier Zwitserloot [EMAIL PROTECTED]wrote: I haven't tested it yet, but I'm throwing it out there for review of the concept of what's going on here. Obviously, after this method is done checking the json string, it will be eval()ed. Is this deemed safe enough? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] new JSON api: Design problem.
I didn't quite think the way you can use the new API to create new
JSON objects through. Specifically, in order to support the 'set'
notation, Any given lookup will always need to tree out from the root,
every time, which could be a little slow for very deeply nested JSON,
and take up more memory.
In other words:
JSON json = JSON.parse(/*deeply nested
json*/).get(foo).get(bar).get(10).get(baz);
would have to be just the original deeply nested json and a 'pointer'
to foo/bar/10/baz. So, it will still take up all the memory of the big
json object, and every access to this thing will result internally in:
jso[foo][bar][10][baz].
I also have some doubts that the writing part of the API will make
sense to the casual user. It's definitely fast and convenient if you
know how it works, but, does this look readable to you (objective:
create {foo: [10, null], bar: []}:
JSON json = JSON.createMap();
json.get(foo).add().set(10);
json.get(foo).add().setNull();
json.get(bar).set(JSON.createList());
(one of the problems is that its really difficult to create empty
lists/maps with this method, as the general idea is to create the
'structure' (JS arrays and objects) on demand, but there is no demand
if they are supposed to be empty!)
Contrast this to the IMHO much cleaner code you can use to read such a
structure:
json.get(foo).get(0).asInt();
json.get(foo).get(1).isNull();
for (json item : JSON.get(foo).asList()) {
Object o = item.asObject();
}
json.get(bar).asList().size();
json.asObject(); //returns a HashMap with 2 ArrayLists in it, one of
which has an Integer and 'null', the other is empty).
Here's an alternative idea: Let the new API exist only for reading - I
never really had an issue with the existing API's utility when
creating JSON - just when reading it. Solves all these problems. If
that's fine, then it's ready to go right now, pending an addition to
the regexp that finds string literals during the validation step as
per Scott Blum's comments.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Re: GWT + comet?
As you said, comet is a complex problem on the server side. On the client it's relatively straightforward. Some issues: 1) You either need an async webserver (such as something based on the fairly new java Simple, or the continuation support available in jetty), or you need an OS + VM combo which can handle tons of threads without a high overhead (the latest linux + the latest java 6 seems capable of this). Be especially careful if you've got a frontloader (such as Apache) that merely redirects to your actual java stuff. Apache, out of the box, will probably not use the new worked thread mechanism to communicate with the java server at the backend, and by default apache will start serving up 'busy' pages if more than 50 simultaneous connections are already running. You get to 50 very quickly when using comet. If this is your setup, google around for how to implement apache+comet+java properly. Personally I just run jetty only, no apache. 2) The only safe way to do comet is to make a request from the client to the server, then the server returns NOTHING, not a single byte, it just waits, and then, once data is available, it sends it, and then closes the connection. In response, the client should open another connection and this whole song and dance number is repeated. The reason you can't just keep sending data across a single HTTP connection, is because the HTTP standard has no concept of 'flush'. A proxy or even the webclient itself (IE and Safari both do some limited caching, for example) will simply assume more will come very shortly, and never forward the data to the endpoint (your GWT app). In order to do this concept right, you need some sort of tracking number. For example, imagine an IRC (chat) client using comet. You could simply assign to each chat line in the chat room an index number, and upon first connect, tell the client the last chat line index number spoken. From here on out, comet can be done by letting the client request http://www.mychatserver.com/chats/line?idx=; + lastReceivedChatLineIdx++ - the server, upon receiving such a request, first checks if a line with that idx has already been said. If so, it is returned immediately (no comet). if NOT, it will not return an error, it will instead just wait and hold the connection open. Your servlet should register a listener of some sort with the central repository of chat messages, so it can wake up when the line with the given idx is actually spoken. You can't just ask for 'the next line' without a tracker ID of some sort, because in between receiving one line, processing it on the client, and opening another connection, a line might have been spoken. Without tracking you'd miss this line. 3) Because proxies, webservers, and web clients all have HTTP timeouts, and they are all different, you should manually close the connection after ~50 seconds. In our chat example, you'd send back something like: [NO CHAT] to indicate to the client that in the entire 50 second span, the chat line with idx '1234' never came up so far. In response, the client should re-open the connection with the exact same request (gimme line 1234). 4) For efficiency you may want to let the server respond with all relevant messages that have a tracker ID equal to or larger than the requested item. For example, in our chat app, if a client asks for message #1234, but on the server you already know that we're on message 1237 (a burst of rapid chats just recently happened, for example), then you should just send 1234, 1235, 1236, and 1237 in one go. You'll need a way to delimit each 'packet' of information in the response in this case. You could use JSON, for example. Or use a GWT- RPC call, though I don't know the specifics of making that work right with comet. 5) Web clients internally have a 2 connections limit. This means that, for any given full server name, if there are already 2 open connections, and a third thing is requested from this server, the client will queue up this request instead of sending it. Once one of those 2 open connections is closed, it will send it. This is perfectly reasonable when all requests are handled as fast as possible, but in comet, the whole point is that requests are NOT handled as fast as possible. If you have multiple comet elements on a single web page (Let's say, a 'live' stock ticker AND a chat box, each running a separate comet connection), then you're out of connections, and the act of requesting a simple image in response to a mouse over or some such never goes through! There are two solutions to this: A) run your non-AJAX calls off a different server. For example, serve up images from img.yourhost.com instead of just yourhost.com. You can't do this for your comet connections, because those usually use AJAX calls, and those must go to the same domain as the web page (Same Origin Policy, wikipedia that if you don't know what that is). This won't help you if you have 3 separate comety things going on, and it won't help
Re: GWT + comet?
Glad you liked the missive. I've saved a bookmark for future reference in case someone else comes in and asks (Comet usually comes up once a month or so). For game development: Just screw IE. There's no way to do halfway decent graphics on IE, period. Go flash, or tell people to switch to firefox/opera/safari/comet. All 3 non-IE browsers are trying to speed up javascript. Opera 9.5 has a fairly spiffy javascript engine already, and both firefox and webkit are on the verge of shipping custom very smart and very fast VMs for javascript (tracemonkey for firefox, and squirrelfish for safari). Then there's V8, which you can see at work today in Google Chrome. It looks like V8, Tracemonkey, and squirrelfish will all be roughly as fast as one another (can you say meep meep?) - should do wonders for attempts to write games in canvas. Which brings us back to IE. F!*k IE. There's future hope though: I believe apple has rescinded copyright/patent claims on canvas, or they ran out, so in theory nothing is stopping IE from implementing them now - though as I understand it, Microsoft never expressed interest in supporting them. Microsoft is part of the W3C and evidently they have not been able to use their considerable weight there to stop the latest news at W3C. W3C's own home-grown XHTML 2.0 effort has effectively been mothballed indefinitely, and instead HTML5 has been adopted (HTML5 started as something from the WHAT-WG, which is a much less officious entity compared to W3C, and consists of the developers of Opera, WebKit (Safari), and Gecko (Firefox/mozilla). - e.g. the anti-IE league, and the main reason stuff like canvas has seeded so quickly to the other non-IE browsers) HTML5 has been dollied up with some lip service to XHTML but make no mistake: Few really expected the W3C to 'fold' to the clearly superior HTML5 work in progress. HTML5 includes Canvas (see http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html for proof). The question now becomes: Does Microsoft break even more from the W3C than they already have (remember, IE isn't exactly standards compliant). So far betas of IE8 indicate that Microsoft is seriously attempting to build a more compatible browser, so there's hope. Then again, armchair analysts (like myself ㋛) believe that Microsoft is still trying to prevent the web from becoming the host of virtually every computer app out there, in order to keep their own OS (Windows) in a safe market leader position. Microsoft's stranglehold on the web community by way of IE is one of the things holding web apps back, so there are plenty of pessimists who believe that the final version of IE8 will be a big disappointment. On Sep 7, 9:41 pm, markww [EMAIL PROTECTED] wrote: Thanks for the excellent response, that was very helpful. Everything makes sense, I was taking a look at Jetty and it seems easy to use for what I want to do. I had been writing my own java nio server for a class I was taking, it's cool to see how Jetty has taken advantage of the nio stuff to support 'comet'. From a game development point of view, this is great because we can wait for the server to send us data instead of constantly polling it. One thing that still seems to be missing is fast graphics support, to actually render dynamic game data. I was working with the gwt canvas intensively a few months ago, but was disappointed to find out that IE's support for it was just horrible. Firefox and Safari (and probably Chrome now) can do a decent job of rendering simple primitives fast in a canvas. In fact, my iPhone could render primitives faster than IE! I wonder if there is any development on this (providing a fast canvas for direct pixel manipulation) by the browsers. Right now it seems like the only way to do it is by using Flash. Anyway thanks again for all those answers, definitely got me in the right direction, Mark On Sep 7, 6:30 am, Reinier Zwitserloot [EMAIL PROTECTED] wrote: As you said, comet is a complex problem on the server side. On the client it's relatively straightforward. Some issues: 1) You either need an async webserver (such as something based on the fairly new java Simple, or the continuation support available in jetty), or you need an OS + VM combo which can handle tons of threads without a high overhead (the latest linux + the latest java 6 seems capable of this). Be especially careful if you've got a frontloader (such as Apache) that merely redirects to your actual java stuff. Apache, out of the box, will probably not use the new worked thread mechanism to communicate with the java server at the backend, and by default apache will start serving up 'busy' pages if more than 50 simultaneous connections are already running. You get to 50 very quickly when using comet. If this is your setup, google around for how to implement apache+comet+java properly. Personally I just run jetty only, no apache. 2) The only safe way to do
Re: Need to get images original dimensions before displaying.
Use onLoad, but also start a timer, and check after 10 seconds. If the image has dimensions that aren't 0x0, remove the onload trigger, and do the resize. On Sep 2, 4:00 pm, darkflame [EMAIL PROTECTED] wrote: Dosnt really help me. I cant even show them at the correct size without knowing what size they are originaly. (nor can I easily center them). I only wish to have a maximum limit in place as well in the case the supplied image is too large. The fact IE has a horrible resize is just another point to add to its many faults rather then relivent to my code at the moment. I dont want to burden my limited server with having to send individualy made images and size specs to absolutely each client using the app. (if its possible at all, I dont want this app to need any specific sever requirements, it will have php as an option for some added security, but I am also making it happly work offline. So no sever-side requirements are part of my spec ). On Sep 2, 3:50 pm, ReinierZwitserloot[EMAIL PROTECTED] wrote: You can't resize images in the browser. They'll look really -really- bad (nearest point resizing in at least IE6). Resize them on the server. When requesting them, send the size of the current window along. On Sep 2, 1:59 pm, darkflame [EMAIL PROTECTED] wrote: What I'm trying to do; Display an image, which is either its original width, or 80% of the browsers width. Whichever is smallest. Height is scaled preportionaly so the correct ratio is maintained. Now, I know I cant get the image size untill its loaded, so I added an onLoad listener. But I then ran up against this issue;http://code.google.com/p/google-web-toolkit/issues/detail?id=863 I cant rely on onLoad to work in IE. So whats the easiest way to achieve what I need? Cheers :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Google Chrome
askar: Did you try to contribute to GWT? They accept anyone, and are willing to listen to any patch proposal you have, provided you of course do the work. It doesn't look like anyone cares if you actually work at google. This meritocracy system is essentially the same as any open source project, so what possible good would it do if google 'completely transfer it to open source community'. On Sep 2, 3:52 pm, askar [EMAIL PROTECTED] wrote: Recently I have been feeling pessimistic about GWT future, although we are using GWT in our product. It seems like development slowed down significantly during 1.5 release cycle and I'm anxious whether Google guys can finally stop working on GWT and completely transfer it to open source community. Undoubtedly, the choice of technology for development of enterprise applications depends on technology's perspectives and it's a pity we don't know how Google envisages GWT roadmap. From that point of view, Adobe AIR and Microsoft Silverlight seem to be better options as a platform to use for next several years. I think we can be sure that both technologies will be there for a long time; can you say the same about GWT? Should you invest in writing tons of code for the platform that will be abandoned soon? Having said that, I do think that GWT is a great technology that we get for free. It has a great advantage over AIR and Silverlight - it does not need any additional plugins for the browser. I hope that GWT will be integrated somehow with Google Chrome because that would mean longer life for GWT as a platform. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Need to get images original dimensions before displaying.
You can't resize images in the browser. They'll look really -really- bad (nearest point resizing in at least IE6). Resize them on the server. When requesting them, send the size of the current window along. On Sep 2, 1:59 pm, darkflame [EMAIL PROTECTED] wrote: What I'm trying to do; Display an image, which is either its original width, or 80% of the browsers width. Whichever is smallest. Height is scaled preportionaly so the correct ratio is maintained. Now, I know I cant get the image size untill its loaded, so I added an onLoad listener. But I then ran up against this issue;http://code.google.com/p/google-web-toolkit/issues/detail?id=863 I cant rely on onLoad to work in IE. So whats the easiest way to achieve what I need? Cheers :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Reading CSV files for rendering
Reading CSV files is a matter of applying String.split(\\n) and String.split(,). That's all you need to do parse it. Rendering it - of course you need to do that yourself. GWT doesn't have a magic: GWT.renderYahooFinanceCSVDataJustTheWayIAmImaginingIt() function. We're working on it though. On Aug 30, 12:47 am, Larry White [EMAIL PROTECTED] wrote: i don't think reading csv files is the kind of thing that gwt does - or should do. In one of my projects, I use the open source java library OpenCSV -http://opencsv.sourceforge.net/ Not sure if this will meet your exact needs but it works for me. Once you've parsed the files, you can focus on rendering them with gwt. cheers. On Fri, Aug 29, 2008 at 4:34 PM, shinokamparos [EMAIL PROTECTED]wrote: Hi I'm trying to read historical data from Yahoo Finance. The file returned by them is in the csv format. does GWT support this? Will I have to render this myself? If so, can someone give me tips on how to do this, i'm new to java programming and GWT. If anyone could point me in the right direction i'd be much obliged --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.5 long JSNIs vs. Dates.
I apologize for being an idiot. The answer is was looking for 'use a
'double' instead of a 'long' - you said it yourself - dumbass!'.
Eh, it had been a long day. Thanks for all the hints, at any rate. And
extra points for Ian for showing yet another way in which JSOs are
cool.
On Aug 29, 9:26 am, Ian Petersen [EMAIL PROTECTED] wrote:
On Fri, Aug 29, 2008 at 3:05 AM, Reinier Zwitserloot [EMAIL PROTECTED]
wrote:
I don't use GWT-Serialization to talk to my server. The server sends
timestamps as milliseconds. I'd like to turn these milliseconds into
javascript Date objects.
How do I accomplish this?
As I mentioned when long emulation was on the table, timestamps are
one of those numbers which are not representable with ints, but they
fit perfectly in the range where doubles still represent integral
numbers without loss of precision.
I don't think you want to use longs--someone measured them at 250
times slower than JS doubles, or something like that. I think you
want the following:
public final class JSDate extends JSO {
protected JSDate() {
}
public static native create(double millis) /*-{
return new Date(millis);
}-*/;
// implement relevant date methods here, like getYear:
public native int getYear() /*-{
return this.getYear();
}-*/;
}
Not sure though--I haven't used the new overlay stuff myself, and I
typed the above directly into the browser without testing.
Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Re: do somebody know how to access private field and method in gwt widget using jsni from custom class ?
Just access it. In JSNI, 'final', and 'private' do not exist.
You'll need to read up on JSNI. Here's an example:
public static native callGetSplitElement(HorizontalSplitPanel panel) /
*-{
[EMAIL PROTECTED]::getSplitElement()
();
}-*/;
Note the double ()(). The first () is part of the getSplitElement
signature (namely, the parameter list). The second () is the actual
parameters. In this case, getSplitElement has no parameters, so it's
just ()().
Also, you're still using private parts of an API. If you use these
tricks, your code is most likely not going to work with the next
version of GWT. Even a small point release might change things around.
You've been warned!
On Aug 27, 1:23 am, Rene [EMAIL PROTECTED] wrote:
I tryed everything and allways som exception or so. There is
getSplitElement() in HorizontalSplitPanel , how to access it , and or
some field also. I beleve that it will be very helpful also to
others.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
