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.herre...@gmail.com> wrote: > 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 >
