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:[email protected]]
Envoyé : vendredi 11 octobre 2013 12:23
À : [email protected]
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 <
[email protected]> 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:[email protected]]
> Envoyé : vendredi 11 octobre 2013 11:31 À : [email protected] 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:[email protected]] Envoyé : vendredi 11
> octobre 2013 11:25 À : [email protected] 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 <
> [email protected]> 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:[email protected]] Envoyé : vendredi 11
> > octobre
> > 2013 06:26 À : [email protected] Objet : Re: FLEX-33806 and spark
> > Alert implementation
> >
> >
> >
> > On 10/10/13 7:20 PM, "Justin Mclean" <[email protected]> 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
> >
> >
>
