I definitely like the idea of declaring Popups in MXML instead of ActionScript.
However, there is a downside to your approach, because it induces some code redundancy: the popup management (modal, parent, adding/removing to PopupManager, centering, etc...) must be pushed to the Popup component itself, so that it can be used. I prefer the more loosely coupled approach used in PopupAnchor, where it's the PopupAnchor that manages all the popup behavior (modal, parenting, adding/removing to PopupManager, centering, etc...). IMO it has the following benefits: - no code redundancy, easier maintenance - you can popup just anything that is enclosed in PopupAnchor ( Panel, Titlewindow, Callout, Toaster, Group, Button...) . - you can add new popup behavior (eg. Transitions effects) to PopupAnchor and all your popups will benefit from it. The downsides are the following: - it's more verbose: you need two embedded tags instead of one, to achieve the same result. That's the price of flexibility - the PopupAnchor must be child of it's parent (eg. Button). I would prefer it to be independent and be in the <fx:Declarations> section, and have an explicit optional "parent" property. That's how Parsley's Popup work (see below). ------ PS: to say the truth, I am not using PopupAnchor but a variant of it, called "Popup" that is part of Cairngorm/Parsley, because it's IOC aware, but it's the same idea: <parsley:PopUp id="createComponentPopup" modal="true" open="{model.editDialogPM.showDialog}" paren="{someButton}" > <my:MyComponent id="createComponentDlg"/> </parsley:PopUp> What do you think? Maurice -----Message d'origine----- De : Maxime Cowez [mailto:maxime.co...@gmail.com] Envoyé : vendredi 11 octobre 2013 12:23 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark Alert implementation > What's the difference between you new SkinnablePopup and the existing SkinnablePopupContainer ? It's how SkinnableComponent compares to SkinnableContainer, but for popups. So it allows you to create custom popups without having to wrap them in a SkinnablePopUpContainer or a PopUpAnchor. >From a pragmatic point of view it allows you to do things like this: <fx:Declarations> <rs:Alert id="alert" title="Hello world" text="Are you sure you wish to say hello?"/> </fx:Declarations> <s:Button label="Say hello" click="alert.open()"/> As another example implementation of SkinnablePopUp (besides Alert) I've created a Toaster class (you know, messages that pop up and stack up in a corner of the screen for a few seconds), which can be used like this: <fx:Declarations> <rs:Toaster id="toaster" width="150" bottom="20" right="20"/> </fx:Declarations> <s:Button label="Say hello" click="toaster.toast('Hello there from the Toaster')"/> M On Fri, Oct 11, 2013 at 11:34 AM, Maurice Amsellem < maurice.amsel...@systar.com> wrote: > BTW, I like the idea of the mxml based Alert (in addition to AS script > API) :-) > > Maurice > > -----Message d'origine----- > De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] > Envoyé : vendredi 11 octobre 2013 11:31 À : dev@flex.apache.org Objet > : RE: FLEX-33806 and spark Alert implementation > > Hi Maxime, > > What's the difference between you new SkinnablePopup and the existing > SkinnablePopupContainer ? > > Maurice > > -----Message d'origine----- > De : Maxime Cowez [mailto:maxime.co...@gmail.com] Envoyé : vendredi 11 > octobre 2013 11:25 À : dev@flex.apache.org Objet : Re: FLEX-33806 and > spark Alert implementation > > I've been working on a Spark implementation of Alert, which I've > discussed on this list before (see > http://apache-flex-development.2333347.n4.nabble.com/DISCUSS-Alerts-an > d-dialogs-in-Flex-4-x-Spark-was-Alerts-and-dialogs-in-FlexJS-td27595.h > tml > ). > Unlike the current experimental implementation - which is a port of > the old mx Alert - it's rewritten from scratch. > I've been meaning to integrate it with the existing implementation so > that its API would be more or less backwards compatible and then > submit it as a patch, but haven't had a shred of spare time these last > few months :( > > What's a bit different in my approach is that Alert extends > SkinnablePopUp (which is a new base class, and hence Alert is no > longer a SkinnableContainer). SkinnablePopUp can be extended and/or > skinned any which way you want and offers total flexibility, whereas > Alert is a default implementation with a few SkinParts. > I used these SkinParts: > > [SkinPart(required="true")] > public var textDisplay:IDisplayText; > > [SkinPart(required="false")] > public var titleDisplay:IDisplayText; > > [SkinPart(required="false")] > public var commitButton:IVisualElement; > > [SkinPart(required="false")] > public var discardButton:IVisualElement; > > [SkinPart(required="false")] > public var cancelButton:IVisualElement; > > [SkinPart(required="false")] > public var iconDisplay:BitmapImage; > > Only 'textDisplay' is required since an Alert without a message > doesn't make much sense; the others are optional. > > Max > > > > On Fri, Oct 11, 2013 at 9:34 AM, Maurice Amsellem < > maurice.amsel...@systar.com> wrote: > > > >Simplification tends to remove flexibility. Spark components are > supposed > > >to leave control of all visuals to the skin designer. For example, can > > >the custom skin designer swap out a messageDisplay that does plain > > >text > > with one that does rich text? > > > > If you replace plain text with rich text, it's not only a skin > > design change in my sense, because you are also changing the > > behavior (you have to change to calling code as well). > > Yet, you can do it by subclassing Alert to RichAlert and just swap > > the content and override one of the static methods to use your RichText. > > With the previous implementation, you could replace the skin part > > with RichText in the skin, but you will still have to subclass Alert > > to set the richText correctly. > > > > The problem here is that it's not a Skinnable Component but a > > Skinnable Container. > > It's different because Skinnable containers content is part on the "data" > > and not of the skin. > > It's not clear to me if changes in the content of > > SkinnableContainers should be set as skinParts and moved to the skin > > (and disabling the content > > skinpart) > > or just overriding the content in a subclass of the container. > > > > What do you think? > > > > Maurice > > > > -----Message d'origine----- > > De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 11 > > octobre > > 2013 06:26 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark > > Alert implementation > > > > > > > > On 10/10/13 7:20 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > > > > >Hi, > > > > > >Being an experimental component I think just about any improvement > > >is a good idea. > > I agree with that statement, but is removing skinparts a "good idea"? > > Simplification tends to remove flexibility. Spark components are > supposed > > to leave control of all visuals to the skin designer. For example, can > > the custom skin designer swap out a messageDisplay that does plain > > text with one that does rich text? > > > > Getting rid of monkey patching PanelSkin sounds like a good idea though. > > And defaulting to BitmapImage and plain text. > > > > Have fun, > > -Alex > > > > >