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 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
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 ma
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
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 Ap
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
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 visi
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 se
