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" <yishayj...@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?
