Re: problems with auto-complete form login
On 6 Sep., 19:59, Thomas Broyer t.bro...@gmail.com wrote: But honestly, I don't understand how this design is any different from redirecting to the login page (unless maybe you have a cancel button that leaves you in the app, i.e. without reload) Well, from my point of view it would be nice if the login form is visually integrated into my app. I managed to size and center the iframe so that it just opens as a popup. However, I now have an external login page, totally outside of GWT, but I am not happy with all that. First, my app loads. Then, when I request the login, it unloads and loads the external login page, and then, after login, my app loads again. This is a very time consuming process. And the login page itself does not fit into the visual design of the app at all... I wonder why we have to research on this topic. It must be a problem that almost all GWT developers must also have. Why isn't there a generic recommendation, or even a solution within GWT? I have the feeling that we are inventing some wheels here. As I already said, I am totally unhappy with this solution, and I hope some GWT developers point me/us into a better direction someday... Magnus -- 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-tool...@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: problems with auto-complete form login
Just for the completeness: I recall what was the problem with the GWT integration: As I said I had an iframe with the src attribute pointing to a separate html file with the login form. Then, to inject the JS code for form submission I needed to wrap the form. But I did not get access to the iframe's DOM... Just for the completeness... I am still unhappy... :-/ Magnus -- 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-tool...@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: problems with auto-complete form login
Thomas, I was too quick when saying that it works with iframes: The login page was shown correctly and the browser offered autofill, but FormPanel.wrap caused an exception which I could not get away (i think a JS exception). Then I tried a combination of both - external login and visual GWT integration: I made an external JSP page for the log, totally outside of GWT, but I loaded this JSP page into an iframe so that it showed up within my GWT app. The only problem is, when I submit the login form inside the iframe, the login page redirects to my app inside the iframe. So the app appears inside the iframe. Isn't there a way to do the following: If the login form within the iframe is submitted, reload the app outside the iframe. Magnus On 3 Sep., 19:00, Magnus alpineblas...@googlemail.com wrote: Hmmm...I would like to get my peace with this, but... I now created an invisible iframe in my host html. On login I just show it, so it's a native html form. It's not so nice as a DialogBox, but it works. I cannot see why this is bad. Why is it bad? You see, I cannot let it go... :-) Magnus On Sep 2, 3:47 am, Thomas Broyer t.bro...@gmail.com wrote: On Sep 1, 3:42 pm, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! Not necessarily. The setup I described about web.xml, etc. would make it behave as you describe, but that's just one way to do externalized login, and a way that doesn't make guest access possible (to make things simpler and keeping the advantages of container-managed login using servlet FORM or JASPIC, you could just use 2 host pages: a world-accessible one and a restricted one, possible using redirections and so on to make it work as intended in every corner case, I haven't tested; I bet you'll find plenty of examples on the Web about doing guest and authenticated access on the same resource in Java servlet/JSP) In every of the 3 cases you cite, I don't see a problem in reloading the app when switching from unauthenticated to authenticated access (if you want to keep some information around –such as your shopping cart–, send it as part of the login process –or store it on the server and pass some ID around–). YMMV of course (and I didn't say externalize login is a silver bullet, you might really want/need some UX that would make it impossible to use). One possibility too is to only allow a guest-to-authenticated-user workflow without reloading the app (integrated login). As soon as the user wants to sign out, then reload the app and start back in guest mode. That way, you don't have to fear about restricted data leaking between user sessions, but you'd still have to make sure to clear some client-side caches (depending on your use case; for the forum case you gave, for instance, clear the list of posts so you'll reload them from the server and see the restricted posts). -- 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-tool...@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: problems with auto-complete form login
Hello Magnus, That's called Breaking out of frames [1]. If you need your app to be able to detect a valid login, then you'll need to communicate from within the iframe to the hosting app that the login was ok (have a look at window.name transport in this case [2]) [1] http://www.blooberry.com/indexdot/html/topics/breakframe.htm [2] http://development.lombardi.com/?p=611 On Sep 6, 3:00 pm, Magnus alpineblas...@googlemail.com wrote: Thomas, I was too quick when saying that it works with iframes: The login page was shown correctly and the browser offered autofill, but FormPanel.wrap caused an exception which I could not get away (i think a JS exception). Then I tried a combination of both - external login and visual GWT integration: I made an external JSP page for the log, totally outside of GWT, but I loaded this JSP page into an iframe so that it showed up within my GWT app. The only problem is, when I submit the login form inside the iframe, the login page redirects to my app inside the iframe. So the app appears inside the iframe. Isn't there a way to do the following: If the login form within the iframe is submitted, reload the app outside the iframe. Magnus On 3 Sep., 19:00, Magnus alpineblas...@googlemail.com wrote: Hmmm...I would like to get my peace with this, but... I now created an invisible iframe in my host html. On login I just show it, so it's a native html form. It's not so nice as a DialogBox, but it works. I cannot see why this is bad. Why is it bad? You see, I cannot let it go... :-) Magnus On Sep 2, 3:47 am, Thomas Broyer t.bro...@gmail.com wrote: On Sep 1, 3:42 pm, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! Not necessarily. The setup I described about web.xml, etc. would make it behave as you describe, but that's just one way to do externalized login, and a way that doesn't make guest access possible (to make things simpler and keeping the advantages of container-managed login using servlet FORM or JASPIC, you could just use 2 host pages: a world-accessible one and a restricted one, possible using redirections and so on to make it work as intended in every corner case, I haven't tested; I bet you'll find plenty of examples on the Web about doing guest and authenticated access on the same resource in Java servlet/JSP) In every of the 3 cases you cite, I don't see a problem in reloading the app when switching from unauthenticated to authenticated access (if you want to keep some information around –such as your shopping cart–, send it as part of the login process –or store it on the server and pass some ID around–). YMMV of course (and I didn't say externalize login is a silver bullet, you might really want/need some UX that would make it impossible to use). One possibility too is to only allow a guest-to-authenticated-user workflow without reloading the app (integrated login). As soon as the user wants to sign out, then reload the app and start back in guest mode. That way, you don't have to fear about restricted data leaking between user sessions, but you'd still have to make sure to clear some client-side caches (depending on your use case; for the forum case you gave, for instance, clear the list of posts so you'll reload them from the server and see the restricted posts). -- 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-tool...@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: problems with auto-complete form login
On 6 sep, 19:22, George Georgovassilis g.georgovassi...@gmail.com wrote: Hello Magnus, That's called Breaking out of frames [1]. If you need your app to be able to detect a valid login, then you'll need to communicate from within the iframe to the hosting app that the login was ok (have a look at window.name transport in this case [2]) [1]http://www.blooberry.com/indexdot/html/topics/breakframe.htm [2]http://development.lombardi.com/?p=611 In this case, a target=_top on the form would be enough. But honestly, I don't understand how this design is any different from redirecting to the login page (unless maybe you have a cancel button that leaves you in the app, i.e. without reload) -- 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-tool...@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: problems with auto-complete form login
Hmmm...I would like to get my peace with this, but... I now created an invisible iframe in my host html. On login I just show it, so it's a native html form. It's not so nice as a DialogBox, but it works. I cannot see why this is bad. Why is it bad? You see, I cannot let it go... :-) Magnus On Sep 2, 3:47 am, Thomas Broyer t.bro...@gmail.com wrote: On Sep 1, 3:42 pm, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! Not necessarily. The setup I described about web.xml, etc. would make it behave as you describe, but that's just one way to do externalized login, and a way that doesn't make guest access possible (to make things simpler and keeping the advantages of container-managed login using servlet FORM or JASPIC, you could just use 2 host pages: a world-accessible one and a restricted one, possible using redirections and so on to make it work as intended in every corner case, I haven't tested; I bet you'll find plenty of examples on the Web about doing guest and authenticated access on the same resource in Java servlet/JSP) In every of the 3 cases you cite, I don't see a problem in reloading the app when switching from unauthenticated to authenticated access (if you want to keep some information around –such as your shopping cart–, send it as part of the login process –or store it on the server and pass some ID around–). YMMV of course (and I didn't say externalize login is a silver bullet, you might really want/need some UX that would make it impossible to use). One possibility too is to only allow a guest-to-authenticated-user workflow without reloading the app (integrated login). As soon as the user wants to sign out, then reload the app and start back in guest mode. That way, you don't have to fear about restricted data leaking between user sessions, but you'd still have to make sure to clear some client-side caches (depending on your use case; for the forum case you gave, for instance, clear the list of posts so you'll reload them from the server and see the restricted posts). -- 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-tool...@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: problems with auto-complete form login
Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! For now, I am not sure if I understood you right. In addition I am thinking about a dummy user to let guests come into my application, but I am not sure if this is a solution. What do you think about this? Magnus On 1 Sep., 00:13, Thomas Broyer t.bro...@gmail.com wrote: On 31 août, 19:34, Magnus alpineblas...@googlemail.com wrote: Hi folks, is it the common opinion for GWT apps to have a separate login page? (Thomas, your cache example seems a bit artificial to me (although I believe that you know why you recommend a separate login page).) Having built 2 apps that way, and having to remember to handle those login/logout events to reset the views, I can assure you it's not artificial, but lot of boilerplate code I could have just avoided writing. I also spent way too much time (IMO) to get the login process working (have to use a base AsyncCallback/RequestCallback that handles authentication errors to show the login screen –RequestFactory will fortunately makes this waaay easier–; and what to do once you log back in? replay the request? the reason we went for an integrated login UX was our client asking for sessions to expire, and we didn't want the user to lose its unsaved work, so the login screen in this case is showed above the screen, with the username field switched to readonly; if you do not have a need for such a thing, then I you could probably live with an externalized login; I'm now trying to make clients change their mind about session expiration, and/or adopting a different approach with auto-saves into server-side working copies, or live with their users losing work if they don't hit save soon enough though without automatically redirecting them to the login screen, similar to how web 1.0 applications generally work – directing you to the login screen only when you hit the server, i.e. only between page loads–) Could someone please provide an example for a separate login page? I wonder if this should be realized as a servlet or a jsp or something like that, how control is passed to the app and how the app finds out that the user is logged in... To force authentication, my approach is to just have the host html page a protected resource (configure security in the web.xml to require a valid, authenticated user; letting the servlet container handling authentication, using JASPIC/JSR-196 or the container's own APIs when you need/want customization). For the app to know the user's details, the host html page is a JSP, rendering a script block defining a JavaScript variable with the needed info,and using JSNI or just Dictionnary to getthe info from the GWT app (do a view-source on GMail or any AJAX Google App, you'll see that they're doing similar things), but an RPC request at onModuleLoad could do it too (though a bit less performant). I can't give you code/config sample offhand, but there's nothing really special about it. The only missing thing is to detect session expirations from your RPC calls but you already were doing this, right? (as I said, RequestFactory makes this easier –dispatching an event on the eventbus– so if you can wait GWT 2.1, use RequestFactory!) -- 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-tool...@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: problems with auto-complete form login
Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! For now, I am not sure if I understood you right. In addition I am thinking about a dummy user to let guests come into my application, but I am not sure if this is a solution. What do you think about this? Magnus On 1 Sep., 00:13, Thomas Broyer t.bro...@gmail.com wrote: On 31 août, 19:34, Magnus alpineblas...@googlemail.com wrote: Hi folks, is it the common opinion for GWT apps to have a separate login page? (Thomas, your cache example seems a bit artificial to me (although I believe that you know why you recommend a separate login page).) Having built 2 apps that way, and having to remember to handle those login/logout events to reset the views, I can assure you it's not artificial, but lot of boilerplate code I could have just avoided writing. I also spent way too much time (IMO) to get the login process working (have to use a base AsyncCallback/RequestCallback that handles authentication errors to show the login screen –RequestFactory will fortunately makes this waaay easier–; and what to do once you log back in? replay the request? the reason we went for an integrated login UX was our client asking for sessions to expire, and we didn't want the user to lose its unsaved work, so the login screen in this case is showed above the screen, with the username field switched to readonly; if you do not have a need for such a thing, then I you could probably live with an externalized login; I'm now trying to make clients change their mind about session expiration, and/or adopting a different approach with auto-saves into server-side working copies, or live with their users losing work if they don't hit save soon enough though without automatically redirecting them to the login screen, similar to how web 1.0 applications generally work – directing you to the login screen only when you hit the server, i.e. only between page loads–) Could someone please provide an example for a separate login page? I wonder if this should be realized as a servlet or a jsp or something like that, how control is passed to the app and how the app finds out that the user is logged in... To force authentication, my approach is to just have the host html page a protected resource (configure security in the web.xml to require a valid, authenticated user; letting the servlet container handling authentication, using JASPIC/JSR-196 or the container's own APIs when you need/want customization). For the app to know the user's details, the host html page is a JSP, rendering a script block defining a JavaScript variable with the needed info,and using JSNI or just Dictionnary to getthe info from the GWT app (do a view-source on GMail or any AJAX Google App, you'll see that they're doing similar things), but an RPC request at onModuleLoad could do it too (though a bit less performant). I can't give you code/config sample offhand, but there's nothing really special about it. The only missing thing is to detect session expirations from your RPC calls but you already were doing this, right? (as I said, RequestFactory makes this easier –dispatching an event on the eventbus– so if you can wait GWT 2.1, use RequestFactory!) -- 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-tool...@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: problems with auto-complete form login
On Wed, Sep 1, 2010 at 6:42 AM, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! For now, I am not sure if I understood you right. In addition I am thinking about a dummy user to let guests come into my application, but I am not sure if this is a solution. What do you think about this? You're on the right track. Consider separating authentication (who are you) from authorization (what can you do). You have a /guest/ role along side a /user/ role. -- 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-tool...@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: problems with auto-complete form login
On Sep 1, 3:42 pm, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, I have thought about this the whole day now and it really sounds interesting to me to give it a try with external login, but - if I understood you right - I see a big disatvantage: Many applications are not or should not be usable at all when the user is not logged in. But there are also applications that should be usable (in a limited way) without login. Consider eBay: You can search and browse as nobody, but if you want to sell, you have to sign in. Or consider a chess application: You can watch everything, but if you want to create a new game, you have to sign in first. Consider a forum: You can read a lot, but not everything, but after you login, you can read everything and also write. So my problem is that with your method I had to lock out all guest users that just want to come and see what is going on there! Not necessarily. The setup I described about web.xml, etc. would make it behave as you describe, but that's just one way to do externalized login, and a way that doesn't make guest access possible (to make things simpler and keeping the advantages of container-managed login using servlet FORM or JASPIC, you could just use 2 host pages: a world-accessible one and a restricted one, possible using redirections and so on to make it work as intended in every corner case, I haven't tested; I bet you'll find plenty of examples on the Web about doing guest and authenticated access on the same resource in Java servlet/JSP) In every of the 3 cases you cite, I don't see a problem in reloading the app when switching from unauthenticated to authenticated access (if you want to keep some information around –such as your shopping cart–, send it as part of the login process –or store it on the server and pass some ID around–). YMMV of course (and I didn't say externalize login is a silver bullet, you might really want/need some UX that would make it impossible to use). One possibility too is to only allow a guest-to-authenticated-user workflow without reloading the app (integrated login). As soon as the user wants to sign out, then reload the app and start back in guest mode. That way, you don't have to fear about restricted data leaking between user sessions, but you'd still have to make sure to clear some client-side caches (depending on your use case; for the forum case you gave, for instance, clear the list of posts so you'll reload them from the server and see the restricted posts). -- 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-tool...@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: problems with auto-complete form login
On 31 août, 11:38, Magnus alpineblas...@googlemail.com wrote: Hi Thomas, didn't you propose exactly this method which is referenced in the document I referred to? Yes, and I implemented it, and I now regret. On 30 Aug., 10:48, Thomas Broyer t.bro...@gmail.com wrote: ...which violates rule #3: do not move the form around Which rule do you mean? Some informal rules. Rule #1 is to have the form in the original markup of the page, and rule #2 is to let the browser submit the form using an input type=submit or button type=submit, rather than calling form.submit(). See above, the problem is moving the FormPanel around (adding it to a VerticalPanel in this case). I don't understand that, because the VerticalPanel is also used in the example, and this seems to work: http://borglin.net/gwt-project/?page_id=467 I can't tell whether the example work in all browsers, but in my (now ancient) testings, you had to leave the form where you found it and only play with its attributes and style (that'd be rule #3). (but believe me, you'd rather externalize the login process from your app, just like Google apps –as you're using GMail, you should understand what I mean–, it makes things so much simpler!) What exactly would get simpler? If the login/logout mechanism works, everything is fine, isn't it? If you cache some data on the client-side (which also includes, for instance, populating a ListBox only if it's empty, because you know upfront that the data shouldn't change for the lifetime of the app, for a given user), then you'd have to dispatch login/logout events to all your components so they empty their caches. You don't have to think about this kind of things if data won't change for the lifetime of the app (because signing out would mean leaving the app). -- 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-tool...@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: problems with auto-complete form login
Hi folks, is it the common opinion for GWT apps to have a separate login page? (Thomas, your cache example seems a bit artificial to me (although I believe that you know why you recommend a separate login page).) Could someone please provide an example for a separate login page? I wonder if this should be realized as a servlet or a jsp or something like that, how control is passed to the app and how the app finds out that the user is logged in... Thanks Magnus -- 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-tool...@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: problems with auto-complete form login
On 31 août, 19:34, Magnus alpineblas...@googlemail.com wrote: Hi folks, is it the common opinion for GWT apps to have a separate login page? (Thomas, your cache example seems a bit artificial to me (although I believe that you know why you recommend a separate login page).) Having built 2 apps that way, and having to remember to handle those login/logout events to reset the views, I can assure you it's not artificial, but lot of boilerplate code I could have just avoided writing. I also spent way too much time (IMO) to get the login process working (have to use a base AsyncCallback/RequestCallback that handles authentication errors to show the login screen –RequestFactory will fortunately makes this waaay easier–; and what to do once you log back in? replay the request? the reason we went for an integrated login UX was our client asking for sessions to expire, and we didn't want the user to lose its unsaved work, so the login screen in this case is showed above the screen, with the username field switched to readonly; if you do not have a need for such a thing, then I you could probably live with an externalized login; I'm now trying to make clients change their mind about session expiration, and/or adopting a different approach with auto-saves into server-side working copies, or live with their users losing work if they don't hit save soon enough though without automatically redirecting them to the login screen, similar to how web 1.0 applications generally work – directing you to the login screen only when you hit the server, i.e. only between page loads–) Could someone please provide an example for a separate login page? I wonder if this should be realized as a servlet or a jsp or something like that, how control is passed to the app and how the app finds out that the user is logged in... To force authentication, my approach is to just have the host html page a protected resource (configure security in the web.xml to require a valid, authenticated user; letting the servlet container handling authentication, using JASPIC/JSR-196 or the container's own APIs when you need/want customization). For the app to know the user's details, the host html page is a JSP, rendering a script block defining a JavaScript variable with the needed info,and using JSNI or just Dictionnary to getthe info from the GWT app (do a view-source on GMail or any AJAX Google App, you'll see that they're doing similar things), but an RPC request at onModuleLoad could do it too (though a bit less performant). I can't give you code/config sample offhand, but there's nothing really special about it. The only missing thing is to detect session expirations from your RPC calls but you already were doing this, right? (as I said, RequestFactory makes this easier –dispatching an event on the eventbus– so if you can wait GWT 2.1, use RequestFactory!) -- 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-tool...@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: problems with auto-complete form login
On 30 août, 07:45, Magnus alpineblas...@googlemail.com wrote: Hi, I implemented a login form suitable for auto-complete by the browser nearly exactly as described here: http://borglin.net/gwt-project/?page_id=467 ...which violates rule #3: do not move the form around or the browser will treat it the same as a dynamically generated form and won't auto- fill it (well, it really depends on which browser, and probably which browser version). All you're allowed to do with the form is to show and hide it and change its style. (but believe me, you'd rather externalize the login process from your app, just like Google apps –as you're using GMail, you should understand what I mean–, it makes things so much simpler!) Unfortunately, I have problems with it: 1. The password field is not filled in. When I login for the first time the browser (FF) asks me to remember the form fields. I can verify in the browsers settings that the username and password is stored in the browser. However, when I login again, only the username field is autofilled. The password field is empty. See above, the problem is moving the FormPanel around (adding it to a VerticalPanel in this case). 2. I cannot repeat the login. When I login, logout and then try to login again, the form cannot be created. The call to Document.get().getElementById(LOGINFORM_ID); returns null. First, because the form has already been wrapped, you shouldn't try to wrap it again; consider your FormPanel as a singleton, and always reuse it (as a rule of thumb, make all your views singletons if you can; working with the DOM is probably what degrades your app's performances the most, so try to not do it more than necessary). In your case, getElementById probably returns null because you removed the FormPanel from the document instead of just hiding/showing it. But let me reiterate: your life will be easier if you externalize the login process from your app. When the app loads, it knows if the user is authenticated (in case you authorize unauthenticated access, otherwise the app wouldn't even be loaded as the authentication gatekeeper wouldn't let the user in without first authenticating) and who she is; and the user's identity cannot change through the lifetime of the app (signing out will unload the app, re-signing in will load it again), which means you can keep data cached. Integrating the login process in your app means dispatching login/logout events and handling them to clear cached data, which can really become very painful. Believe me on this, I built two apps this way before I realize the obvious (well, I already knew it before making the second one, but it had to work the same as the first :-( ) -- 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-tool...@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.
