You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Peter Ent <pe...@adobe.com> on 2013/06/07 21:52:29 UTC
[DISCUSS] Alerts and Dialogs in FlexJS
Hi,
I'm currently working on the Alert dialog for FlexJS. Alex and I have been discussing options regarding event handling from the Alert dialog which could provide a pattern for future dialogs. We thought it would been good to get some opinions.
In Flex you normally post an Alert dialog using Alert.show() and pass it a closeFunction. The returned Alert instance can be used to listen for events for whatever else you want to do with it. The closeFunction is optional as you can also listen for events.
We thought of these possibilities:
Events: make the FlexJS Alert work the same - create an Alert instance and then listen for events.
Delegate pattern: register an object (probably the instance that is posting the Alert) as a delegate and implement one or more callbacks. This is how you would do it in iOS, for example.
Declare in MXML, something like this:
<fx:Declarations>
<basic:Alert id="foo" title="Panic" message="Yowza!" ok="doSomething()" cancel="doSomethingElse()" />
</fx:Declarations>
These are not mutually exclusive by any means.
Thoughts? Preferences?
Peter Ent
Flex SDK Team
Adobe Systems
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Maxime Cowez <ma...@gmail.com>.
I'd like to reply to some questions asked in this thread, but we seem to
have moved away from the original question too much. So I'll start a new
one to do so.
M
On Mon, Jun 10, 2013 at 4:59 PM, Christophe Herreman <
christophe.herreman@gmail.com> wrote:
> Hi Peter,
>
> 2013/6/10 Peter Ent <pe...@adobe.com>
>
> > One of the things I have disliked about Flex is the over-complication of
> > some things. The majority of the time I think most developers are looking
> > for a quick alert to the user (with a message and a button to dismiss the
> > alert) and a question with two or three choices. Adding multiple buttons,
> > other content (other than the message and title), and such seems, to me,
> > to belong in another class and not in Alert. This is the general
> > philosophy of FlexJS - keep it simple and light and add in only what you
> > need.
> >
>
> This assumption is subjective and not valid in my personal experience. In
> most cases we used alerts to prompt the user to respond to an action. The
> outcome was a YES/NO (or variations). A simple OK alert was certainly also
> used, but not as frequent.
>
> I agree that things should be simple though and that Alert might be a very
> specific type of user prompt with limited/no modification possibilities.
> The behavior you describe could also just be the default behavior.
>
>
> >
> > My question for this discussion was about getting the 'result' of the
> > Alert - through events or via a delegate. Alex had also suggested to me
> > the possibility of declaring an Alert in MXML which can be fine, but if
> > the Alert has 3 buttons for one case and 1 button for another, then the
> > MXML needs to be able to handle this. Having a single event with the
> > button flag would take care that case:
> >
> > <fx:Declarations>
> > <basic:Alert id="alert1" message="Out of Time" title="Error"
> flags="4"
> > close="handleAlert1Close(event)" />
> > <basic:Alert id="alert2" message="Are you sure?" title="Confirm"
> > flags="3" close="handleAlert2Close(event)" />
> > </fx:Declarations>
> >
> > Based on what I've read, the delegate pattern isn't all that familiar to
> > Flex folks so I'll go with events and include the flag of the button that
> > was selected.
> >
>
> Apologies if I diverted from the original question. The event approach
> seems to me like the most obvious/intuitive one.
>
>
> >
> > For more complex presentations we can figure out something that satisfies
> > those criteria.
> >
> > Thanks for your input.
> > Peter Ent
> > Flex SDK Team
> > Adobe Systems
> >
> > On 6/10/13 5:09 AM, "Christophe Herreman" <christophe.herreman@gmail.com
> >
> > wrote:
> >
> > >Regarding the buttons, I would find the following interesting:
> > >
> > >- option to define the order in which the buttons appear (e.g. Mac vs
> > >Windows [1]). The flags approach doesn't work for this, so perhaps
> replace
> > >this by an array.
> > >- extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ...
> > >- custom buttons: you can localize the built-in ones, but what if you
> want
> > >another semantic meaning for a button. A question here is how you handle
> > >the click/selection of a custom button.
> > >- have predefined combinations of buttons, similar to .NET's
> > >MessageBoxButtons [2]
> > >
> > >regards,
> > >Christophe
> > >
> > >[1] http://www.nngroup.com/articles/okndashcancel-or-cancelndashok/
> > >[2]
> > >
> >
> http://msdn.microsoft.com/en-us/library/system.windows.forms.messageboxbut
> > >tons.aspx
> > >
> > >
> > >2013/6/10 Alex Harui <ah...@adobe.com>
> > >
> > >>
> > >>
> > >> On 6/9/13 1:45 PM, "Carlos Rovira" <ca...@codeoscopic.com>
> > >>wrote:
> > >>
> > >> >Hi Maxime,
> > >> >
> > >> >very cool alert spark implementation. I was navigating the source
> code
> > >>and
> > >> >have mainly a question about buttons. The eligible buttons in your
> > >>version
> > >> >are 3 (commit, discard and cancel). In mx alert we have different
> > >>options
> > >> >(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
> > >> >considered as well passing styles from a moduleFactory?
> > >> Interesting. Makes me wonder if Alert should be a container for a set
> > >>of
> > >> buttons of your choosing.
> > >>
> > >> FlexJS will have a minimum of two Alert classes: a simple one that is
> > >> essentially the JS alert() call, and then something that has a choice
> of
> > >> buttons more like mx:Alert. But it could be a container, I suppose.
> > >>
> > >> I'm not quite sure what is a "delegate" about this version of
> Alert.as.
> > >> Also, it still gets instantiated at startup if it is in the
> > >> fx:Declarations as Carlos pointed out, doesn't it?
> > >> >
> > >> >I think the declaration you provided is what Alex was askin for,
> > >>nothing
> > >> >to
> > >> >add for my side. I like as well the SkinnablePopUp, something that
> > >> >complements the SkinnablePopUpContainer counterpart.
> > >> >
> > >> >You have plans to integrate with the rest of spark components?
> > >> >
> > >> >Thanks
> > >> >
> > >> >Carlos
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >2013/6/9 Maxime Cowez <ma...@gmail.com>
> > >> >
> > >> >> 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 <ah...@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" <ma...@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
> > >> >> > ><ca...@apache.org>wrote:
> > >> >> > >
> > >> >> > >> 2013/6/8 Alex Harui <ah...@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.
> > >> >> > >>
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> >--
> > >> >Carlos Rovira
> > >> >Director de Tecnología
> > >> >M: +34 607 22 60 05
> > >> >F: +34 912 94 80 80
> > >> >http://www.codeoscopic.com
> > >> >http://www.directwriter.es
> > >> >http://www.avant2.es
> > >>
> > >>
> > >
> > >
> > >--
> > >Christophe Herreman
> > >http://www.herrodius.com
> > >http://www.springactionscript.org
> > >http://www.as3commons.org
> >
> >
>
>
> --
> Christophe Herreman
> http://www.herrodius.com
> http://www.springactionscript.org
> http://www.as3commons.org
>
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Christophe Herreman <ch...@gmail.com>.
Hi Peter,
2013/6/10 Peter Ent <pe...@adobe.com>
> One of the things I have disliked about Flex is the over-complication of
> some things. The majority of the time I think most developers are looking
> for a quick alert to the user (with a message and a button to dismiss the
> alert) and a question with two or three choices. Adding multiple buttons,
> other content (other than the message and title), and such seems, to me,
> to belong in another class and not in Alert. This is the general
> philosophy of FlexJS - keep it simple and light and add in only what you
> need.
>
This assumption is subjective and not valid in my personal experience. In
most cases we used alerts to prompt the user to respond to an action. The
outcome was a YES/NO (or variations). A simple OK alert was certainly also
used, but not as frequent.
I agree that things should be simple though and that Alert might be a very
specific type of user prompt with limited/no modification possibilities.
The behavior you describe could also just be the default behavior.
>
> My question for this discussion was about getting the 'result' of the
> Alert - through events or via a delegate. Alex had also suggested to me
> the possibility of declaring an Alert in MXML which can be fine, but if
> the Alert has 3 buttons for one case and 1 button for another, then the
> MXML needs to be able to handle this. Having a single event with the
> button flag would take care that case:
>
> <fx:Declarations>
> <basic:Alert id="alert1" message="Out of Time" title="Error" flags="4"
> close="handleAlert1Close(event)" />
> <basic:Alert id="alert2" message="Are you sure?" title="Confirm"
> flags="3" close="handleAlert2Close(event)" />
> </fx:Declarations>
>
> Based on what I've read, the delegate pattern isn't all that familiar to
> Flex folks so I'll go with events and include the flag of the button that
> was selected.
>
Apologies if I diverted from the original question. The event approach
seems to me like the most obvious/intuitive one.
>
> For more complex presentations we can figure out something that satisfies
> those criteria.
>
> Thanks for your input.
> Peter Ent
> Flex SDK Team
> Adobe Systems
>
> On 6/10/13 5:09 AM, "Christophe Herreman" <ch...@gmail.com>
> wrote:
>
> >Regarding the buttons, I would find the following interesting:
> >
> >- option to define the order in which the buttons appear (e.g. Mac vs
> >Windows [1]). The flags approach doesn't work for this, so perhaps replace
> >this by an array.
> >- extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ...
> >- custom buttons: you can localize the built-in ones, but what if you want
> >another semantic meaning for a button. A question here is how you handle
> >the click/selection of a custom button.
> >- have predefined combinations of buttons, similar to .NET's
> >MessageBoxButtons [2]
> >
> >regards,
> >Christophe
> >
> >[1] http://www.nngroup.com/articles/okndashcancel-or-cancelndashok/
> >[2]
> >
> http://msdn.microsoft.com/en-us/library/system.windows.forms.messageboxbut
> >tons.aspx
> >
> >
> >2013/6/10 Alex Harui <ah...@adobe.com>
> >
> >>
> >>
> >> On 6/9/13 1:45 PM, "Carlos Rovira" <ca...@codeoscopic.com>
> >>wrote:
> >>
> >> >Hi Maxime,
> >> >
> >> >very cool alert spark implementation. I was navigating the source code
> >>and
> >> >have mainly a question about buttons. The eligible buttons in your
> >>version
> >> >are 3 (commit, discard and cancel). In mx alert we have different
> >>options
> >> >(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
> >> >considered as well passing styles from a moduleFactory?
> >> Interesting. Makes me wonder if Alert should be a container for a set
> >>of
> >> buttons of your choosing.
> >>
> >> FlexJS will have a minimum of two Alert classes: a simple one that is
> >> essentially the JS alert() call, and then something that has a choice of
> >> buttons more like mx:Alert. But it could be a container, I suppose.
> >>
> >> I'm not quite sure what is a "delegate" about this version of Alert.as.
> >> Also, it still gets instantiated at startup if it is in the
> >> fx:Declarations as Carlos pointed out, doesn't it?
> >> >
> >> >I think the declaration you provided is what Alex was askin for,
> >>nothing
> >> >to
> >> >add for my side. I like as well the SkinnablePopUp, something that
> >> >complements the SkinnablePopUpContainer counterpart.
> >> >
> >> >You have plans to integrate with the rest of spark components?
> >> >
> >> >Thanks
> >> >
> >> >Carlos
> >> >
> >> >
> >> >
> >> >
> >> >2013/6/9 Maxime Cowez <ma...@gmail.com>
> >> >
> >> >> 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 <ah...@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" <ma...@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
> >> >> > ><ca...@apache.org>wrote:
> >> >> > >
> >> >> > >> 2013/6/8 Alex Harui <ah...@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.
> >> >> > >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >Director de Tecnología
> >> >M: +34 607 22 60 05
> >> >F: +34 912 94 80 80
> >> >http://www.codeoscopic.com
> >> >http://www.directwriter.es
> >> >http://www.avant2.es
> >>
> >>
> >
> >
> >--
> >Christophe Herreman
> >http://www.herrodius.com
> >http://www.springactionscript.org
> >http://www.as3commons.org
>
>
--
Christophe Herreman
http://www.herrodius.com
http://www.springactionscript.org
http://www.as3commons.org
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Alex Harui <ah...@adobe.com>.
Adobe is on holiday this week so I will answer for Peter.
There are org.apache.flex.html.Alert and SimpleAlert classes. SimpleAlert
wraps JavaScript alert and has no options. Alert is more like
mx.controls.Alert.
Other than Panel, there is no "base class" for dialogs. Feel free to make
one if you need it, but consider that in regular Flex, things like
TitleWindow and PopUpManager existed to handle really complex overlapping
window scenarios. If you are just going to float something over the rest
of your UI, you can just add and remove a Panel from code or via states.
HTH,
-Alex
On 7/7/16, 6:25 AM, "yishayw" <yi...@hotmail.com> wrote:
>Hi Peter,
>
>Is there anything I can use for dialogs or should I create something?
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/DISCUSS-Alerts-and-Di
>alogs-in-FlexJS-tp27505p53755.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by yishayw <yi...@hotmail.com>.
Hi Peter,
Is there anything I can use for dialogs or should I create something?
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/DISCUSS-Alerts-and-Dialogs-in-FlexJS-tp27505p53755.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Peter Ent <pe...@adobe.com>.
One of the things I have disliked about Flex is the over-complication of
some things. The majority of the time I think most developers are looking
for a quick alert to the user (with a message and a button to dismiss the
alert) and a question with two or three choices. Adding multiple buttons,
other content (other than the message and title), and such seems, to me,
to belong in another class and not in Alert. This is the general
philosophy of FlexJS - keep it simple and light and add in only what you
need.
My question for this discussion was about getting the 'result' of the
Alert - through events or via a delegate. Alex had also suggested to me
the possibility of declaring an Alert in MXML which can be fine, but if
the Alert has 3 buttons for one case and 1 button for another, then the
MXML needs to be able to handle this. Having a single event with the
button flag would take care that case:
<fx:Declarations>
<basic:Alert id="alert1" message="Out of Time" title="Error" flags="4"
close="handleAlert1Close(event)" />
<basic:Alert id="alert2" message="Are you sure?" title="Confirm"
flags="3" close="handleAlert2Close(event)" />
</fx:Declarations>
Based on what I've read, the delegate pattern isn't all that familiar to
Flex folks so I'll go with events and include the flag of the button that
was selected.
For more complex presentations we can figure out something that satisfies
those criteria.
Thanks for your input.
Peter Ent
Flex SDK Team
Adobe Systems
On 6/10/13 5:09 AM, "Christophe Herreman" <ch...@gmail.com>
wrote:
>Regarding the buttons, I would find the following interesting:
>
>- option to define the order in which the buttons appear (e.g. Mac vs
>Windows [1]). The flags approach doesn't work for this, so perhaps replace
>this by an array.
>- extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ...
>- custom buttons: you can localize the built-in ones, but what if you want
>another semantic meaning for a button. A question here is how you handle
>the click/selection of a custom button.
>- have predefined combinations of buttons, similar to .NET's
>MessageBoxButtons [2]
>
>regards,
>Christophe
>
>[1] http://www.nngroup.com/articles/okndashcancel-or-cancelndashok/
>[2]
>http://msdn.microsoft.com/en-us/library/system.windows.forms.messageboxbut
>tons.aspx
>
>
>2013/6/10 Alex Harui <ah...@adobe.com>
>
>>
>>
>> On 6/9/13 1:45 PM, "Carlos Rovira" <ca...@codeoscopic.com>
>>wrote:
>>
>> >Hi Maxime,
>> >
>> >very cool alert spark implementation. I was navigating the source code
>>and
>> >have mainly a question about buttons. The eligible buttons in your
>>version
>> >are 3 (commit, discard and cancel). In mx alert we have different
>>options
>> >(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
>> >considered as well passing styles from a moduleFactory?
>> Interesting. Makes me wonder if Alert should be a container for a set
>>of
>> buttons of your choosing.
>>
>> FlexJS will have a minimum of two Alert classes: a simple one that is
>> essentially the JS alert() call, and then something that has a choice of
>> buttons more like mx:Alert. But it could be a container, I suppose.
>>
>> I'm not quite sure what is a "delegate" about this version of Alert.as.
>> Also, it still gets instantiated at startup if it is in the
>> fx:Declarations as Carlos pointed out, doesn't it?
>> >
>> >I think the declaration you provided is what Alex was askin for,
>>nothing
>> >to
>> >add for my side. I like as well the SkinnablePopUp, something that
>> >complements the SkinnablePopUpContainer counterpart.
>> >
>> >You have plans to integrate with the rest of spark components?
>> >
>> >Thanks
>> >
>> >Carlos
>> >
>> >
>> >
>> >
>> >2013/6/9 Maxime Cowez <ma...@gmail.com>
>> >
>> >> 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 <ah...@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" <ma...@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
>> >> > ><ca...@apache.org>wrote:
>> >> > >
>> >> > >> 2013/6/8 Alex Harui <ah...@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.
>> >> > >>
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >Carlos Rovira
>> >Director de Tecnología
>> >M: +34 607 22 60 05
>> >F: +34 912 94 80 80
>> >http://www.codeoscopic.com
>> >http://www.directwriter.es
>> >http://www.avant2.es
>>
>>
>
>
>--
>Christophe Herreman
>http://www.herrodius.com
>http://www.springactionscript.org
>http://www.as3commons.org
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Christophe Herreman <ch...@gmail.com>.
Regarding the buttons, I would find the following interesting:
- option to define the order in which the buttons appear (e.g. Mac vs
Windows [1]). The flags approach doesn't work for this, so perhaps replace
this by an array.
- extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ...
- custom buttons: you can localize the built-in ones, but what if you want
another semantic meaning for a button. A question here is how you handle
the click/selection of a custom button.
- have predefined combinations of buttons, similar to .NET's
MessageBoxButtons [2]
regards,
Christophe
[1] http://www.nngroup.com/articles/okndashcancel-or-cancelndashok/
[2]
http://msdn.microsoft.com/en-us/library/system.windows.forms.messageboxbuttons.aspx
2013/6/10 Alex Harui <ah...@adobe.com>
>
>
> On 6/9/13 1:45 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>
> >Hi Maxime,
> >
> >very cool alert spark implementation. I was navigating the source code and
> >have mainly a question about buttons. The eligible buttons in your version
> >are 3 (commit, discard and cancel). In mx alert we have different options
> >(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
> >considered as well passing styles from a moduleFactory?
> Interesting. Makes me wonder if Alert should be a container for a set of
> buttons of your choosing.
>
> FlexJS will have a minimum of two Alert classes: a simple one that is
> essentially the JS alert() call, and then something that has a choice of
> buttons more like mx:Alert. But it could be a container, I suppose.
>
> I'm not quite sure what is a "delegate" about this version of Alert.as.
> Also, it still gets instantiated at startup if it is in the
> fx:Declarations as Carlos pointed out, doesn't it?
> >
> >I think the declaration you provided is what Alex was askin for, nothing
> >to
> >add for my side. I like as well the SkinnablePopUp, something that
> >complements the SkinnablePopUpContainer counterpart.
> >
> >You have plans to integrate with the rest of spark components?
> >
> >Thanks
> >
> >Carlos
> >
> >
> >
> >
> >2013/6/9 Maxime Cowez <ma...@gmail.com>
> >
> >> 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 <ah...@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" <ma...@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
> >> > ><ca...@apache.org>wrote:
> >> > >
> >> > >> 2013/6/8 Alex Harui <ah...@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.
> >> > >>
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >Director de Tecnología
> >M: +34 607 22 60 05
> >F: +34 912 94 80 80
> >http://www.codeoscopic.com
> >http://www.directwriter.es
> >http://www.avant2.es
>
>
--
Christophe Herreman
http://www.herrodius.com
http://www.springactionscript.org
http://www.as3commons.org
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Alex Harui <ah...@adobe.com>.
On 6/9/13 1:45 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>Hi Maxime,
>
>very cool alert spark implementation. I was navigating the source code and
>have mainly a question about buttons. The eligible buttons in your version
>are 3 (commit, discard and cancel). In mx alert we have different options
>(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
>considered as well passing styles from a moduleFactory?
Interesting. Makes me wonder if Alert should be a container for a set of
buttons of your choosing.
FlexJS will have a minimum of two Alert classes: a simple one that is
essentially the JS alert() call, and then something that has a choice of
buttons more like mx:Alert. But it could be a container, I suppose.
I'm not quite sure what is a "delegate" about this version of Alert.as.
Also, it still gets instantiated at startup if it is in the
fx:Declarations as Carlos pointed out, doesn't it?
>
>I think the declaration you provided is what Alex was askin for, nothing
>to
>add for my side. I like as well the SkinnablePopUp, something that
>complements the SkinnablePopUpContainer counterpart.
>
>You have plans to integrate with the rest of spark components?
>
>Thanks
>
>Carlos
>
>
>
>
>2013/6/9 Maxime Cowez <ma...@gmail.com>
>
>> 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 <ah...@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" <ma...@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
>> > ><ca...@apache.org>wrote:
>> > >
>> > >> 2013/6/8 Alex Harui <ah...@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.
>> > >>
>> >
>> >
>>
>
>
>
>--
>Carlos Rovira
>Director de Tecnología
>M: +34 607 22 60 05
>F: +34 912 94 80 80
>http://www.codeoscopic.com
>http://www.directwriter.es
>http://www.avant2.es
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Maxime,
very cool alert spark implementation. I was navigating the source code and
have mainly a question about buttons. The eligible buttons in your version
are 3 (commit, discard and cancel). In mx alert we have different options
(Ok, Cancel, Yes, No). I Think is the only point I miss. Have you
considered as well passing styles from a moduleFactory?
I think the declaration you provided is what Alex was askin for, nothing to
add for my side. I like as well the SkinnablePopUp, something that
complements the SkinnablePopUpContainer counterpart.
You have plans to integrate with the rest of spark components?
Thanks
Carlos
2013/6/9 Maxime Cowez <ma...@gmail.com>
> 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 <ah...@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" <ma...@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
> > ><ca...@apache.org>wrote:
> > >
> > >> 2013/6/8 Alex Harui <ah...@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.
> > >>
> >
> >
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Maxime Cowez <ma...@gmail.com>.
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 <ah...@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" <ma...@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
> ><ca...@apache.org>wrote:
> >
> >> 2013/6/8 Alex Harui <ah...@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.
> >>
>
>
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Maxime Cowez <ma...@gmail.com>.
Right, that turned out to be harder than I anticipated. To get this to work
I had to do the following things:
- redeclare all event metadata that is declared by the Alert component and
its base classes (to be able to use mxml event handlers)
- extend EvenDispatcher and relay all events dispatched by the Alert
instance
- redeclare all style metadata that is declared by the Alert component and
its base classes (to be able to use mxml style attributes)
- implement IStyleClient (same reason)
- cache the styles and assign them to the instance once created
- "decorate" all properties exposed by Alert and its base classes (to be
able to use mxml properties)
- cache the properties and assign them to the instance once created
The resulting delegate class can be found here:
https://github.com/RIAstar/SkinnablePopUpFx/blob/delegate/skinnable-popup-fx/src/main/actionscript/net/riastar/components/AlertDelegate.as
You can play around with the compiled result here:
http://riastar.github.io/SkinnablePopUpFx/
I didn't decorate all of the properties/styles/events (just the ones to get
the demo working), but the resulting code is already bigger than the Alert
class itself :( So I'm not so sure if it's still such a great idea. To be
complete you'd have to wrap every property, style and event of
SkinnableComponent and UIComponent, and there are a lot of them. And we're
not even talking about methods: suppose someone wants to call
`alert.addElement(someElement)`...
Of course this is good old Flex 4; perhaps this can be solved another way
in FlexJS?
Max
On Sat, Jun 8, 2013 at 9:13 PM, Maxime Cowez <ma...@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 <ca...@apache.org>wrote:
>
>> 2013/6/8 Alex Harui <ah...@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.
>>
>
>
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Alex Harui <ah...@adobe.com>.
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" <ma...@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
><ca...@apache.org>wrote:
>
>> 2013/6/8 Alex Harui <ah...@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.
>>
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Maxime Cowez <ma...@gmail.com>.
@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 <ca...@apache.org>wrote:
> 2013/6/8 Alex Harui <ah...@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.
>
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Carlos Rovira <ca...@apache.org>.
2013/6/8 Alex Harui <ah...@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.
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Alex Harui <ah...@adobe.com>.
On 6/7/13 3:00 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>Hi Peter,
>
>how this will show up? calling "foo.show()"?
>
>I use to like this kind of UI Object declaration, but in this particular
>case a problem I'm seeing is that we will generate the Alert although it's
>not called by the user, isn't it? (calling Alert.show() in the old way was
>generating the object at runtime).
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.
>
>2013/6/7 Peter Ent <pe...@adobe.com>
>
>> Hi,
>>
>> I'm currently working on the Alert dialog for FlexJS. Alex and I have
>>been
>> discussing options regarding event handling from the Alert dialog which
>> could provide a pattern for future dialogs. We thought it would been
>>good
>> to get some opinions.
>>
>> In Flex you normally post an Alert dialog using Alert.show() and pass
>>it a
>> closeFunction. The returned Alert instance can be used to listen for
>>events
>> for whatever else you want to do with it. The closeFunction is optional
>>as
>> you can also listen for events.
>>
>> We thought of these possibilities:
>>
>> Events: make the FlexJS Alert work the same - create an Alert instance
>>and
>> then listen for events.
>>
>> Delegate pattern: register an object (probably the instance that is
>> posting the Alert) as a delegate and implement one or more callbacks.
>>This
>> is how you would do it in iOS, for example.
>>
>> Declare in MXML, something like this:
>>
>> <fx:Declarations>
>> <basic:Alert id="foo" title="Panic" message="Yowza!" ok="doSomething()"
>> cancel="doSomethingElse()" />
>> </fx:Declarations>
>>
>> These are not mutually exclusive by any means.
>>
>> Thoughts? Preferences?
>>
>> Peter Ent
>> Flex SDK Team
>> Adobe Systems
>>
>
>
>
>--
>Carlos Rovira
>Director de Tecnología
>M: +34 607 22 60 05
>F: +34 912 94 80 80
>http://www.codeoscopic.com
>http://www.directwriter.es
>http://www.avant2.es
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Peter,
how this will show up? calling "foo.show()"?
I use to like this kind of UI Object declaration, but in this particular
case a problem I'm seeing is that we will generate the Alert although it's
not called by the user, isn't it? (calling Alert.show() in the old way was
generating the object at runtime).
2013/6/7 Peter Ent <pe...@adobe.com>
> Hi,
>
> I'm currently working on the Alert dialog for FlexJS. Alex and I have been
> discussing options regarding event handling from the Alert dialog which
> could provide a pattern for future dialogs. We thought it would been good
> to get some opinions.
>
> In Flex you normally post an Alert dialog using Alert.show() and pass it a
> closeFunction. The returned Alert instance can be used to listen for events
> for whatever else you want to do with it. The closeFunction is optional as
> you can also listen for events.
>
> We thought of these possibilities:
>
> Events: make the FlexJS Alert work the same - create an Alert instance and
> then listen for events.
>
> Delegate pattern: register an object (probably the instance that is
> posting the Alert) as a delegate and implement one or more callbacks. This
> is how you would do it in iOS, for example.
>
> Declare in MXML, something like this:
>
> <fx:Declarations>
> <basic:Alert id="foo" title="Panic" message="Yowza!" ok="doSomething()"
> cancel="doSomethingElse()" />
> </fx:Declarations>
>
> These are not mutually exclusive by any means.
>
> Thoughts? Preferences?
>
> Peter Ent
> Flex SDK Team
> Adobe Systems
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: [DISCUSS] Alerts and Dialogs in FlexJS
Posted by "Skogen, Espen" <es...@jpmorgan.com>.
My immediate thought on the delegate pattern is that it feels a little awkward. As a flex dev, I feel the event flow would be more familiar, but I guess we need to ask ourselves whether these api's will be used by old flex hats or whether we're appealing to a new group of developers.
Maybe you could show some code to illustrate how it would work, for those not familiar with objective c and ios dev.
In the mxml implementation it would be good to include a declarative display control similar to what we have in popup-wrapper.
Espen
----- Original Message -----
From: Peter Ent [mailto:pent@adobe.com]
Sent: Friday, June 07, 2013 08:52 PM GMT Standard Time
To: flex-dev@incubator.apache.org <fl...@incubator.apache.org>
Subject: [DISCUSS] Alerts and Dialogs in FlexJS
Hi,
I'm currently working on the Alert dialog for FlexJS. Alex and I have been discussing options regarding event handling from the Alert dialog which could provide a pattern for future dialogs. We thought it would been good to get some opinions.
In Flex you normally post an Alert dialog using Alert.show() and pass it a closeFunction. The returned Alert instance can be used to listen for events for whatever else you want to do with it. The closeFunction is optional as you can also listen for events.
We thought of these possibilities:
Events: make the FlexJS Alert work the same - create an Alert instance and then listen for events.
Delegate pattern: register an object (probably the instance that is posting the Alert) as a delegate and implement one or more callbacks. This is how you would do it in iOS, for example.
Declare in MXML, something like this:
<fx:Declarations>
<basic:Alert id="foo" title="Panic" message="Yowza!" ok="doSomething()" cancel="doSomethingElse()" />
</fx:Declarations>
These are not mutually exclusive by any means.
Thoughts? Preferences?
Peter Ent
Flex SDK Team
Adobe Systems
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.