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