IMO, in FlexJS we want to make a distinction between Containers and
Controls.
Containers can contain arbitrary sets of children determined by the app
logic and have a layout. I'm still leaning towards renaming Group to
Container and make Container be called something like
ContainerWithViewport, but for now, Group is a "Container" in this
context. Maybe Group and Container implement IContainer.
Controls do not take arbitrary sets of children. Logic in the Control
determines the set of children. CheckBox, TextArea, and even List and
DataGrid are Controls. I'd hide the addElement APIs from the code assist
if I could find a way to do that. App devs aren't supposed to call
List.addElement. Only the List code that generates and adds the renderers
should do so.
So, if you are putting children in a Container/Group, you must choose a
Layout. If you set x/y on the children, you should choose BasicLayout.
If you are writing a Control, the View usually creates and adds and
positions the children and it can set the position:relative on the outer
element.
Does that make sense? Of course, I could be wrong...
-Alex
On 4/25/17, 6:25 AM, "Peter Ent" <p...@adobe.com> wrote:
>The x and y properties in Flash are always relative to their parent
>container. The browser world is, well I'll just say "complex" and leave it
>at that.
>
>If you do position:relative then x (left) and y (top) become positions
>relative to the nearest element in the "flow" the browser lays down. That
>is probably only partially accurate as I always have to run a half dozen
>experiments to understand the differences. We don't have anything like
>that in Flash. Eventually I want to a ConstraintLayout that makes use of
>that, but probably next release.
>
>Anyway, back to your original question. If component-specific code (i.e.,
>COMPILE::JS) is not available to component authors outside the framework
>space, then you are left with CSS.
>
>If you were to give all of your sub-elements a common class name, then you
>could do:
>
>.MyComponent .commonName {
> position:absolute;
>}
>
>And still programmatically position them using .x and .y properties. The
>Flash side will work as intended and now the JS side should as well.
>
>‹peter
>
>On 4/25/17, 9:06 AM, "yishayw" <yishayj...@hotmail.com> wrote:
>
>>Peter Ent wrote
>>> I first encourage you to base any new components on Group and then add
>>>in
>>> BasicLayout. Nothing will happen until you dispatch a layout needed
>>>event.
>>> You should be able to add multiple children and then dispatch the
>>>event.
>>
>>That's what I'm doing right now.
>>
>>
>>> We could also make a specialized Group subclass that has a
>>> positionElement(element, x, y) function that will also set
>>> position:absolute. Perhaps we could call it "BasicGroup" that would
>>>also
>>> make BasicLayout its default but you would not necessarily need to run
>>>the
>>> layout every time.
>>
>>That's not a bad idea, but again I'm curious about what we'll do for
>>components that are not based off group or container. Also, what would
>>the
>>flash behavior be? AFAIK x and y in flash act like absolute in HTML, even
>>without layout.
>>
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61332.html&d
>>a
>>ta=02%7C01%7C%7C15aa43a0230b4d7e725c08d48bdd724c%7Cfa7b1b5a7b34438794aed2
>>c
>>178decee1%7C0%7C0%7C636287230601148452&sdata=OPPvWFPqY4d44ZyVe0OH7Cz5LOTh
>>R
>>CIo1LuXZMnUBws%3D&reserved=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
