flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Unclear exception when valuesImpl is not set in <js:Application>
Date Fri, 02 Dec 2016 21:51:07 GMT

On 12/2/16, 1:32 PM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>I'm trying to write some better beginner docs for FlexJS components this
>afternoon. I don't actually have any time to do this, but it absolutely
>needs to be done for the good of FlexJS so I'll try to get something
>started. Anyway, as a semi-beginner with the framework, I'm paying close
>attention to the weird errors I run into along the way so that they will
>known and can be addressed.

Thanks for working on this.

>Will it completely break anything if we skip the call to init() when
>valuesImpl is missing?

Yes.  I would expect the whole world to implode.  ValuesManager generally
dictates how lots of components find their beads.

> In other words, is a valuesImpl essential to a
>FlexJS application? If not, we should skip calling init() instead of
>allowing this vague exception to be thrown. If bad things will happen,
>we need to preemptively throw a different exception with a better
>description of what's wrong.

Could put a try/catch around it and report a nicer error, but even that is
code that won't be needed in production because you'll have long since
figured out you need a valuesImpl.

IMO, it might be time to start on the "heavier" component set.  You could
create a SimpleCSSApplication or POCApplication or just another
Application in a different package like org.apache.flex.full or
org.apache.flex.poc (Proof Of Concept) that has SimpleCSSValuesImpl baked
in.  Then folks will never hit this issue and we don't have to put in code
that isn't needed at runtime.

This is another aspect of pay-as-you-go and composition.  We want to
identify the common aggregations of beads and make higher-level components
that compose them.  Really, the current examples are just testing that
there are no assumed aggregations.  I don't expect lots of folks to use
Basic and aggregate everything from scratch.  I think most folks will use
a heavier set with more things baked in because it will take them less
thinking about what beads are needed.  But if they run into
performance/size issues we will know they can decompose their app into
smaller pieces and throw out what they don't need.  The key is that we,
the framework developers, have to make sure the pieces remain loosely

My 2 cents,

View raw message