Aw: Maintaining application state
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. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/ATC609dohsAJ. 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: Maintaining application state
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 -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/51lt6kbjjoQJ. 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: Maintaining application state
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 On Jun 10, 6:37 am, Ben Imp benlee...@gmail.com wrote: 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 -- 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: Maintaining application state
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
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/aZpqp1HwcwwJ.
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: Maintaining application state
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).
On Jun 10, 2:08 pm, Ben Imp benlee...@gmail.com wrote:
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
--
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: Maintaining application state
I am storing the information in the Client Factory.
Alisson Prestes
www.google.com/profiles/javalisson
On Fri, Jun 10, 2011 at 4:00 PM, Ashton Thomas ash...@acrinta.com wrote:
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).
On Jun 10, 2:08 pm, Ben Imp benlee...@gmail.com wrote:
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
--
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.
--
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.
Maintaining application state
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. -- 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.
