Hi Alex, Sorry I missed the inline responses. Reading your response & Peter's I am better enlightened :D I will refractor the code & advice when it's in a state where its near ready, I guess popup class would vanish now.
Tabcatcher is for catching the tab key & distributing focus to the popup children rather than the background stuff, it's a more vanity thing but I need it for something I am trying to do. Thanks, Pratyoosh -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Thursday, October 24, 2013 12:26 PM To: dev@flex.apache.org Subject: Re: [FlexJS] PopUp implementation Hi Pratyoosh, I had replied to various portions of your email in my previous reply. Not sure if you saw that or not. Are you ok with my checking in everything except for the change to Alert? What is a "tabcatcher"? Thanks, -Alex On 10/24/13 7:49 AM, "Sharma, Pratyoosh" <pratyoosh.sha...@jpmorgan.com> wrote: >Hi Alex, > >Great webinar indeed, it was very refreshing to see the level of >interest. > >Back to my email >On inheriting from panel: does a popup always has a title bar & other >panel decorations? In case of a tooltip or callout 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. > >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? > >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, Thoughts.... > >It would be great if this code atleast is added to some experimental >components folders until it can be refactored & standardized. > >I will most probably work on tabcatcher, tooltip & callout classes next... > > >Thanks, >Pratyoosh >-----Original Message----- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Thursday, October 24, 2013 1:56 AM >To: dev@flex.apache.org >Subject: Re: [FlexJS] PopUp implementation > >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 > > >This email is confidential and subject to important disclaimers and >conditions including on offers for the purchase or sale of securities, >accuracy and completeness of information, viruses, confidentiality, >legal privilege, and legal entity disclaimers, available at >http://www.jpmorgan.com/pages/disclosures/email. This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
