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" <christophe.herre...@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 <aha...@adobe.com>
>
>>
>>
>> On 6/9/13 1:45 PM, "Carlos Rovira" <carlos.rov...@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 <maxime.co...@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 <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.
>> >> > >>
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >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
