Combining multiple responses: >> Okay. I just implemented WrappedShape, WrappedSimpleButton, WrappedSprite >> and WrappedTextField. I hope that helps you. >> >> I did not implement a createElement method because I did not see the >> point. On the HTML side there’s code that’s specific to a lot of >> different individual elements, but on the Flash side it’s really simple. > > Well, on the SWF side there is current CSSShape, UIBase, UIButtonBase, > StyleableCSSTextField, maybe others. With this change, these four classes > can theoretically be collapsed into one (UIBase) where createElement > creates the Shape, Sprite, Button, TextField, whatever. Then the > lifecycle would be much more similar to the JS-side (or so I think).
True. But having separate classes makes accessing the underlying typed DisplayObject much easier and clearer. You could do this: b.$button.upState = upSprite.$sprite; instead of this: (b.$displayObject as SimpleButton).upState = upSprite.$displayObject; The number of possible base UI classes is pretty limited on the SWF side, so I like this way better. Here’s the full list of potential additional objects as I see it: Bitmap, Video, Loader, TextLine > 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). > 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. > 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? Harbs
