On Sunday, December 4, 2011 8:31:48 PM UTC+1, vehdra music wrote: > > On Dec 3, 9:53 pm, Thomas Broyer <[email protected]> wrote: > > If your 3 parts are tightly linked (you have different actions and > > different filters for each different "main content"), given that they're > > displayed next to each other, then you only need one activity. > > > > I'd however try to code them as three distinct "components" (widgets) > > linked only through events (true events with event-handlers using > > addHandler, or simply using callbacks). > > So, for example I will have to create with (or without) UIBinder a > widget for every actions menu or filters menu that I need (dispite of > reusing anyone when I could). For example UsersListActions widget and > UsersListsFilter widget. >
Hard (impossible?) to answer without knowing more about your specific needs, but do the Simplest Thing That Could Possibly Work™ On more doubt. Wich one would be the way to communicate between this > widgets (actions and filters panels) and the current presenter (in my > case, the current activity)? > Your widgets are part of the view, and your presenter is, well, the presenter for the view (you can segregate the widgets behind "sub interfaces"). > That should make it easier maintain > > the whole thing (otherwise your "main content with actions and filters" > > could grow and become unmaintainable) but more importantly, if you think > > you could visually separate them later, that would make it easier (in > that > > event, route the events through the event bus and "you're done"). It > would > > make it possible/easier to reuse one part in different views (e.g. if > > most/all lists have the same set of actions). > > > > I'm afraid there's no "one size fits all" approach; it (in part) depends > > how you imagine your app will evolve. The whole idea of activities are to > > decouple things, it doesn't make sense for things that are tightly > coupled > > (unless they're separated visually into non-adjacent areas). The idea is > > that, for instance, a "main menu", a "list of things" and "details about > > one thing" could all appear on the screen at the same time on a desktop, > > but appear as "sequential screens" on a smart phone (and using MVP within > > an activity, you can in addition decouple the view –wide on a desktop, > > narrower on a smartphone– from the behavior) > > > > To me, however, your current design is clearly not the best (or i > > misunderstood it): why use MainDisplayFilters and MainDisplayActions as > > singletons that you clear/populate each time instead of simply using > > distinct instances in each view? > > I did it in this way because I don't know how can I tell to my > presenter from some widget to perform some action (ie: delete some > users) or how to communicate to the vie. > > For example, on the start method of UserListActivity I make a rpc to > load the users and populate my UsersListViewImpl. IE: How can I tell > to my UsersListsActions widget that there are n users? Or how can I > know from my UsersListsActions widget how many rows are selected in my > UsersListViewImpl? How can I tell from my UsersListsActions to my > UserListPresenter to delete some users? > What I understood is that you're using singletons and when you need them, you tell them "forget everything, and know this is what you should know/do". I'm just saying that instead of singletons and "forget everything", you should create instances that the activity/view *owns* and are initialized once and for all. -- 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/-/pNLumTohzFwJ. 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.
