There is already a static Event.addEventPreview() that delegates through to DOM.addEventPreview() (the idea being that the static DOM methods could be removed eventually). The static event triggering methods are also going on Event and following this pattern. +1, btw, to this whole idea. The EventPreview stuff was really built to support modal dialogs, and it would be very useful to generalize it in the way you propose.
On Wed, Dec 3, 2008 at 4:48 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > Good point! Joel, where are your trigger event methods going? > > > > > On Wed, Dec 3, 2008 at 4:24 PM, John LaBanca <[EMAIL PROTECTED]> wrote: > >> +1 >> >> I think DOM is on its way out. Maybe we can add the method to Window, >> Document, or even Event? >> >> Thanks, >> John LaBanca >> [EMAIL PROTECTED] >> >> >> On Wed, Dec 3, 2008 at 4:19 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >>> >>> Sounds good. I don't do a lot with event preview, but it seems >>> reasonable that it should follow the new event model. >>> >>> On Wed, Dec 3, 2008 at 2:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: >>> > What about deprecating the old DOM.addEventPreview and creating an >>> > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent >>> and >>> > has some specialized methods to stop the event from going down the GWT >>> > preview event chain. >>> > >>> > >>> > >>> > >>> > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> >>> wrote: >>> >> >>> >> > Other Solutions: >>> >> > ============ >>> >> > We considered passing the event preview down the existing stack of >>> >> > EventPreview, which fixes the problem for more than just >>> PopupPanels. >>> >> > However, we think this approach is overkill because the problem >>> really >>> >> > doesn't manifest itself in other widgets. >>> >> >>> >> What about GlassPanel in the Incubator? Sounds like throwing a >>> >> GlassPanel into the mix would break things since it isn't a subclass >>> >> of PopupPanel and does it's own event previewing. >>> >> >>> >> >>> >> On Wed, Dec 3, 2008 at 1:56 PM, John LaBanca <[EMAIL PROTECTED]> >>> wrote: >>> >> > Contributors - >>> >> > >>> >> > Summary: >>> >> > ======== >>> >> > In the current implementation of PopupPanel, a PopupPanel with >>> autoHide >>> >> > enabled will not autoHide if another Widget (such as another >>> PopupPanel) >>> >> > steals the event preview. In practice, this means that if a >>> PopupPanel >>> >> > is >>> >> > opened on top of an autoHide PopupPanel, the autoHide PopupPanel >>> will no >>> >> > longer autoHide. >>> >> > >>> >> > Consider an example where you have a SuggestBox inside of a >>> PopupPanel >>> >> > that >>> >> > is autoHide. If you start typing in the SuggestBox, it opens a >>> >> > PopupPanel >>> >> > of suggestions. You then click outside the original popup and >>> expect it >>> >> > to >>> >> > disappear. Instead, only the SuggestBox popup disappears. In this >>> >> > case, >>> >> > the PopupPanels are related, but in some cases they are not. If you >>> use >>> >> > a >>> >> > sticky PopupPanel (stays open for a while, ex. a debug menu or log) >>> in >>> >> > your >>> >> > app, it may steal preview from an autoHide PopupPanel, and you have >>> to >>> >> > close >>> >> > one to close the other. >>> >> > >>> >> > >>> >> > Proposed Solution: >>> >> > ============== >>> >> > I propose that we add a static stack of PopupPanels to the >>> PopupPanel >>> >> > class. As popups are shown and hidden, they are added and removed >>> from >>> >> > the >>> >> > stack. When a popup recieves an event preview, it passes the event >>> down >>> >> > the >>> >> > stack and lets each PopupPanel preview it UNTIL it reaches a >>> PopupPanel >>> >> > that >>> >> > is modal. The first modal PopupPanel (which blocks events by >>> >> > definition) >>> >> > will end the event preview chain. >>> >> > >>> >> > >>> >> > Example: >>> >> > ======= >>> >> > Consider the following stack of PopupPanels, where the top panel is >>> the >>> >> > last >>> >> > one that is opened: >>> >> > popup6 (autoHide) >>> >> > popup5 >>> >> > popup4 (autoHide) >>> >> > popup3 (autoHide) >>> >> > popup2 (modal) >>> >> > popup1 (autoHide) >>> >> > popup0 (modal) >>> >> > >>> >> > Now lets say you click on popup4: >>> >> > 1. Popup6 previews the event. AutoHide is enabled, so it will hide. >>> >> > (NOTE: >>> >> > usually, only popup6 gets to preview the event) >>> >> > 2. Popup5 previews the event. Neither autoHide nor modal is >>> enabled, so >>> >> > ignore it. >>> >> > 3. Popup4 previews the event. AutoHide is enabled, but the event >>> >> > occured >>> >> > over Popup4, so it is ignored. >>> >> > 4. Popup3 previews the event. AutoHide is enabled, so it will hide. >>> >> > 5. Popup2 previews the event. Modal is enabled, so it ends the >>> chain. >>> >> > >>> >> > Popup1 and Popup0 never preview the event, so they both remain open. >>> >> > >>> >> > >>> >> > Other Solutions: >>> >> > ============ >>> >> > We considered passing the event preview down the existing stack of >>> >> > EventPreview, which fixes the problem for more than just >>> PopupPanels. >>> >> > However, we think this approach is overkill because the problem >>> really >>> >> > doesn't manifest itself in other widgets. >>> >> > >>> >> > Thanks, >>> >> > John LaBanca >>> >> > [EMAIL PROTECTED] >>> >> > >>> >> > > >>> >> > >>> >> >>> >> >>> > >>> > >>> > >>> > -- >>> > "There are only 10 types of people in the world: Those who understand >>> > binary, and those who don't" >>> > >>> > > >>> > >>> >>> >>> >> >> >> >> > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
