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 <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
