On 9/18/14 11:34 AM, "OmPrakash Muppirala" <[email protected]> wrote:
>On Thu, Sep 18, 2014 at 11:03 AM, Alex Harui <[email protected]> wrote: > >> >> >> On 9/18/14 10:47 AM, "OmPrakash Muppirala" <[email protected]> wrote: >> >> >On Thu, Sep 18, 2014 at 9:07 AM, Alex Harui <[email protected]> wrote: >> > >>I guess I was expecting that you could declaratively describe a complex >> graphic and do something like: >> >> <GraphicsContainer> >> <Rect ..> >> <Circle ..> >> <Path ..> >> </GraphicsContainer> >> >> >Right, this is essentially FXG. I want to support this, but don't really >want to restrict being able to add Rect to a GraphicsContainer. In FlexJS, there can be more than one Button component. It has a different package, therefore MXML namespace, but the name can still be Button. Maybe the GraphicsContainer children are in a graphics.shapes package and the top-level components are in a graphics.components package. The shapes can have an MXML namespace like "gs" and assuming GraphicsContainer has graphics.components.Rect go in the "basic" namespace (that I want to rename to "fjs" someday), the MXML might look like: <fjs:ViewBase> <fjs:Button> <fjs:Rect> <fjs:TextInput> <fjs:GraphicsContainer> <gs:Rect> <gs:Circle> <gs:Path> </fjs:GraphicsContainer> <fjs:ViewBase> >> >> What about doing something similar to Spark? Spark has a BitmapImage >> graphic primitive and an Image component. FlexJS could have a Rect >> component as well as a Rect graphic element that only can be a child of >>a >> GraphicsContainer. The Rect component can just be a UIBase that is >> composed of a GraphicsContainer child with a Rect in it. That would be >> consistent with the composition philosophy of FlexJS: common patterns >>get >> composited into Components and can be further optimized if needed. >> > >So, in this case, GraphicShape would implement IUIBase. RectElement, >EllipseElement, etc. would extend GraphicShape. GraphicsContainer extends >UIBase and would take in only GraphicShapes as children. Is it possible >to >enforce this during compilation? Or would we have to rely on runtime >exceptions? Or we could just add a addShape() method to GraphicsContainer >to enforce this. How would we suppress addElement() in that case? I was thinking that graphics.shapes.Rect (or its base class GraphicShape) would not implement IUIBase, maybe something new called IGraphicShape or IGraphicElement. I think that would make it easier to have the compiler tell you that you cannot just drop the graphics.shape.Rect outside of a GraphicsContainer and to tell you that you can't stick a TextInput inside a GraphicsContainer (which is true on the JS side, isn't it?). Yes, I know the set of APIs is probably exactly the same, so an alternative is we make extensions to IUIBase and use that to determine what can be a child of what. > >Is that the way you see it? I honestly don't have a particular vision. I'm just pointing out stuff that pops into my head while matching it up against the "composition of smaller things" philosophy for FlexJS. I'm still trying to finish up some significant tweaking of FlexJS to try to get the FlexJS version of FlexStore to work. Along the way I've made it possible to define views in MXML and cross-compile more code instead of having to write parallel versions. I was looking at addElement, etc and pondering what would break if I changed the type of the child from Object to IUIBase. That would enforce the right children being added via AS for these graphics primitives as well. Then I would say that GraphicsContainer shouldn't extend UIBase so it doesn't pick up the addElement and have its own addElement that accepts whatever types we put on the graphic shapes. -Alex
