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