Hi,
I think you can do this relatively simply, but it's not directly noted
in the documentation.
(warning, a little plug ahead...) We're looking at how to do this for
the 2nd edition of the GWT in Action book, and the approach below is
where we are at the moment, though we have not thought through all
implementations yet. The final solution will be described in detail
in the book, but the following is the essence of the current solution:
* GWT has a FilteredActivityMapper that you can use to run another
activity rather than the one associated with the requested Place; for
example if you go to a PhotoEditPlace when not logged in, you might
want to run the LoginActivity rather than PhotoEditActivity.
* To do that, we created a Filter, such as:
Filter filter = new Filter(){
public Place filter(Place place) {
// Always allow the WelcomePlace
if(place instanceof WelcomePlace) return place;
// If user is not logged in, redirect
the activity for requested place to the login activity
if(!isLoggedIn()) return loginPlace;
// If user is logged in, then allow
the requested place/activity
else return place;
}};
* To use the filter, we created the ActivityMapper using a
FilteredActivityMapper instead of the standard ActivityMapper, i.e.:
// Difference to normal here
ActivityMapper activityMapper = new
FilteredActivityMapper(filter, new AppActivityMapper(clientFactory));
// Carry on as normal from here
ActivityManager activityManager = new
ActivityManager(activityMapper, eventBus);
* In the login activity, there is code to refresh the browser page if
the user logs in successfully (a simple Window.Location.reload() has
worked so far)
The flow is:
* User goes to a protected page
* If logged in the FilteredActivityMapper allows the appropriate
activity to start
* If not logged in,
* the FilteredActivityMapper starts the login activity
* when user logs in successfully, the fact they are logged in is
captured and the browser page is reloaded
* since the filter only redirected the activity, not the place,
then the reload goes to the original place, this time the filter
should detects the user is logged in, and so the requested activity is
started, rather than the login activity.
Hope that is of some use!
//Adam
On 5 Juni, 11:34, Thomas Broyer <[email protected]> wrote:
> On Saturday, June 4, 2011 11:47:08 PM UTC+2, Jeff Schnitzer wrote:
>
> > I'm trying to implement a simple pattern that is *very* common in the
> > world of "normal" webapps:
>
> > 1) Most of my application requires authentication in order to access.
> > 2) I allow deep links to protected content.
> > 3) When visiting a deep link, you are given a login page - after
> > logging in, you get the content.
>
> > I have a single-page GWT app that uses Places. I've spent a lot of
> > time on this issue, and I *almost* have it working - but it's not
> > elegant and there are still broken edge cases. If you want to
> > experience it firsthand, visithttp://www.similarity.com/#matches:
>
> > The specific issues with the Places system are:
>
> > * The default place is different in authenticated mode vs anonymous
> > mode. When you are anonymous, your default place is the "hello,
> > stranger" place but when you're logged in, the default place is "all
> > about your account". Since I can't reset the default place in the
> > PlaceHistoryHandler, I need to swap out the instance when I switch
> > modes.
>
> 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.
>
> * The PlaceController has no way to reset the current place. When an
>
> > anonymous user tries to go to the #matches: link, the place is set to
> > MatchesPlace (which my special handler translates into a "you must log
> > in first" message). When the user logs in, I force another
> > handleCurrentHistory(), but it doesn't actually do anything - because
> > the PlaceController is already at MatchesPlace. I'll have to swap out
> > the PlaceController instance when I switch modes.
>
> 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").
>
> > And now a little rant:
>
> > All in all, this seems ludicrously difficult for something I could
> > have done with dozen lines of code if I wasn't trying to use the
> > standard GWT tools. I feel like I've wasted a lot of time learning
> > the system, and what I've ultimately learned is that I would be better
> > off building it from scratch.
>
> > Am I the only one that thinks the Places system is WAY
> > over-engineered, yet not all that useful?
>
> Before it existed, I built something that was very similar, so no, I don't
> think it's over-engineered (quite the contrary actually). BTW, it's just a
> tool, you're free to use it or not. Nobody said it's a "one size fit all",
> there are probably use cases where it's not a good fit (or not the best
> fit).
>
>
>
>
>
>
>
>
--
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.
