On 7/30/16, 12:13 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>> In order to get Application to wrap the root, I will have to do more >> mucking in this area. I may add createElement because it lets us >>control >> what gets created as the wrapped element is a more common way. >>Otherwise >> if a subclass wants to create a different element, the superclass will >> have unnecessarily created a different element. > >I’d like to see a use case before we do this. It seems like it should be >pretty clear which subclasses to start from in Flash (as is currently >being assumed with the sub-classing). It would be nice if Application could extend HTMLElementWrapper since we want it to wrap the root in the SWF or Body in JS. Since we don't want HTMLElementWrapper to extend Sprite, we need to use a FactoryClass in order to bootstrap the SWF with a MovieClip (two-frame SWF like regular Flex). And so having HTMLElementWrapper's constructor generate a Sprite is not useful for Application. By calling createElement, Application can override createElement and create something else (actually, for Application, it won't create anything as the root MovieClip has already been created and is assigned to the Application by the Factory). > > >> Related thought, so I don't forget: It isn't clear that CSSShape and >> CSSTextField which are only used in SWF implementations needed to become >> HTMLElementWrappers. > > >I was wondering about that myself. When I started, I did not notice that >they seem to be SWF-only. But: > >First of all, CSSTextField is not a SWF-only class. I’m not sure if it’s >used anywhere in JS, but I assume it could. It’s also possible that >CSSShape can get a JS implementation as well. I might actually use it for >the svg primitives. (not sure yet) > >Even if not, it seems like it makes sense to keep the same pattern. I'm worried that we'll be sorry if we add additional function call overhead to the leaves of the display object tree. For example, every time we access x,y,width,height it will result in extra function calls through the wrapper. A TextField emulation exists for the MX/Spark port where we don't care about overhead. I would be cautious about replicating all of TextField to the JS side to do text for the graphics SWC. There are some funky APIs around textColor vs TextFormat. IMO, we want to have low overhead on the JS-side and emulate SVG on the SWF side. > > >> So now, I'm pondering a couple of deeper refactors. One is something >>like: >> -create a ElementWrapper class. It has an element property. >> -create a UIElementWrapper class. It subclasses WrappedElement and adds >> parent, x, y, width, height, visible, alpha that proxy to the element. >> -rename HTMLElementWrapper to FlexJSElementWrapper. It would add the >> strand implementation. >> -CSSShape and friends subclass UIElementWrapper >> -HTTPService subclasses ElementWrapper >> -UIBase and Application subclass FlexJSElementWrapper > > >I assume the ElementWrapper has the Bead related code that HTTPService >seems to be implementing on the SWF side. > >I like this option. It seems clean and makes sense to me. > >UIElementWrapper would have element for cross-platform use. >UIElementWrapper would have $displayObject for Flash-only use. >CSSSprite and friends would have the $sprite and friends for easy typed >access to the Flash objects. > >The only thing I’m not clear on is where the Flesh objects get >instantiated. I guess that could be in the UIBase constructor, or in a >createElement function (if necessary). > >I’m also not clear on why to have both UIElementWrapper and >FlexJSElementWrapper. Why would you not always want the strand >implementation? Because the low-level CSSShape and friends probably won't need beads hung on them. I will probably try to code up the other option and see where the pain points are. There might be some killer issue. I'd like to avoid wrapping the CSSShape and friends. Thoughts? -Alex
