You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Peter Ent <pe...@adobe.com> on 2017/04/13 16:06:30 UTC
[FlexJS] Layouts
Hi,
I just pushed feature/layouts branch for your consideration. The changes in this branch affect how layouts are run. I moved code from GroupView into LayoutBase, making layouts more autonomous. That is, layouts now listen for the events they need rather than relying on GroupView to listen for the events and trigger the layout. This will make it possible for layouts to work with other types of components that are not container based.
If you check out this branch, flex-asjs should build (ant and maven) as should the examples (ant and maven). I test DataBinding, Chart, DataGrid, DateControls, and MDLExample. I know that the Mobile package does not work correctly. FlexJSStore runs but has some layout issues to address, but I don't think it will change any fundamentals with the core changes to layouts.
Regards,
Peter
Re: [FlexJS] Layouts
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi, I always say that MDL should be treated as a separate case. Take into
account that MDL use to have its own examples and ways to make things and
that doesn't has nothing to do with our layouts.
just my 2 cents :)
2017-05-05 21:51 GMT+02:00 piotrz <pi...@gmail.com>:
> I will try to look into that deeply and probably will go through this path
> in
> MDL.
>
> Thanks Peter!
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61505.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
--
<http://www.codeoscopic.com>
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] Layouts
Posted by piotrz <pi...@gmail.com>.
I will try to look into that deeply and probably will go through this path in
MDL.
Thanks Peter!
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61505.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Well, the LayoutBase assume's the host/strand implements ILayoutParent and
provides the ILayoutHost. The ILayoutHost then provides the ILayoutView.
These can all be the same thing.
The layouts in Basic assume the items being laid out are ILayoutChild
compliant. So if MDL components followed that pattern things should work
out.
‹peter
On 5/5/17, 10:58 AM, "piotrz" <pi...@gmail.com> wrote:
>Well maybe that's not bad idea - to make similar set of layouts, but, what
>would be the difference ?
>
>In general MDL should be like our Basic set of components, should be able
>to
>use such beads.
>
>Maybe I should implement to the containers View parts and move there
>appropriate logic. - In that case all layouts will be working.
>
>Any thoughts from others ?
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61501.html&da
>ta=02%7C01%7C%7Cb742d8c1f6d44087f65f08d493c8dce3%7Cfa7b1b5a7b34438794aed2c
>178decee1%7C0%7C0%7C636295938289099392&sdata=Kt0Qd5IA1PEdNjvRF0SQN87vjYl0D
>hWjLOBlPGHaeIo%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by piotrz <pi...@gmail.com>.
Well maybe that's not bad idea - to make similar set of layouts, but, what
would be the difference ?
In general MDL should be like our Basic set of components, should be able to
use such beads.
Maybe I should implement to the containers View parts and move there
appropriate logic. - In that case all layouts will be working.
Any thoughts from others ?
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61501.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Maybe MDL should have its own set of layouts and layout-compliant
interfaces. Opinions?
‹peter
On 5/5/17, 2:15 AM, "piotrz" <pi...@gmail.com> wrote:
>Hi Peter,
>
>I have found one scenario where there is a null pointer exception, but I'm
>not sure whether even we should cover such case. Let me know what do you
>think.
>
>If I have in MDL Grid with GridCell and I add to it HorizontalFlexLayout
>bead [1] I will get NPE [2], cause GridCell do not have View.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FoQRi&data=02%7C01%7C%7C247c58abd1ef48ae7de608d4937fbd81%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636295624251898329&sdata=s6R8lLuDcUjf
>x%2FSoGYvLeaBLd2a7iFtYFZMzSw2DF48%3D&reserved=0
>[2]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FHn3G&data=02%7C01%7C%7C247c58abd1ef48ae7de608d4937fbd81%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636295624251898329&sdata=dUrANaUf5Kd6
>yAmaf7NAssyRHj2clQFjfhecHxYrXJo%3D&reserved=0
>
>Thanks,
>Piotr
>
>
>
>
>
>
>-----
>Apache Flex PMC
>piotrzarzycki21@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61494.html&da
>ta=02%7C01%7C%7C247c58abd1ef48ae7de608d4937fbd81%7Cfa7b1b5a7b34438794aed2c
>178decee1%7C0%7C0%7C636295624251898329&sdata=Ezju83uKcTRx4n748WEIz9zKf8C4Z
>Qq5M1rbNuVnObY%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by piotrz <pi...@gmail.com>.
Hi Peter,
I have found one scenario where there is a null pointer exception, but I'm
not sure whether even we should cover such case. Let me know what do you
think.
If I have in MDL Grid with GridCell and I add to it HorizontalFlexLayout
bead [1] I will get NPE [2], cause GridCell do not have View.
[1] https://paste.apache.org/oQRi
[2] https://paste.apache.org/Hn3G
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61494.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I've just pushed an update to flex-asjs develop branch with
AbsolutePositioningViewBeadBase as described below. This should make it
much easier to build control component which do not need to use layout
beads and can handle resizing events on their own.
—peter
On 4/26/17, 9:05 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Let's do this then, after the merge of dual into develop:
>
>AbsolutePositioningViewBeadBase will be the view bead to use for controls.
>On the HTML platform, this bead will set its strand's style position to
>"relative" if it is not set to either "absolute" or "relative" already. In
>addition, this bead will have a setAbsolutePosition(child, x, y) function
>that on Flash, just sets x and y while on HTML, sets left and top styles
>as well as setting position:absolute style.
>
>You could use it like this: Create a view bead class that extends this
>class and set your custom view bead class in CSS for your control or add
>it programmatically. The super.strand setter will take care of setting the
>strand's position style. After you have created any elements required for
>your control, position them using setAbsolutePosition() and do so in
>response to changes in your control's size.
>
>—peter
>
>
>
>On 4/25/17, 4:47 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>On 4/25/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>>Perhaps I am not understanding this.
>>>
>>>You create a control component extending UIBase. You create your view
>>>bead
>>>extending AbsolutePositioningViewBase. This bead makes sure that the
>>>strand/host has position:relative set.
>>>
>>>So how do you set position:absolute on each of the control's parts?
>>>Setting part.x and part.y won't be enough. You still need set
>>>part.style.position = "absolute". I don't think that will translate over
>>>to the HTML side and will not be useful to Flash.
>>
>>Well, you are right that there is more to it than just the ViewBase.
>>
>>However, we are in the business of encapsulating patterns. We could do
>>any combination of the following:
>>
>>1) have setter for x and y set position="absolute" but it won't change
>>the
>>parent's position style. AbsolutePositioningViewBase would still do
>>that.
>>2) add a setChildPosition method on AbsolutePositioningViewBase.
>>3) add xChanged,yChanged listeners to children
>>4) add childAdded listener to parent and check the child's x,y value
>>
>>Thoughts?
>>-Alex
>>
>>>
>>>‹peter
>>>
>>>On 4/25/17, 2:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>>On 4/25/17, 10:55 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>>
>>>>>App devs may want to write custom controls and would expect flash and
>>>>>js
>>>>>behaviour to be the same. I think we should strive to eliminate use of
>>>>>conditional compilation for app devs. If that's so we don't want them
>>>>>changing an HTML only style (position).
>>>>
>>>>Agreed, which is why we'd offer different base classes for views, one
>>>>of
>>>>which assigns the position style.
>>>>
>>>>-Alex
>>>>
>>>
>>
>
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Let's do this then, after the merge of dual into develop:
AbsolutePositioningViewBeadBase will be the view bead to use for controls.
On the HTML platform, this bead will set its strand's style position to
"relative" if it is not set to either "absolute" or "relative" already. In
addition, this bead will have a setAbsolutePosition(child, x, y) function
that on Flash, just sets x and y while on HTML, sets left and top styles
as well as setting position:absolute style.
You could use it like this: Create a view bead class that extends this
class and set your custom view bead class in CSS for your control or add
it programmatically. The super.strand setter will take care of setting the
strand's position style. After you have created any elements required for
your control, position them using setAbsolutePosition() and do so in
response to changes in your control's size.
—peter
On 4/25/17, 4:47 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 4/25/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>Perhaps I am not understanding this.
>>
>>You create a control component extending UIBase. You create your view
>>bead
>>extending AbsolutePositioningViewBase. This bead makes sure that the
>>strand/host has position:relative set.
>>
>>So how do you set position:absolute on each of the control's parts?
>>Setting part.x and part.y won't be enough. You still need set
>>part.style.position = "absolute". I don't think that will translate over
>>to the HTML side and will not be useful to Flash.
>
>Well, you are right that there is more to it than just the ViewBase.
>
>However, we are in the business of encapsulating patterns. We could do
>any combination of the following:
>
>1) have setter for x and y set position="absolute" but it won't change the
>parent's position style. AbsolutePositioningViewBase would still do that.
>2) add a setChildPosition method on AbsolutePositioningViewBase.
>3) add xChanged,yChanged listeners to children
>4) add childAdded listener to parent and check the child's x,y value
>
>Thoughts?
>-Alex
>
>>
>>‹peter
>>
>>On 4/25/17, 2:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>On 4/25/17, 10:55 AM, "yishayw" <yi...@hotmail.com> wrote:
>>>
>>>>App devs may want to write custom controls and would expect flash and
>>>>js
>>>>behaviour to be the same. I think we should strive to eliminate use of
>>>>conditional compilation for app devs. If that's so we don't want them
>>>>changing an HTML only style (position).
>>>
>>>Agreed, which is why we'd offer different base classes for views, one of
>>>which assigns the position style.
>>>
>>>-Alex
>>>
>>
>
Re: [FlexJS] Layouts
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>Perhaps I am not understanding this.
>
>You create a control component extending UIBase. You create your view bead
>extending AbsolutePositioningViewBase. This bead makes sure that the
>strand/host has position:relative set.
>
>So how do you set position:absolute on each of the control's parts?
>Setting part.x and part.y won't be enough. You still need set
>part.style.position = "absolute". I don't think that will translate over
>to the HTML side and will not be useful to Flash.
Well, you are right that there is more to it than just the ViewBase.
However, we are in the business of encapsulating patterns. We could do
any combination of the following:
1) have setter for x and y set position="absolute" but it won't change the
parent's position style. AbsolutePositioningViewBase would still do that.
2) add a setChildPosition method on AbsolutePositioningViewBase.
3) add xChanged,yChanged listeners to children
4) add childAdded listener to parent and check the child's x,y value
Thoughts?
-Alex
>
>‹peter
>
>On 4/25/17, 2:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>On 4/25/17, 10:55 AM, "yishayw" <yi...@hotmail.com> wrote:
>>
>>>App devs may want to write custom controls and would expect flash and js
>>>behaviour to be the same. I think we should strive to eliminate use of
>>>conditional compilation for app devs. If that's so we don't want them
>>>changing an HTML only style (position).
>>
>>Agreed, which is why we'd offer different base classes for views, one of
>>which assigns the position style.
>>
>>-Alex
>>
>
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Perhaps I am not understanding this.
You create a control component extending UIBase. You create your view bead
extending AbsolutePositioningViewBase. This bead makes sure that the
strand/host has position:relative set.
So how do you set position:absolute on each of the control's parts?
Setting part.x and part.y won't be enough. You still need set
part.style.position = "absolute". I don't think that will translate over
to the HTML side and will not be useful to Flash.
‹peter
On 4/25/17, 2:08 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 4/25/17, 10:55 AM, "yishayw" <yi...@hotmail.com> wrote:
>
>>App devs may want to write custom controls and would expect flash and js
>>behaviour to be the same. I think we should strive to eliminate use of
>>conditional compilation for app devs. If that's so we don't want them
>>changing an HTML only style (position).
>
>Agreed, which is why we'd offer different base classes for views, one of
>which assigns the position style.
>
>-Alex
>
Re: [FlexJS] Layouts
Posted by Alex Harui <ah...@adobe.com>.
On 4/25/17, 10:55 AM, "yishayw" <yi...@hotmail.com> wrote:
>App devs may want to write custom controls and would expect flash and js
>behaviour to be the same. I think we should strive to eliminate use of
>conditional compilation for app devs. If that's so we don't want them
>changing an HTML only style (position).
Agreed, which is why we'd offer different base classes for views, one of
which assigns the position style.
-Alex
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
App devs may want to write custom controls and would expect flash and js
behaviour to be the same. I think we should strive to eliminate use of
conditional compilation for app devs. If that's so we don't want them
changing an HTML only style (position).
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61339.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
If AbsolutePositioningViewBase is for creating controls it sounds like a good
idea. Answers my previous post.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61341.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Alex Harui <ah...@adobe.com>.
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" <ah...@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" <pe...@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" <yi...@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.
>>
>
Re: [FlexJS] Layouts
Posted by Alex Harui <ah...@adobe.com>.
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" <pe...@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" <yi...@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.
>
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
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" <yi...@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-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61332.html&da
>ta=02%7C01%7C%7C15aa43a0230b4d7e725c08d48bdd724c%7Cfa7b1b5a7b34438794aed2c
>178decee1%7C0%7C0%7C636287230601148452&sdata=OPPvWFPqY4d44ZyVe0OH7Cz5LOThR
>CIo1LuXZMnUBws%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
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: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61332.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
This is still a little bit of a conundrum. Automatically setting
position:absolute when setting x and y (effectively left and top styles)
runs into several problems as you can imagine.
One issue is that you have to make sure the parent container's position is
either relative or absolute, otherwise the element is positioned on the
first item in the parent chain that has position relative or absolute.
This is why BasicLayout sets the host component's position if it isn't
already set.
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.
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.
Maybe there are some other ideas?
‹peter
On 4/25/17, 5:41 AM, "yishayw" <yi...@hotmail.com> wrote:
>Also, what if I'm adding elements to a UIBase (no layout)? Shouldn't I be
>able to set the absolute x and y on the added element?
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61330.html&da
>ta=02%7C01%7C%7Ce0b936af7e38411d815a08d48bc0c368%7Cfa7b1b5a7b34438794aed2c
>178decee1%7C0%7C0%7C636287107406338981&sdata=iY0A2%2FsLf%2BCVgWsNlxZl%2BBR
>C20YTFTjPuX3%2BulkUBss%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
Also, what if I'm adding elements to a UIBase (no layout)? Shouldn't I be
able to set the absolute x and y on the added element?
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61330.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
After having another look, BasicLayout loops over its children and sets their
positions to absolute. The problem with that is it requires a
dispatchEvent('layoutNeeded') every time I add an item, which is expensive.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61329.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by yishayw <yi...@hotmail.com>.
Hi Peter,
I noticed setting UIBase.x no longer changes positioning to absolute. This
probably makes sense because it was a strong side effect which could be
counter-intuitive, but what's the method for setting items absolutely now? I
searched the code base but couldn't find anywhere position in set to
absolute.
In our app lots of items are overlaid on top of one another and then
translated to other parts of the screen using a transform matrix. How do you
suggest we do this without reverting UIBase.x to set positioning to
absolute?
Thanks,
Yishay
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61327.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
The merge is complete. Alex is doing something big too but I am done.
We should put together a task list for a proper release. I think some renaming/refacotoring is in order as well as documentation.
Peter
> On Apr 15, 2017, at 12:43 PM, piotrz <pi...@gmail.com> wrote:
>
> Hi Peter,
>
> I'm following and constantly checking your changes in this branch. It look
> good. Do you think that is the last big changes in framework Api?
> Do you plan merge it to develop next week?
>
> Thanks,
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-Layouts-tp61120p61128.html&data=02%7C01%7C%7C34cce7f02f334aa64e9d08d4841e895d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636278714068445857&sdata=sewthVxykzQHYESCOCbR%2Fj2RVNvPWXDyiwPVVcTnYag%3D&reserved=0
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by piotrz <pi...@gmail.com>.
Hi Peter,
I'm following and constantly checking your changes in this branch. It look
good. Do you think that is the last big changes in framework Api?
Do you plan merge it to develop next week?
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layouts-tp61120p61128.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Layouts
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I have merged the feature/layout branch with develop. I will check the
build periodically over the weekend and fix anything if I see it has
broken because I my commit/push.
I still have to get MobileTrader example to run completely. It now looks
OK, just doesn't fully work. Once I get that done I will work on updating
the Wiki.
Thanks,
Peter
On 4/13/17, 12:06 PM, "Peter Ent" <pe...@adobe.com> wrote:
>Hi,
>
>I just pushed feature/layouts branch for your consideration. The changes
>in this branch affect how layouts are run. I moved code from GroupView
>into LayoutBase, making layouts more autonomous. That is, layouts now
>listen for the events they need rather than relying on GroupView to
>listen for the events and trigger the layout. This will make it possible
>for layouts to work with other types of components that are not container
>based.
>
>If you check out this branch, flex-asjs should build (ant and maven) as
>should the examples (ant and maven). I test DataBinding, Chart, DataGrid,
>DateControls, and MDLExample. I know that the Mobile package does not
>work correctly. FlexJSStore runs but has some layout issues to address,
>but I don't think it will change any fundamentals with the core changes
>to layouts.
>
>Regards,
>Peter