It still seems like an extra "event" at the very least. User selects, which fires selection change, which fires new place, which then "reselects" the item (the loop ends here since there no selection change would be fired given that the item is already selected).
BUT, in the case of history movement (back/forward), new place is requested, place change is fired, which selects item, which fires selectionchange, which then again goes to new place. How would you not get an extra item on the history stack with this approach? On Thu, Mar 1, 2012 at 9:31 AM, Chris Price <pric...@gmail.com> wrote: > In my example this is caught by the following in > SingleSelectionManager, which traps setting the selected value to be > itself - > > http://code.google.com/codesearch#T04cSGC7sWI/trunk/user/src/com/google/gwt/view/client/SingleSelectionModel.java&q=abstractselectionmodel%20package:http://google-web-toolkit%5C.googlecode%5C.com&l=106 > > However, Jens raises a very good point about the potential downside of > this approach. > > Chris > > On Thu, Mar 1, 2012 at 2:23 PM, Shaun Tarves <sh...@tarves.net> wrote: > > @Thomas - In the example you pointed me to, what prevents this from > > essentially creating an infinite loop? OnSelectionChange fires a new > history > > event. The history handler responds, gets info and changes the selection, > > which would in turn fire a new history event. No? > > > > @Chris - I think it's the same situation...your selection handler fires a > > new place, which selects and item, which would in turn fire a new place > > request. Right? > > > > Am I missing something here? > > > > > > On Thu, Mar 1, 2012 at 5:14 AM, Jens <jens.nehlme...@gmail.com> wrote: > >> > >> You may also want to > >> read: > https://groups.google.com/d/topic/google-web-toolkit/dTwvMbxlFgI/discussion > >> > >> Its not directly related to your problem but as you are firing place > >> changes by listening on the selection model it could happen that your > UI may > >> gets inconsistent. This can happen if you use Activity.mayStop() to > provide > >> warning messages and the user chooses to cancel a place change. Without > >> considering this case your list will have the new item selected > (because you > >> clicked on it and CellList updates the selection model) while your > details > >> view still shows the old item (because the user cancels the place > change). > >> > >> -- J. > >> > >> > >> Am Mittwoch, 29. Februar 2012 14:30:21 UTC+1 schrieb Shaun Tarves: > >>> > >>> Hi all - > >>> > >>> First off, thanks for all the great info on this board. I've gotten so > >>> much out of it. However, I'm having a problem I haven't seen addressed > >>> before. Here's my scenario: > >>> > >>> 1) I have 2 places, 2 separate activity managers/mappers (one for a > >>> "menu" display area and one for "content" display area). > >>> > >>> 2) In the menu area is a basic CellList, with an attached selection > >>> handler that fires an event registered on the app's event bus to go to > a new > >>> place. It also naturally "selects" the item in the menu. > >>> > >>> Selection of items/going to new places works naturally when the user is > >>> clicking around. > >>> > >>> My problem: > >>> > >>> When any history action is involved (via a direct URL or using > >>> back/forward in the browser), how to I handle selecting the > appropriate item > >>> in the menu? > >>> > >>> The obvious choice is a place change handler in the menu, which, in > turn, > >>> uses the menu's selection handler to select the appropriate item. BUT, > since > >>> the selection handler fires an event to go to a new place upon > selection, it > >>> introduces circular logic. (onPlaceChange does setSelected, then > onSelection > >>> fires an event to change places) > >>> > >>> It's disconcerting that none of the sample apps (expenses, > mobilewebapp) > >>> do any kind of item selection when you navigate DIRECTLY to a place > via URL, > >>> but this seems like a really basic feature of a web application. > >>> > >>> Thoughts? > >> > >> -- > >> 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/-/McTGZk-A6DQJ. > >> > >> 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. > > -- > 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.
