Hi Peter, 2013/6/10 Peter Ent <p...@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.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 > > -- Christophe Herreman http://www.herrodius.com http://www.springactionscript.org http://www.as3commons.org
