On Thu, Nov 7, 2013 at 4:41 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 11/7/13 4:35 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>
> >On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >> FWIW, I was thinking that this kind of check should be replaced by some
> >> capability in the tool chain to verify a configuration, maybe by marking
> >> some values as required.  In production, you hopefully don't need these
> >> kinds of checks.  I've also floated the idea of "debug-mode" beads which
> >> have more checks than production beads.
> >>
> >> Thoughts?
> >>
> >
> >Personally, I don't like the idea of setting the bead values in CSS.  It
> >makes it hard to enforce these kind of things.  Ideally, the absence of a
> >bead that the code is looking for should generate a compile error.
> >
> >Another way to inject beads would be to use metadata attributes.
> >Something
> >along the lines of spark skins' [SkinPart(required="true")] metadata
> >attribute.  Would this make it easier to do the checks?
> That would help with the check, but are you also proposing naming the
> default value in the metadata?
>
>
Yes, setting the default values in metadata would be great.  It is more in
tune with how Flex works in today.


>  >
> >Or more simpler, maybe we have default empty IBeads available so that
> >things at least don't blow up.  But I am guessing that this approach might
> >only delay the blow up of the code to a later stage.
> I guess I'm wondering how easy it is to screw up your config such that we
> need a lot of runtime protection for this.  How did you get into this
> error in the first place?
>
>
I wouldnt say it is very easy, but definitely possible.  And a pain to
debug.  I am not sure how I got into that situation.  It was probably the
IFlexInfo issue I had earlier.  I will check if I can repro this again.

Thanks,
Om

Reply via email to