@alex > Interesting. Makes me wonder if Alert should be a container for a set of buttons of your choosing.
As I've described in my response to Carlos: I believe you can get - almost - anywhere you want with three buttons as long as you can customize their labels. > 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? The delegate I created as an experiment following Carlos' idea ( https://github.com/RIAstar/SkinnablePopUpFx/blob/delegate/skinnable-popup-fx/src/main/actionscript/net/riastar/components/AlertDelegate.as) is not a UIComponent; it's just a simple class which will hold the values of the Alert's properties, styles and event handlers until the real Alert component is instantiated with these values and added to the displayList. So yes it is instantiated, but it's more lightweight than the UI component itself. Or at least it was supposed to be: my conclusion from the experiment was that it was not really worth the effort, unfortunately. Max On Mon, Jun 10, 2013 at 10:43 PM, Maxime Cowez <maxime.co...@gmail.com>wrote: > @Carlos > > > 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. > > I look at it like this: OK/Cancel and Yes/No and possible some other > options are all functionally equivalent; they are just different labels for > the same function. Also one would never combine Cancel with No. So I tried > to analyze what were the basic actions one could take after reading a > simple message and how they would affect the application flow; I came to > these three generic functionalities: > - the user wants to commit the stuff he was just working on and he wants > to move on with the flow of the application: Ok/Yes/Commit (I called this > 'commit') > - the user does not want to commit that stuff and > - he wants to go back to where he was (perhaps so he can fix what was > wrong or what he forgot about): I called this 'cancel' > - he wants to discard the stuff he just did and move on with the > application anyway: I called this 'discard' > That's why there are just three buttons, but you can assign whichever > label to them you like. So if you want a Yes/No dialog you can do it like > this: > > <rs:Alert title="my title" text="my message" cancelable="true" > commitLabel="Yes" cancelLabel="No"/> > > Or if you want your Alerts to have the Yes/No combo application-wide > instead of the default values, you can do so through the locale .properties > file. > Also I tried to keep things as simple as possible, that's why the default > values are committable:true, cancelable:false and discardable:false, which > means by default you'll get an Alert with only one button (Ok/Yes/Commit). > Feel free to disagree with me, but I think these three plus their labels > can cover just about any standard situation you would use an Alert for. If > you need more there's always the possibility to extend SkinnablePopUp. > What is missing compared to mx Alert though (for now) is the possibility > to show an icon next to the message. > > > Have you considered as well passing styles from a moduleFactory? > > Haven't worked with modules much so my knowledge of the topic is sparse. > SkinnablePopUp is heavily based on SkinnablePopUpContainer though, so it > has the exact same functionalities (except for not being a container of > course). > > > 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. > > Indeed my idea was to have a more generic base class which one could > extend if the default Alert class would prove insufficient. For instance I > was also thinking of toast-messages (you know, the messages that popup in a > corner of the screen and then disappear again after a while) as another > default implementation of SkinnablePopUp. > > > You have plans to integrate with the rest of spark components? > > I'm not exactly sure what you're asking here. I *try* to design my > components as if they were part of the SDK, so this should already > integrate fairly well, unless you think something is still missing? > If you're asking if I would like to work on it more in the context of > Apache Flex, I'd be glad to; but it is my understanding that there already > is an implementation of Alert in the experimental components (that one is > more of a direct port to Spark of the old mx Alert though). I don't think > it would be wise to have two discrete implementations of the same concept. > > Max > > > On Mon, Jun 10, 2013 at 10:08 PM, Maxime Cowez <maxime.co...@gmail.com>wrote: > >> As we were discussing some options in the thread "Alerts and dialogs in >> FlexJS", we started to elaborate on dialog implementation in general. This >> was carrying us away from the initial question so I started this new thread. >> >> One of the initial topics was the possibility to declare Alerts/Dialogs >> as mxml tags instead of using the old static function, something like this: >> >> <fx:declarations> >> <s:Alert id="alert" title="myTitle" text="myMessage" >> close="handleAlertClose(event)"/> >> </fx:declarations> >> >> <s:Button label="show alert" click="alert.open()"/> >> >> I mentioned that I had already created such an implementation, which can >> be found at https://github.com/RIAstar/SkinnablePopUpFx >> There's also a live demo at http://riastar.github.io/SkinnablePopUpFx/ >> >> Some people seemed to like the idea and asked some questions, which I'll >> try to answer next. >> >> Max >> > >
