Alex, the mxml for my test case looks like this with minimal attributes:
<fx:declarations>
<rs:Alert id="alert" title="myTitle" text="myMessage"
close="handleAlertClose(event)"/>
</fx:declarations>
<s:Button label="show alert" click="alert.open()"/>
For a demo of more attributes, have a look at
http://riastar.github.io/SkinnablePopUpFx/; it contains a code panel that
shows you the required mxml code as you pick values from the UI.
This mxml code is the equivalent of:
var alert = new Alert("myTitle", "myMessage");
alert.addEventListener(PopUpEvent.CLOSE, handleAlertClose);
alert.show();
In Flex 4 the Alert must go in the 'declarations' block because:
a/ the Alert component itself should not be on the displayList yet
b/ the Alert mxml tag is now actually the delegate Carlos was referring to
(i.e. the AlertDelegate class in my implementation) instead of the real
Alert class
Max
On Sun, Jun 9, 2013 at 6:07 AM, Alex Harui <aha...@adobe.com> wrote:
> Sounds interesting. If one of you can sketch out what the MXML would look
> like, it would help clarify what you're thinking.
>
> -Alex
>
> On 6/8/13 12:13 PM, "Maxime Cowez" <maxime.co...@gmail.com> wrote:
>
> >@Carlos: Interesting idea. I had already created a Flex 4 implementation
> >of
> >PopUp / Alert that can be used in a declarative way (see
> >https://github.com/RIAstar/SkinnablePopUpFx). I'll see if I can tweak it
> >to
> >leverage your idea; don't think it should be too hard.
> >Max
> >
> >
> >On Sat, Jun 8, 2013 at 4:30 PM, Carlos Rovira
> ><carlosrov...@apache.org>wrote:
> >
> >> 2013/6/8 Alex Harui <aha...@adobe.com>
> >>
> >> >
> >> > Good point, we forgot about that. It might be possible to use
> >>includeIn
> >> > to defer its instantiation or add some other attribute that works like
> >> > that but isn't tied to states.
> >> >
> >> >
> >> So from your response seems you're thinking in a state implementation
> >> similar to what we have today in flex 4, isn't it?
> >>
> >> Regarding deferred implementation maybe the proposal could be something
> >> like a value object that holds all config properties of the alert dialog
> >> (this will be the example posted by Peter) and the "show" method will be
> >> the one that unchains the process of create the UI Object through a
> >>static
> >> method. So all alerts VOs will be only a proxy that are very light
> >>weight
> >> and only it will pay as you go when calling "show" through delegating
> >>the
> >> work to the class that generates the fat UI object.
> >>
>
>
