Maintaining application state

[Ryan]

Hello everyone,

I'm a little new to GWT, but I'm a quick study, and I've written a
small application using some of the fun new concepts, such as MVP,
GIN, Command-pattern-based RPC, and Activity and Places.

One question I have is how best to maintain application state in the
client (prefer the server to be as sessionless as possible). For
example, when I login* I need to store the username somewhere. It may
get used in various other views, and possibly also on logout. I don't
want to store it in the "presenter" (read: Activity) for the login
page, because that object should be destroyed after the user logs in
and arrives at the initial home page of the app. Likewise I would not
want to store it in the view, since it could be reused elsewhere. So
where should I store it?

One suggestion I've seen several times is a variation of using a
client-side singleton "catch all" class where things can be stored,
sort of like session-scoped map of attribute in a servlet. Is this
the best way to do it? What other patterns or approaches would you
suggest?

Many thanks!
Ryan

* I probably wouldn't use GWT for login credentials in a real
production app, but instead use a 3rd-party security framework like
Spring Security. But this is a hypothetical example and could apply
to any number of types of application state.

[Jens]

On client side I am working with a singleton that can be injected via gin everywhere I need these kind of login information. Works fine so far.

-- J.

[Ben Imp]

I use an object called ApplicationModel, that is passed to every presenter on creation.  It stores application state, as its name might suggest.  It also fires off events whenever any of the presenters modifies one of its values, which helps keep the application in sync.  Things like user roles and what the user has currently selected are stored in there.

I should also mention that the ApplicationModel is actually handed off to the presenter as part of an ApplicationBundle, which is basically just a parameter object.  It holds the model, the ApplicationNavigationControl, ApplicationEventBus, ApplicationFactory, etc.  Wrapping it all up in the parameter object makes it really easy to add new application-wide bits.

-Ben

[Ryan]

Mmm, very interesting idea, Ben. I was already a little distressed
that my Activity constructors are getting large (5+ parameters).
Bundling them up into an ApplicationBundle object is appealing.
Although since I'm using Gin, I guess the constructor size isn't
really a problem.

Do you use this ApplicationBundle object to pass presenter-specific
information? I.e., a specific view or place provider? If so, how do
you parameterize the bundle to work for all presenters?

Ryan

[Ben Imp]

The bundle is presenter-agnostic.  It only contains application-wide state and control objects.

I do have two classes of presenters in my application, however.  Those that get passed the ApplicationBundle are page presenters, and control the whole screen (or at least the central content portion of it anyway).  They are created in response to navigation events.  These, in turn, may create component presenters and pass them specific bits of information, like an instance of their view that was retrieved from somewhere in the main page view interface, or a specific implementation of their model interface that will play well with the rest of the page.

Something like this:

public XxxPagePresenter(ApplicationBundle bundle, XxxPageView view) {
        this.bundle = bundle;
        this.view = view;
        this.model = new XxxPageModelImpl();
        this.yyyComponentPresenter1 = new YyyComponentPresenter(model.getYyyComponentModel(), view.getYyyComponentView());
        ...
}

-Ben

[Ashton Thomas]

I do something kinda similar. I make the assumption that a Place
object should store all the state/data for the particular place. I
then have something called a ContextWatcher which controls any
application wide state or data. I use a static Cache class to actually
store any data.

The impl also makes it very easy to rebuild application state from a
refresh or bookmark

Everything is controlled by a PlaceChangeEvent. So, on a PCE the new
Activity (ActivityMapper calles setPlace(NewPlace) - which makes the
start() method somewhat irrelevant but allows the same place to be
called consecutively and have new params for each place) and
ContextWatcher (implements PCE.Handler) so both have a reference to
the new Place. The Activity adds an a callback to the place
(addOnValidCallback - other objects which need to know when the Place
and AppWide info is valid) and the ContextWatcher adds a callback to
the place for onContextCheck (basically the place will make sure it
has the necessary data it needs then hands control over to the
ContextWatcher. The ContextWatcher does its thing and then calls
place.startOnValidCallbacks. The place will then go through all
callbacks that need to know everything is valid (The activity and any
other object that have been put on hold)

The method has been working extremely well for keeping Application
State, Place specific data, Refresh, Bookmark, Caching etc

It does add some custom complexity to the mix and slightly changes the
way an activity is started but has proved well worth it.

on a PCE the place will take the String token given to its constructor
and then check to make sure the Client Cache has all the necessary
data (retrieving it when needed).

[Alisson Prestes]

I am storing the information in the Client Factory.

Alisson Prestes

www.google.com/profiles/javalisson

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.