Strand Initializer

[Yishay Weiss <yi...@hotmail.com>]

I’ve encountered a problem with MXML initialization of components that have a model defined in MXML beads. Suppose I have the following MXML:

<MyComp attName=”val1”>
  <beads><CompModel></beads>
</MyComp>


And the follow as3:

class MyComp extends UIBase {
      public function set attName(value:*):void
             {
            model.attName = value;
}
}

model will be initialized before CompModel is added to beads so CompModel is never added to MyComp.

Is this a bug? Is specifying a model in <beads/> bad practice?

Re: Strand Initializer

[Alex Harui <ah...@adobe.com.INVALID>]

There are two kinds of calls to MXMLDataInterpreter per instance.

The first one is generateMXMLProperties which handles the attributes in an MXML tag.  IIRC, this is called in the constructors in order to guarantee that the baseclass calls generateMXMLProperties on its attributes before the subclass does in order for subclass values to override baseclass values just like in typical AS constructors.

Long after that, when the container is added to the DOM, then generateMXMLInstances is called that builds all of the child tags.  This needs verification, but I'm pretty sure a bead is a child tag and instantiated in this part of the lifecycle.  However, beadOffset is used to make sure that, of all of the child tags, that beads are applied before other child tags, but not the attributes.

Moving bead instantiation into constructor time might change lots of little things.  The lifecycle has to consider various options for app devs to override things, inject other things.  It should try to defer work if possible, so the browser doesn't have to freeze while the constructors of all attributes are instantiated.

IMO, the expectation was that if you define a bead override in MXML, you should set the attributes on the bead instead of the Top-Level Component boundary.  But hey, there might still be a way to do everything we currently do and still fix this issue.

HTH,
-Alex

On 4/18/19, 12:09 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:

    
    >You are welcome to investigate finding an efficient way to allow your proposed pattern.
    
    What comes to my mind is interpreting  <beads> before the atts. I’m finding It difficult to understand how beadOffset is used in MXMLDataInterpeter.initializeStrandBasedObject(). But can we use it to jump to the beads location, interpret the beads, splice that interpreted data out, and then continue with the original algorithm?
    
    

RE: Strand Initializer

[Yishay Weiss <yi...@hotmail.com>]

>You are welcome to investigate finding an efficient way to allow your proposed pattern.

What comes to my mind is interpreting  <beads> before the atts. I’m finding It difficult to understand how beadOffset is used in MXMLDataInterpeter.initializeStrandBasedObject(). But can we use it to jump to the beads location, interpret the beads, splice that interpreted data out, and then continue with the original algorithm?

Re: Strand Initializer

[Alex Harui <ah...@adobe.com.INVALID>]

When I wrote this part of the lifecycle, I couldn't find an efficient way to allow your pattern.  So folks will have to instead use:

    <MyComp>
      <beads><CompModel attName=”val1”></beads>
    </MyComp>

We should add that to the doc somewhere.  You are welcome to investigate finding an efficient way to allow your proposed pattern.

HTH,
-Alex

On 4/17/19, 6:14 AM, "Yishay Weiss" <yi...@hotmail.com> wrote:

    I’ve encountered a problem with MXML initialization of components that have a model defined in MXML beads. Suppose I have the following MXML:
    
    <MyComp attName=”val1”>
      <beads><CompModel></beads>
    </MyComp>
    
    
    And the follow as3:
    
    class MyComp extends UIBase {
          public function set attName(value:*):void
                 {
                model.attName = value;
    }
    }
    
    model will be initialized before CompModel is added to beads so CompModel is never added to MyComp.
    
    Is this a bug? Is specifying a model in <beads/> bad practice?