On 30 nov, 06:28, zixzigma <zixzi...@gmail.com> wrote: > Thank you for your comments. > > >>So you would have one main activity for each major area with one view > >>and could have multiple widgets that accomplish what your individual > >>activities could? > > I had thought about this, but my concern is by doing so, we lose the > navigation/history/bookmarking. > > in the case of West Region having West North, West Main and West > South, > lets say we place three widgets in the West Region, and treat the > entire region as a single activity, > > when we click an item in one of the regions (West Main for example), > selection of an item fires an event on eventBus, > the widget in West South is listening for this event, and upon > receiving, > populates itself with contextual data related to item selected in West > Main, however > since we are not using activities and places, the history token doesnt > get updated, > and we lose the history which results in poor/broken navigation. > > more over, since we are not using Activities/Places for these sub- > regions (west_north, west_main, west_south), > we can not use placeController.go(new place), for communicating > events, and have to resort to manually creating event handling > (GwtEvent, etc)
navigation != business event. If you want navigation, then use places, and in your activitymapper for the "west" display region, then return a new activity (with the same 3 widgets, just different data on them). Or if you think it could be too resource-consuming (e.g. could lead to many RPC requests just to show the very same information as before, in the sub-regions that didn't change) then you could keep a reference on the "current" activity (in the activitymapper) and "update" it with the new place. But for "side" regions, I wonder why you want it to be part of navigation... when there's a "main region", navigation generally is tied to this region, and the rest is either contextual to the main region (i.e. determined by the place) or tied by business events exchanged between the components (or a mix of both). > "What about apps with multiple panels in the same window whose state > should all be saved together in a single URL? GWT 2.1 does not attempt > to provide a generic implementation of a composite Place; however, > your app could create a CompositePlace, CompositeActivity, and > CompositePlace.Tokenizer classes that delegate to the constituent > members. In this case, only the composite objects would need to be > registered with your app's ActivityMapper and PlaceHistoryMapper." > > do you have any idea on CompositePlace , its relation to Composite > Activity, and how we can map a Composite Place to its corresponding > Activities ? Having briefly talked about it with Ray Ryan, the idea is to split the history token in several parts that you then detokenize as if they were inidividual places. The CompositePlace would then (to be generic, adapt to your own needs) model an array of places. I for one don't buy this idea; I haven't yet met an app where I'm not "doing something" or "looking at something", and that's the definition of a place. I'm not "looking at something on the left and doing something totally unrelated on the right" (that's what a 'composite place' would model). That being said, I'm not working at Google, and I'm not a UX expert; so please consider that as my very own opinion. Yours might of course be different. (and activities and places don't aim at addressing every use case, only the ones that make 90% or more of web apps) -- 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-tool...@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.
