Hi Carlos, Thanks for bringing this up. The plan is to change the popup implementation, but it isn't completely settled on how, so any input is welcome.
In FlexJS, the Application is not a display object. That's because it encourages you to separate your views from other code, and because it didn't make sense to tie the JS Application to <Body>. So, generally, you will have a main View. It will not be the SWF root in AS, and it will probably be the <Body> in JS. My current thinking is that Popups will just get added to the main view via addToParent() but marked as a popup. That allows you to plug-in different popupmanagers that manage child order based on different strategies. Simple apps don't really need a popupmanager at all unless they have non-modal floating windows, and simple apps don't have to carry around all the MDI overlapping windows code either. So, I think the View will parent the popup and events will bubble up to the View. But this is not set in stone yet. Much more prototyping and input is needed. -Alex On 6/7/13 3:08 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote: >The thread opened by Peter about Alert, is very interesting since there's >some question about underlying Popups in actual Flex 4 that I will like to >see if can be enhanced in FlexJS. Maybe others could thing are ok with >actual implementation, so for this reason is better to discuss a bit. > >One legacy thing about PopUps in Flex that I think should be discussed is >the location in displaylist tree. Actualy we have sys manager as root and >the Application and then 1..n popups as childrens. This make difficult >sometimes to handle events since popups are separated from the application >that usualy launch it. For example in MVC frameworks like Swiz this break >general management of events (that use to bubble) since popups does not >find the dispatcher necessary for your code to work. > >Other issue is that actualiy is more easy implement an MDI system in the >Application layer domain that in Popups zone, but at the price that you >loose activation/desactivation feature (and it's skin representation). > >So what do you think. A new implementation should be in the same tree >structure pattern or you think this could be changed to other >implementation?
