Re: [DISCUSS] Alerts and dialogs in Flex 4.x / Spark (was: Alerts and dialogs in FlexJS)
Hi Maxime, I understand the buttons concept and seems ok to me. It's another way to get to the same. I was aware of an Alert but for I forgot it until you point it. Ok, I revised it and seems in a quick read a right implementation of the mx Alert in spark version. Maybe we could update it to get the benefits in your implementation to get best of both worlds. So for example we will get the mxml declaration, the delegate concept, but will maintain the api with show method and alert traditional buttons... 2013/6/10 Maxime Cowez maxime.co...@gmail.com @Christophe I'll be replying to your statements from the point of view of my Alert/SkinnablePopUp implementation, so maybe you'll have to read the previous mails in this thread to understand what I mean. Regarding the buttons, I would find the following interesting: - option to define the order in which the buttons appear (e.g. Mac vs Windows). The flags approach doesn't work for this, so perhaps replace this by an array. Agreed. For now the only way to do this in my implementation is by creating a custom skin. For the Mac vs. Windows case this might be sufficient (or perhaps even appropriate), but it sure wouldn't hurt if there were an easier way to just change the order through an attribute. I'll have a look at it. - extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ... 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. Yes/No, Ok/Cancel, Retry/Ignore/Abort all fit into the commit/cancel/discard functional threesome I described. - 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. That's exactly why I think there should be only three and not 9+. As long as the semantic meaning of the buttons is sufficiently generic, I believe most use cases will fit in there. Feel free to prove me wrong ;) If you have the odd case where you really can't fit it in, you can still extend SkinnablePopUp. - have predefined combinations of buttons, similar to .NET's MessageBoxButtons Again, I think this approach is actually more limiting. I looked at the list of possible combinations in the .NET docs and I'm already missing some. 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. That's why I created Alert to be 'committable'-only by default (not 'cancelable' or 'discardable'). This results in a simple message box with an OK/Commit/Yes button. Max On Mon, Jun 10, 2013 at 10:57 PM, Maxime Cowez maxime.co...@gmail.com wrote: @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
Re: [DISCUSS] Alerts and dialogs in Flex 4.x / Spark (was: Alerts and dialogs in FlexJS)
@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.comwrote: @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.comwrote: As we were discussing some options in the thread Alerts and dialogs in FlexJS, we started to elaborate on dialog implementation
Re: [DISCUSS] Alerts and dialogs in Flex 4.x / Spark (was: Alerts and dialogs in FlexJS)
@Christophe I'll be replying to your statements from the point of view of my Alert/SkinnablePopUp implementation, so maybe you'll have to read the previous mails in this thread to understand what I mean. Regarding the buttons, I would find the following interesting: - option to define the order in which the buttons appear (e.g. Mac vs Windows). The flags approach doesn't work for this, so perhaps replace this by an array. Agreed. For now the only way to do this in my implementation is by creating a custom skin. For the Mac vs. Windows case this might be sufficient (or perhaps even appropriate), but it sure wouldn't hurt if there were an easier way to just change the order through an attribute. I'll have a look at it. - extra buttons: Yes, No, Cancel, OK, Retry, Ignore, Abort, ... 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. Yes/No, Ok/Cancel, Retry/Ignore/Abort all fit into the commit/cancel/discard functional threesome I described. - 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. That's exactly why I think there should be only three and not 9+. As long as the semantic meaning of the buttons is sufficiently generic, I believe most use cases will fit in there. Feel free to prove me wrong ;) If you have the odd case where you really can't fit it in, you can still extend SkinnablePopUp. - have predefined combinations of buttons, similar to .NET's MessageBoxButtons Again, I think this approach is actually more limiting. I looked at the list of possible combinations in the .NET docs and I'm already missing some. 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. That's why I created Alert to be 'committable'-only by default (not 'cancelable' or 'discardable'). This results in a simple message box with an OK/Commit/Yes button. Max On Mon, Jun 10, 2013 at 10:57 PM, Maxime Cowez maxime.co...@gmail.comwrote: @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.comwrote: @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
