On Sun, Jun 5, 2011 at 2:34 AM, Thomas Broyer <[email protected]> wrote:
>
> Or maybe you could have a single place and have the ActivityMappers (or
> whatever PlaceChangeHandler if you're not using Activities) react
> differently whether the user is authenticated or not.
Originally I did have a single default Place, but the caching of
places made this problematic. Ie, when you log in, you "go to" the
same place and nothing happens. A. Stevko's suggestion of just firing
the PlaceChangeEvent myself is the
"doh-I-can't-believe-I-didn't-think-of-that" solution to this problem
(thanks A!)
> Authentication is (should be) orthogonal to navigation. When the user
> authenticates, you should dispatch a LoginEvent (or similar) on the event
> bus and have the activities (or whatever) refresh their content ("restart").
This just doesn't work in my application. When the user logs in, the
*entire* app gets torn down and rebuilt using a different set of Gin
"singletons" and a totally different navigation structure. Basically,
when I get a LoginEvent, I need to simulate the user having gone
directly to the new URL in a fresh application.
Reloading the browser page would be tempting but I have too much state
that needs to carry across. Also, it's ugly.
I think the LoginEvent approach makes sense in an app that you can
reasonably navigate in both auth and nonauth states. In this kind of
app, yeah, authenticating just makes some widgets redraw their
content. But I don't think I can get away with that. I do have a
LoginEvent, but it's essentially caught by my master module object,
and has to do a warm restart of the app. I'm guessing this is a
common pattern, and Places makes it difficult.
Jeff
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
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.
