Maxime, >However some components will always be popups and are not intended to be used >any other way. Some examples are Alert, Toaster, CallOut, and >DropDownListBase's list. I agree with you. Alert is a Popup on its own, and it's a "low level" component, so it should not need a second tag to be used.
>If you want to entirely remove the redundancy around the creation/destruction >of popups, then that logic should also be encapsulated and reused (something >like the >existing DropDownController, but in a more generic way). I think the idea of PopupController (the equivalent of DropDownController) for popups is *excellent* as it will certainly help reduce the code redundancy and make it more consistent. I don't know what the design pattern is for that (Delegate?) > A PopUp tag that can be used inside "declarations" seems like a reasonable > compromise. However I'm unsure as to whether it'll actually solve the > redundancy issue: it'll be yet another class that manages popups as well. Unless it uses the PopupController :-) Regards, Maurice -----Message d'origine----- De : Maxime Cowez [mailto:maxime.co...@gmail.com] Envoyé : vendredi 11 octobre 2013 17:40 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark Alert implementation I absolutely agree about the code redundancy. However at this moment it is already all over the place. Alert, SkinnablePopUpContainer, PopUpAnchor, DropDownListBase and perhaps some other classes I'm not thinking of, all have their own ways of displaying and positioning popups. And - as you pointed out - none of them offers absolute positioning. To be honest, I often find PopUpAnchor's positioning rules confusing. This is why I created 'IPopUpPosition' as an interface for classes that want to position a popup in a certain way (current implementors are PopUpCenteredPosition and PopUpAbsolutePosition). If you want to entirely remove the redundancy around the creation/destruction of popups, then that logic should also be encapsulated and reused (something like the existing DropDownController, but in a more generic way). Of course this touches on so many classes that I didn't dare venture down that road. A PopUp tag that can be used inside "declarations" seems like a reasonable compromise. However I'm unsure as to whether it'll actually solve the redundancy issue: it'll be yet another class that manages popups as well. I'd also like to bring a semantic argument to the table: SkinnablePopUpContainer and PopUpAnchor offer excellent means of popping up views in a decoupled way. If ever I decide that MyForm, which is currently displayed through a popup, must be used as a regular view, then I can easily do so without touching MyForm's code. However some components will always be popups and are not intended to be used any other way. Some examples are Alert, Toaster, CallOut, and DropDownListBase's list. If you are then allowed to write something like: <fx:Declarations> <!-- myAlert.open() to open --> <s:PopUp id="myAlert"> <s:Alert/> </s:PopUp> </fx:Declarations> That's confusing, because Alert *is *a popup. You can not embed it somewhere in regular view. <fx:Declarations> <!-- myAlert.open() to open --> <s:SkinnablePopUpContainer id="myAlert"> <s:Alert/> </s:SkinnablePopUpContainer> </fx:Declarations> Wouldn't make any sense,because Alert already has a Skin of its own. (This scenario makes perfect sense for MyForm though, because the form's popup chrome is decoupled from the actual form) <fx:Declarations> <!-- myAlert.open() to open --> <s:Alert id="myAlert" /> </fx:Declarations> Conveys the idea that Alert is a component in its own right that is always used as a popup. Bottom line: I think there is a place for something like SkinnablePopUp as a base class, but the actual creation/destruction/positioning behavior should be encapsulated and reused by other popup components. M On Fri, Oct 11, 2013 at 1:13 PM, Maurice Amsellem < maurice.amsel...@systar.com> wrote: > 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 > > > > > > > > >