Hi Pratyoosh, Thanks for attending the FlexJS Webinar. I'm not sure I addressed all of your questions so feel free to start discussion on the mailing list. Now that I'm done with the webinar I can continue this discussion.
On 10/22/13 2:48 PM, "Sharma, Pratyoosh" <pratyoosh.sha...@jpmorgan.com> wrote: >Thanks for your response Alex & Peter, all great perspectives. Here are >my 2 cents: > >On inheriting from panel: does a popup always has a title bar & other >panel decorations? In case of a tooltip the answer is no (If tooltip are >indeed a popup). >Apart from common titlebar bead, I don't see much of a commonality but I >may be missing something & I haven't hard enough of any good arguments to >subclass popup from Panel. When I looked at Popup.js, it looked like it was always creating a titlebar, so I thought you were intending to provide a Panel-like look. But it also makes sense that a base PopUp doesn't need a TitleBar. > >On Peter's code : My thinking was more that popup behavior wasn't a bead >to a container, but a container can be added as a content child to the >popup itself. >I haven't personally worked on applications where a part of view is >inline declared in MXML as a popup container, I am not sure how prominent >that use case is, is it convenient enough to just open a popup from >actionscript? Some folks do like the idea of declaring a popup in MXML, maybe in the fx:Declarations. What isn't clear to me is that there is enough convenience to Popup.createPopup to make it worth having a wrapper class. One alternative is that you create any container or control, mark it as a popup by adding some sort of bead and add it to the display list, and some PopUpManager, if you need one, will manage z order. Another alternative is that the PopUpManager itself has the createPopUp method like we have in the current SDK and it marks the popup and adds it to the right place in the display list. However, this early in the game we can offer several choices and see what folks prefer. > >On the subject of inheritance of Alert control its almost certain a bit >of useless baggage from popup class would make it to Alert by sub >classing but at the same time, I wonder how there can be an alert class >that does not takes advantage of common characteristics from a popup >class like functions to center it in a viewport, determine the optimal >location to open an alert, closing & cleanup logic etc. >Without inheritance we will end up either with a lot of copy/paste of >code or creating quite a lot of beads. >Its tentative how many functions would be common between alert & popup >classes but existing libraries like closure, dojo & ExtJS are good >reference, I am tempted to choose subclassing but again I haven't though >much of arguments against it. Actually, I am thinking we'll create a lot of beads and that would be a good thing. Centering logic might be useful in more places than just popups, for example. Like in some layout classes. Close Buttons appear in other places besides popups. Your thoughts? -Alex
