flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] IUIBase.js has no methods
Date Thu, 18 Sep 2014 18:59:25 GMT


On 9/18/14 11:34 AM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:

>On Thu, Sep 18, 2014 at 11:03 AM, Alex Harui <aharui@adobe.com> wrote:
>
>>
>>
>> On 9/18/14 10:47 AM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:
>>
>> >On Thu, Sep 18, 2014 at 9:07 AM, Alex Harui <aharui@adobe.com> 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


Mime
View raw message