Sure, components should try and validate their values, but client code is not
necessarily components, and it’s pretty easy to introduce a bug where client
code supplies a wrong value.
I do a lot of loading of content programmatically. This includes things like
colors. The dynamic content does not cleanly fit into MXML and pure components.
Setting properties using client code is the norm.
Are worried about the performance implications of an extra check?
In our case we had some code like this in our app:
var fill:SolidColor = new SolidColor(0xFFFF0000, 1);
var stroke:SolidColorStroke = new
SolidColorStroke(0xFFFFFFFF,1, 1);
The color value could just as easily have been a variable whose value is
determined at runtime.
This code works in Flash because it supports argb. I took the easy way out by
simply rejecting argb values, but I guess we could break off the alpha channel
and set the alpha with that value.
On Oct 26, 2016, at 11:46 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 10/26/16, 12:59 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Pretty likely. The color values can come from anywhere. We happened to
>> have the values coming from compiled code (so compile-time checks could
>> have caught that case), but other colors in our app are created at
>> runtime.
>>
>> Runtime colors seems like a likely scenario.
>
> Maybe I'm not understanding, but I would that the recommended practice is
> that a user-determined color is validated at the point of user
> interaction. IOW, a ColorPicker will only return valid colors. Even a
> TextInput where you type in something and want a valid color out of it
> should validate the color at that point, before it goes into ValueObjects
> and into instances of SolidColor/SolidColorStroke.
>
> Thoughts?
> -Alex
>
