More thinking on this.
Some Containers have both assignable children and assignable layout, where
"assignable" means the application developer gets to decide on the
children and layout.
Controls should not have assignable children, but may have assignable
layout. List, DataGrid can have different layouts for horizontal,
vertical, tile, etc.
But some Controls do not need to support assignable layout.
So, we may need a couple of new base classes for Views like an
AbsolutePositioningViewBase that set position:relative (if needed) on the
outer element. And maybe another ViewBase that expects layout to be
assigned.
Thanks,
-Alex
On 4/25/17, 8:45 AM, "Alex Harui" <aha...@adobe.com> wrote:
>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-f
>>>l
>>>e
>>>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61332.html&
>>>d
>>>a
>>>ta=02%7C01%7C%7C15aa43a0230b4d7e725c08d48bdd724c%7Cfa7b1b5a7b34438794aed
>>>2
>>>c
>>>178decee1%7C0%7C0%7C636287230601148452&sdata=OPPvWFPqY4d44ZyVe0OH7Cz5LOT
>>>h
>>>R
>>>CIo1LuXZMnUBws%3D&reserved=0
>>>Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>
>
