An alternative may be to allow something more central than the menu take care of showing and hiding the WidgetPopup:
Let's say you have one main Shell (uibinder for the main layout) You could create a new Event (ShowWidgetpopupEvent) and declare the handler and have the main Shell implement the new handler Then the menu just needs an instance of the eventBus to fire off the new event. and any other component can also show the WidgetPopup by firing the event This may be a little more sound from an Architecture stand point and even then I doubt it is the best. Just depends on how you are implementing everything else (the more sound your app already is, the more sound your implementation can be) On Feb 9, 3:03 pm, Ashton Thomas <[email protected]> wrote: > Yeah should be just fine. Just pass the instance of the widget to the > menu and your good to go. If you use Gin and @Inject the WidgetPopup > and @Inject the view into the WidgetPopup, you will reuse the same > element. so if you close the popup and then reopen it, you data and > stuff will still be there. This could be what you want. If not, you > can always write onClose() code to clear the widget or reset it. > > On Feb 9, 12:33 pm, Ernesto Reig <[email protected]> wrote: > > > > > > > > > A question about architecture... > > Asthon, you said "Then in the activity that calls the popup widget...", and > > my question is: Is it necessary that the popup has to be called by an > > activity? In my case, the popup is called from a MenuItem in a menu bar > > (that is static to the app and never changes), therefore there´s no > > activity. The MenuItem has a command which calls popupWidget.center(); > > > Thank you. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
