Copy/pasting from several posts... On 7/27/16, 2:09 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>Thinking about this some more, I think an svg should have a different API. > >SVG elements should inherit from UIBase and have the full capabilities >For one, I’m not sure primitives should implement beads. UIBase also >makes a lot of assumptions based on normal DOM elements. SVG has quite a >few attributes which can be specified directly rather than using styles >(i.e. width, height opacity, etc.) I'm not sure what you mean by "SVG elements", but IMO, the rect primitive probably shouldn't inherit from UIBase, and maybe shouldn't not implement IUIBase unless we decide that same Rect class will also act as the "Rect component". > >It seem to me like primitives are pretty well defined and the full gamut >of behavior should be part of the classes. Any behavior beyond that >should require either using proper components, or wrapping the primitives >in primitive containers. > >Another area which makes sense to have separate APIs for primitives is >related to defs.[1] You can define definitions in SVG and use those in >SVG elements contained therein. There should be a mechanism for >primitives to get defs of their containing SVG element. A good example is >masks[2] masking content in a single SVG is straightforward, but masking >one SVG using another is not. > >[1]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs >[2]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/mask Does SVG support a mechanism for primitives to get their defs? If not, IMO, doing so would be a nice-to-have, not a requirement. >I prefer to make things a little more explicit: ><svg:Rect> would be <rect> ><svg:RectComponent> would be <svg><rect></svg> ><svg:Circle> would be <circle> ><svg:CircleComponent> would be <svg><circle></svg> > ><canvas:Rect> would do drawRect() on the containing canvas ><canvas:RectComponent> would be <canvas> and drawRect() ><canvas:Circle> would be drawCircle() on the containing canvas ><canvas:CircleComponent> would be <canvas> and drawCircle() > >I’m not sold on the names. Maybe something like WrappedRect instead? > Another possibility is different flavors of Spacer like RectSpacer. Also realize that for a Rect "component" you can also use a <div> and for line there is the <hr> tag. > >I’m not sure how to enforce that the correct components are added to the >correct containers, though. > If primitives support an interface, in theory the MXML compiler should catch when the content property is not assigned something supporting that interface. The ArrayElementType metadata supposedly makes that happen. > >The way Om did it makes that simple. All Graphic elements are simple DOM >elements at their basic level, and can be added to anything. When you are >dealing with primitives it’s more difficult. What I did in >GraphicContainer (which is an svg) is that I’m overriding addElement and >checking that the element being added is an svg-compatible component. >Otherwise I’m throwing an error. This helps for runtime coercion, but not >for compile-time and MXML. Ideally, there should be a compile-time way of >checking which elements can be added to what. > FWIW, my philosophy is not to do runtime checking of the type of the children. You can add conditional compilation around that check and produce a "debug version" of the class, but at production time, in theory you've done enough testing to get the types right, and that checking is not helpful. On Jul 27, 2016, at 10:59 AM, yishayw <yishayj...@hotmail.com> wrote: >If we change IUIBase.addedToParent() to >IUIBase.addedToParent(parent:IUIBase) we can probably make the necessary >adjustments there. That also works around the mxml compile error question. > Whether we do that or not, in theory at addedToParent() time the parent property is valid. HTH, -Alex
