You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Josh Tynjala <jo...@gmail.com> on 2016/12/02 21:32:26 UTC

[FlexJS] Unclear exception when valuesImpl is not set in

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 be
known and can be addressed.

I just created a simple app with <js:Application>. I quickly discovered
that the valuesImpl property must be set or an exception will be thrown.
I've seen enough code on the list to guess that I can probably use
SimpleCSSValuesImpl. A complete beginner won't know that, though.

In org.apache.flex.core.ContainerBase (in both Basic and HTML, but maybe
elsewhere?), I found the following code where the exception is thrown:

if (!_initialized)
{
    // each MXML file can also have styles in fx:Style block
    ValuesManager.valuesImpl.init(this);
}

I'd like to make this better for beginners who might not know what's wrong.

Will it completely break anything if we skip the call to init() when
valuesImpl is missing? 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, then
we need to preemptively throw a different exception with a better
description of what's wrong.

- Josh

Re: [FlexJS] Unclear exception when valuesImpl is not set in

Posted by Alex Harui <ah...@adobe.com>.

On 12/2/16, 1:32 PM, "Josh Tynjala" <jo...@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
>be
>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,
>then
>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
coupled.

My 2 cents,
-Alex