>In that case I think Alert should be even simpler and only allow for the 'OK' >button. If one wants a more configurable message box (with Yes, No, Cancel, >Retry, Ignore, or whatever standard >options), one should use this other class
IMO, the buttons configuration Yes/No , Ok/Cancel, is part of the standard Alert behavior (see Windows or Java API, for example). For the same reason, the icons should also be standardized ( INFO, WARNING, ERROR). >So there seems to be a need for a more configurable Alert. Or do you think >this should be a new component that subclasses Alert (or would be a sibling of >it) >Remember, I'm not looking at this topic from the POV of Alert only, but from >that of a possible set of standard (configurable) popups ;) I think both sentences lead to the same conclusion: making a new "Popup" as easy as possible to implement (using your "PopupController"). That way, it's not even needed to derive from anything. If you need a custom alert with let's say "Retry/Ignore/Abort" buttons, build a custom Panel and plug the PopupController, implement the IPopup interface and you are done :-). Of course, we could provide a base PanelPopup with the PopupController already embedded and a default base implementation (and no content), as a convenience. We could also provide base classes for the common popup UIs ( ie Callout, Box, TitleWindow, Panel, whatever) But if the implementation is simple enough, this shouldn't be even needed. WDYT? Maurice -----Message d'origine----- De : Maxime Cowez [mailto:maxime.co...@gmail.com] Envoyé : lundi 14 octobre 2013 12:03 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark Alert implementation > An alert should be a simple low-level component, with a well-defined behavior, and easy to use. Don't get me wrong, I totally agree. I do think it should be as simple as possible *in its default configuration*. But in another discussion on this topic I've heard people say that they would like to have an easy way to configure Alert for some standard use cases. Most of which relates to the configuration of the buttons (their labels, their order, how many). And by "easy" I understand: no subclassing, no custom skinning. So there seems to be a need for a more configurable Alert. Or do you think this should be a new component that subclasses Alert (or would be a sibling of it)? In that case I think Alert should be even simpler and only allow for the 'OK' button. If one wants a more configurable message box (with Yes, No, Cancel, Retry, Ignore, or whatever standard options), one should use this other class. Remember, I'm not looking at this topic from the POV of Alert only, but from that of a possible set of standard (configurable) popups ;) On Mon, Oct 14, 2013 at 11:05 AM, Maurice Amsellem < maurice.amsel...@systar.com> wrote: > >one might very well imagine an Alert that has no title, hence > >removing > the need for a title bar. So Alert's skin might have to react a bit > differently than Panel's skin >based on the value of its 'title' property. > Otherwise Alert's skin could have simply composed a Panel instead of > duplicating the code. > > I take as a reference the current implementation and behavior of > mx:Alert (which is similar to Alert boxes in other environments, > Windows, Java, > etc...) > You can imagine another behavior (such as not displaying the title bar > when there is no title), but that's an improvement over the existing > component. > > Really, I am not getting the point of this discussion, either with you > or Alex. > An alert should be a simple low-level component, with a well-defined > behavior, and easy to use. > If someone wants to implement a super-duper-extended Alert box, they > can always subclass and change the skin. > > WDYT ? > > Maurice > > -----Message d'origine----- > De : Maxime Cowez [mailto:maxime.co...@gmail.com] Envoyé : lundi 14 > octobre 2013 10:45 À : dev@flex.apache.org Objet : Re: FLEX-33806 and > spark Alert implementation > > > But on the other hand it needs to be displayed in a Panel Skin frame. > I don't totally agree on that one: one might very well imagine an > Alert that has no title, hence removing the need for a title bar. So > Alert's skin might have to react a bit differently than Panel's skin > based on the value of its 'title' property. Otherwise Alert's skin > could have simply composed a Panel instead of duplicating the code. > Max > > > On Mon, Oct 14, 2013 at 2:58 AM, Maurice Amsellem < > maurice.amsel...@systar.com> wrote: > > > >That might be a flaw in the design. I think other Spark components > > >have > > a content property that can take a textFlow. > > >Then it is left to the skin designer to grab the right property > > >from the > > model and display it in the view/skin. > > > > Shouldn't that be done in the hostComponent (eg. in partAdded) ? > > > > >I haven't looked at the Alert code, but it sounds like the design > > >may not > > be correct. In FlexJS the Alert is not a Container for similar reasons. > > I agree that since the content is fixed, it should not be a > > SkinnableContainer. > > But on the other hand it needs to be displayed in a Panel Skin frame. > > How would you do that without inheriting Alert from Panel and > > without "duplicating" the code from PanelSkin? > > > > Maurice > > > > -----Message d'origine----- > > De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 11 > > octobre > > 2013 18:35 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark > > Alert implementation > > > > > > > > On 10/11/13 12:34 AM, "Maurice Amsellem" > > <maurice.amsel...@systar.com> > > wrote: > > > > >>Simplification tends to remove flexibility. Spark components are > > >>supposed > > >>to leave control of all visuals to the skin designer. For example, > can > > >>the custom skin designer swap out a messageDisplay that does plain > > >>text with one that does rich text? > > > > > >If you replace plain text with rich text, it's not only a skin > > >design change in my sense, because you are also changing the > > >behavior (you have to change to calling code as well). > > >Yet, you can do it by subclassing Alert to RichAlert and just swap > > >the content and override one of the static methods to use your RichText. > > >With the previous implementation, you could replace the skin part > > >with RichText in the skin, but you will still have to subclass > > >Alert to set the richText correctly. > > That might be a flaw in the design. I think other Spark components > > have a content property that can take a textFlow. Then it is left > > to the skin designer to grab the right property from the model and > > display it in the view/skin. > > > > > >The problem here is that it's not a Skinnable Component but a > > >Skinnable Container. > > >It's different because Skinnable containers content is part on the > "data" > > >and not of the skin. > > >It's not clear to me if changes in the content of > > >SkinnableContainers should be set as skinParts and moved to the > > >skin (and disabling the content skinpart) or just overriding the > > >content in a subclass of the container. > > > > > >What do you think? > > I haven't looked at the Alert code, but it sounds like the design > > may not be correct. In FlexJS the Alert is not a Container for > > similar > reasons. > > > > > >Maurice > > > > > >-----Message d'origine----- > > >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 11 > > >octobre > > >2013 06:26 À : dev@flex.apache.org Objet : Re: FLEX-33806 and spark > > >Alert implementation > > > > > > > > > > > >On 10/10/13 7:20 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > > > > > >>Hi, > > >> > > >>Being an experimental component I think just about any improvement > > >>is a good idea. > > >I agree with that statement, but is removing skinparts a "good idea"? > > >Simplification tends to remove flexibility. Spark components are > supposed > > >to leave control of all visuals to the skin designer. For example, can > > >the custom skin designer swap out a messageDisplay that does plain > > >text with one that does rich text? > > > > > >Getting rid of monkey patching PanelSkin sounds like a good idea though. > > >And defaulting to BitmapImage and plain text. > > > > > >Have fun, > > >-Alex > > > > > > > >
