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/03/23 17:27:38 UTC
[FlexJS] Summary of Changes
FlexJS Container and Layout Upgrade
My goal when starting this process was to have FlexJS produce leaner HTML structures and to reduce the amount of JavaScript code getting cross-compiled. My latest commit does the following:
- Produces simpler HTML structures for the container classes, Group, Container, and Panel.
- Simplifies a number of the layout classes for JS while fixing or tuning the SWF code to mimic the browser.
- Moves code that only affects the SWF side into SWF code blocks.
I touched only Core and HTML projects and fixed Effects so it would compile since it had the fewest issues. MDL and Charts have larger concerns and I hope to sort those out as quickly as I can.
Here are the classes and changes you will find:
Group: This new class (introduced in a previous commit) produces the simplest container for HTML (it is just a DIV) and SWF. By default it provides no layout in case you want to style in completely using CSS. Group (and its view bead, GroupView), are the foundation of the container classes. Group runs a layout bead (if there is one) and handles the sizing of elements on the SWF side. The JS side is left alone for the browser to manage (this was the biggest change).
Container: This class, which extends Group, exists to provide scrolling on the SWF side. The JS side of Container is very light adds little to what Group does. On the SWF side, Container is a nested structure in order to providing content masking and scrolling (which is handled on the JS side by using overflow:auto style, which is all the ScrollingViewport bead will do if you add it to Container).
UIBase: The major change to UIBase is that it no longer sets the position style. That means if you set the x and y properties of a component, it will, on the JS side, only set the left and top style values. If you intend to place elements at specific pixel coordinates, use a container (Group or Container) with BasicLayout which will add position:absolute style to all of the children.
NOTE: I made UIBase (and a couple other classes, too) not set position style because I saw how easily that caused other problems, especially when there was a mixing of "absolute" and "relative" position values. Now that this work is done, it may not be a bad thing to have UIBase's x and y properties set position:absolute has a convenience. It does however, have some ramifications; if you have position:absolute that will override pretty much all of the layout types. But maybe the developer just sees this and stops setting x and y. Also, there is no way to unset position once set. These are things we will have to see how they play out.
Layouts: The layouts no longer change the size of their container hosts nor do they produce the "layoutComplete" event. The GroupView class handles both of these now to make the process of layout and sizing/positioning consistent.
Lists: The DataGroup that lists use to hold the item renderers is no longer in play. The DataGroup caused unnecessary nesting of elements (DIV inside of DIV). To break that, components like List had to become their own item renderer parents. Squaring this away is perhaps the biggest challenge since a number of complex components use List as their base. The DataContainer is now the basis for lists, with List being its first subclass since they have so much in common. The DataContainerView bead is now the basis for all list views.
Panel: The Panel is now an extension of Group and it contains three children: a TitleBar, a ControlBar (for PanelWithControlBar), and a Container for the content space. When you do: panel.addElement(object), the Panel code redirects this to its Container child. Similarly, panel.numElements tells you the number of elements in the Container child. Because Panel is now a Group (so are TitleBar and ControlBar), it uses a layout to size and position those three children. When you build your own components, you can use Group + layout to achieve the look you want with minimal HTML structure.
Interfaces: There are couple of key changes to interfaces. First, there is a new interface in the Core project: ILayoutView. This interface is implemented by any component whose children can be manipulated by a layout. The ILayoutHost interface's function, contentView, has been changed to return an instance of ILayoutView. The functions listed in ILayoutView may be expanded if we run into situations or layouts that need more information from their layout parents; this change is probably the source of most compilation issues you will see.
Using Layouts inside of Components: As stated above, Panel (and PanelWithControlBar), now uses a layout for its own purposes. This is the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose CSS creation makes the code much simpler and cleaner. Basically, the JS layout code is a few lines with maybe a loop to set each child's display correctly. The SWF side then has the task to mimic the layout. I have not completed the transition on all of the layouts, but the common ones have tested correctly.
Regards,
Peter Ent
Adobe Systems/Apache Flex Project
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
For full constrained layouts like we had in regular Flex, we’re probably going to need to use absolute positioning and JS to set the top/left values. But I’d love to see how far we can get with just CSS...
> On Mar 23, 2017, at 8:13 PM, Peter Ent <pe...@adobe.com> wrote:
>
> I want to make a layout that uses left, top, right, bottom for
> positioning. The JS side is easy of course, you do nothing!
>
> On 3/23/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> The changes look like they should be over-all improvements. Like you say,
>> we will have to see how they play out.
>>
>> There might be a need to easily flip position between absolute and
>> relative, but we¹ll see.
>>
>> I¹m looking forward to seeing how the changes behave. :-)
>>
>> Harbs
>>
>>> On Mar 23, 2017, at 7:27 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> FlexJS Container and Layout Upgrade
>>>
>>> My goal when starting this process was to have FlexJS produce leaner
>>> HTML structures and to reduce the amount of JavaScript code getting
>>> cross-compiled. My latest commit does the following:
>>>
>>> - Produces simpler HTML structures for the container classes, Group,
>>> Container, and Panel.
>>> - Simplifies a number of the layout classes for JS while fixing or
>>> tuning the SWF code to mimic the browser.
>>> - Moves code that only affects the SWF side into SWF code blocks.
>>>
>>> I touched only Core and HTML projects and fixed Effects so it would
>>> compile since it had the fewest issues. MDL and Charts have larger
>>> concerns and I hope to sort those out as quickly as I can.
>>>
>>> Here are the classes and changes you will find:
>>>
>>> Group: This new class (introduced in a previous commit) produces the
>>> simplest container for HTML (it is just a DIV) and SWF. By default it
>>> provides no layout in case you want to style in completely using CSS.
>>> Group (and its view bead, GroupView), are the foundation of the
>>> container classes. Group runs a layout bead (if there is one) and
>>> handles the sizing of elements on the SWF side. The JS side is left
>>> alone for the browser to manage (this was the biggest change).
>>>
>>> Container: This class, which extends Group, exists to provide scrolling
>>> on the SWF side. The JS side of Container is very light adds little to
>>> what Group does. On the SWF side, Container is a nested structure in
>>> order to providing content masking and scrolling (which is handled on
>>> the JS side by using overflow:auto style, which is all the
>>> ScrollingViewport bead will do if you add it to Container).
>>>
>>> UIBase: The major change to UIBase is that it no longer sets the
>>> position style. That means if you set the x and y properties of a
>>> component, it will, on the JS side, only set the left and top style
>>> values. If you intend to place elements at specific pixel coordinates,
>>> use a container (Group or Container) with BasicLayout which will add
>>> position:absolute style to all of the children.
>>>
>>> NOTE: I made UIBase (and a couple other classes, too) not set position
>>> style because I saw how easily that caused other problems, especially
>>> when there was a mixing of "absolute" and "relative" position values.
>>> Now that this work is done, it may not be a bad thing to have UIBase's x
>>> and y properties set position:absolute has a convenience. It does
>>> however, have some ramifications; if you have position:absolute that
>>> will override pretty much all of the layout types. But maybe the
>>> developer just sees this and stops setting x and y. Also, there is no
>>> way to unset position once set. These are things we will have to see how
>>> they play out.
>>>
>>> Layouts: The layouts no longer change the size of their container hosts
>>> nor do they produce the "layoutComplete" event. The GroupView class
>>> handles both of these now to make the process of layout and
>>> sizing/positioning consistent.
>>>
>>> Lists: The DataGroup that lists use to hold the item renderers is no
>>> longer in play. The DataGroup caused unnecessary nesting of elements
>>> (DIV inside of DIV). To break that, components like List had to become
>>> their own item renderer parents. Squaring this away is perhaps the
>>> biggest challenge since a number of complex components use List as their
>>> base. The DataContainer is now the basis for lists, with List being its
>>> first subclass since they have so much in common. The DataContainerView
>>> bead is now the basis for all list views.
>>>
>>> Panel: The Panel is now an extension of Group and it contains three
>>> children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>>> Container for the content space. When you do: panel.addElement(object),
>>> the Panel code redirects this to its Container child. Similarly,
>>> panel.numElements tells you the number of elements in the Container
>>> child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>>> uses a layout to size and position those three children. When you build
>>> your own components, you can use Group + layout to achieve the look you
>>> want with minimal HTML structure.
>>>
>>> Interfaces: There are couple of key changes to interfaces. First, there
>>> is a new interface in the Core project: ILayoutView. This interface is
>>> implemented by any component whose children can be manipulated by a
>>> layout. The ILayoutHost interface's function, contentView, has been
>>> changed to return an instance of ILayoutView. The functions listed in
>>> ILayoutView may be expanded if we run into situations or layouts that
>>> need more information from their layout parents; this change is probably
>>> the source of most compilation issues you will see.
>>>
>>> Using Layouts inside of Components: As stated above, Panel (and
>>> PanelWithControlBar), now uses a layout for its own purposes. This is
>>> the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general
>>> purpose CSS creation makes the code much simpler and cleaner. Basically,
>>> the JS layout code is a few lines with maybe a loop to set each child's
>>> display correctly. The SWF side then has the task to mimic the layout. I
>>> have not completed the transition on all of the layouts, but the common
>>> ones have tested correctly.
>>>
>>> Regards,
>>> Peter Ent
>>> Adobe Systems/Apache Flex Project
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
I want to make a layout that uses left, top, right, bottom for
positioning. The JS side is easy of course, you do nothing!
On 3/23/17, 2:11 PM, "Harbs" <ha...@gmail.com> wrote:
>The changes look like they should be over-all improvements. Like you say,
>we will have to see how they play out.
>
>There might be a need to easily flip position between absolute and
>relative, but we¹ll see.
>
>I¹m looking forward to seeing how the changes behave. :-)
>
>Harbs
>
>> On Mar 23, 2017, at 7:27 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> FlexJS Container and Layout Upgrade
>>
>> My goal when starting this process was to have FlexJS produce leaner
>>HTML structures and to reduce the amount of JavaScript code getting
>>cross-compiled. My latest commit does the following:
>>
>> - Produces simpler HTML structures for the container classes, Group,
>>Container, and Panel.
>> - Simplifies a number of the layout classes for JS while fixing or
>>tuning the SWF code to mimic the browser.
>> - Moves code that only affects the SWF side into SWF code blocks.
>>
>> I touched only Core and HTML projects and fixed Effects so it would
>>compile since it had the fewest issues. MDL and Charts have larger
>>concerns and I hope to sort those out as quickly as I can.
>>
>> Here are the classes and changes you will find:
>>
>> Group: This new class (introduced in a previous commit) produces the
>>simplest container for HTML (it is just a DIV) and SWF. By default it
>>provides no layout in case you want to style in completely using CSS.
>>Group (and its view bead, GroupView), are the foundation of the
>>container classes. Group runs a layout bead (if there is one) and
>>handles the sizing of elements on the SWF side. The JS side is left
>>alone for the browser to manage (this was the biggest change).
>>
>> Container: This class, which extends Group, exists to provide scrolling
>>on the SWF side. The JS side of Container is very light adds little to
>>what Group does. On the SWF side, Container is a nested structure in
>>order to providing content masking and scrolling (which is handled on
>>the JS side by using overflow:auto style, which is all the
>>ScrollingViewport bead will do if you add it to Container).
>>
>> UIBase: The major change to UIBase is that it no longer sets the
>>position style. That means if you set the x and y properties of a
>>component, it will, on the JS side, only set the left and top style
>>values. If you intend to place elements at specific pixel coordinates,
>>use a container (Group or Container) with BasicLayout which will add
>>position:absolute style to all of the children.
>>
>> NOTE: I made UIBase (and a couple other classes, too) not set position
>>style because I saw how easily that caused other problems, especially
>>when there was a mixing of "absolute" and "relative" position values.
>>Now that this work is done, it may not be a bad thing to have UIBase's x
>>and y properties set position:absolute has a convenience. It does
>>however, have some ramifications; if you have position:absolute that
>>will override pretty much all of the layout types. But maybe the
>>developer just sees this and stops setting x and y. Also, there is no
>>way to unset position once set. These are things we will have to see how
>>they play out.
>>
>> Layouts: The layouts no longer change the size of their container hosts
>>nor do they produce the "layoutComplete" event. The GroupView class
>>handles both of these now to make the process of layout and
>>sizing/positioning consistent.
>>
>> Lists: The DataGroup that lists use to hold the item renderers is no
>>longer in play. The DataGroup caused unnecessary nesting of elements
>>(DIV inside of DIV). To break that, components like List had to become
>>their own item renderer parents. Squaring this away is perhaps the
>>biggest challenge since a number of complex components use List as their
>>base. The DataContainer is now the basis for lists, with List being its
>>first subclass since they have so much in common. The DataContainerView
>>bead is now the basis for all list views.
>>
>> Panel: The Panel is now an extension of Group and it contains three
>>children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>>Container for the content space. When you do: panel.addElement(object),
>>the Panel code redirects this to its Container child. Similarly,
>>panel.numElements tells you the number of elements in the Container
>>child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>>uses a layout to size and position those three children. When you build
>>your own components, you can use Group + layout to achieve the look you
>>want with minimal HTML structure.
>>
>> Interfaces: There are couple of key changes to interfaces. First, there
>>is a new interface in the Core project: ILayoutView. This interface is
>>implemented by any component whose children can be manipulated by a
>>layout. The ILayoutHost interface's function, contentView, has been
>>changed to return an instance of ILayoutView. The functions listed in
>>ILayoutView may be expanded if we run into situations or layouts that
>>need more information from their layout parents; this change is probably
>>the source of most compilation issues you will see.
>>
>> Using Layouts inside of Components: As stated above, Panel (and
>>PanelWithControlBar), now uses a layout for its own purposes. This is
>>the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general
>>purpose CSS creation makes the code much simpler and cleaner. Basically,
>>the JS layout code is a few lines with maybe a loop to set each child's
>>display correctly. The SWF side then has the task to mimic the layout. I
>>have not completed the transition on all of the layouts, but the common
>>ones have tested correctly.
>>
>> Regards,
>> Peter Ent
>> Adobe Systems/Apache Flex Project
>>
>
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
The changes look like they should be over-all improvements. Like you say, we will have to see how they play out.
There might be a need to easily flip position between absolute and relative, but we’ll see.
I’m looking forward to seeing how the changes behave. :-)
Harbs
> On Mar 23, 2017, at 7:27 PM, Peter Ent <pe...@adobe.com> wrote:
>
> FlexJS Container and Layout Upgrade
>
> My goal when starting this process was to have FlexJS produce leaner HTML structures and to reduce the amount of JavaScript code getting cross-compiled. My latest commit does the following:
>
> - Produces simpler HTML structures for the container classes, Group, Container, and Panel.
> - Simplifies a number of the layout classes for JS while fixing or tuning the SWF code to mimic the browser.
> - Moves code that only affects the SWF side into SWF code blocks.
>
> I touched only Core and HTML projects and fixed Effects so it would compile since it had the fewest issues. MDL and Charts have larger concerns and I hope to sort those out as quickly as I can.
>
> Here are the classes and changes you will find:
>
> Group: This new class (introduced in a previous commit) produces the simplest container for HTML (it is just a DIV) and SWF. By default it provides no layout in case you want to style in completely using CSS. Group (and its view bead, GroupView), are the foundation of the container classes. Group runs a layout bead (if there is one) and handles the sizing of elements on the SWF side. The JS side is left alone for the browser to manage (this was the biggest change).
>
> Container: This class, which extends Group, exists to provide scrolling on the SWF side. The JS side of Container is very light adds little to what Group does. On the SWF side, Container is a nested structure in order to providing content masking and scrolling (which is handled on the JS side by using overflow:auto style, which is all the ScrollingViewport bead will do if you add it to Container).
>
> UIBase: The major change to UIBase is that it no longer sets the position style. That means if you set the x and y properties of a component, it will, on the JS side, only set the left and top style values. If you intend to place elements at specific pixel coordinates, use a container (Group or Container) with BasicLayout which will add position:absolute style to all of the children.
>
> NOTE: I made UIBase (and a couple other classes, too) not set position style because I saw how easily that caused other problems, especially when there was a mixing of "absolute" and "relative" position values. Now that this work is done, it may not be a bad thing to have UIBase's x and y properties set position:absolute has a convenience. It does however, have some ramifications; if you have position:absolute that will override pretty much all of the layout types. But maybe the developer just sees this and stops setting x and y. Also, there is no way to unset position once set. These are things we will have to see how they play out.
>
> Layouts: The layouts no longer change the size of their container hosts nor do they produce the "layoutComplete" event. The GroupView class handles both of these now to make the process of layout and sizing/positioning consistent.
>
> Lists: The DataGroup that lists use to hold the item renderers is no longer in play. The DataGroup caused unnecessary nesting of elements (DIV inside of DIV). To break that, components like List had to become their own item renderer parents. Squaring this away is perhaps the biggest challenge since a number of complex components use List as their base. The DataContainer is now the basis for lists, with List being its first subclass since they have so much in common. The DataContainerView bead is now the basis for all list views.
>
> Panel: The Panel is now an extension of Group and it contains three children: a TitleBar, a ControlBar (for PanelWithControlBar), and a Container for the content space. When you do: panel.addElement(object), the Panel code redirects this to its Container child. Similarly, panel.numElements tells you the number of elements in the Container child. Because Panel is now a Group (so are TitleBar and ControlBar), it uses a layout to size and position those three children. When you build your own components, you can use Group + layout to achieve the look you want with minimal HTML structure.
>
> Interfaces: There are couple of key changes to interfaces. First, there is a new interface in the Core project: ILayoutView. This interface is implemented by any component whose children can be manipulated by a layout. The ILayoutHost interface's function, contentView, has been changed to return an instance of ILayoutView. The functions listed in ILayoutView may be expanded if we run into situations or layouts that need more information from their layout parents; this change is probably the source of most compilation issues you will see.
>
> Using Layouts inside of Components: As stated above, Panel (and PanelWithControlBar), now uses a layout for its own purposes. This is the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose CSS creation makes the code much simpler and cleaner. Basically, the JS layout code is a few lines with maybe a loop to set each child's display correctly. The SWF side then has the task to mimic the layout. I have not completed the transition on all of the layouts, but the common ones have tested correctly.
>
> Regards,
> Peter Ent
> Adobe Systems/Apache Flex Project
>
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Hi Peter,
I just looked into TourJS and refreshed poms of Maven build. I think after
your changes Tree component is being broken.
Could you build TourJS and confirm. Maybe I'm doing something wrong, but I
see that content.json is being loaded.
<http://apache-flex-development.2333347.n4.nabble.com/file/n60775/tourjs_broken.png>
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60775.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Peter,
I think I have found why layout look like this. We have following structure:
<js:Panel title="Component Explorer" width="25%" height="100%"
className="Explorer">
<js:Tree id="contentTree" width="100%"
height="100%"
labelField="title"
className="ExplorerTree"
change="treeChange()"/>
</js:Panel>
Generated HTML:
<http://apache-flex-development.2333347.n4.nabble.com/file/n60776/content_tree.png>
If I change contentTree CSS to position:relative I will see "span" with
"Everytghing" text and Tree started to work.
I'm trying to understand why...
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60776.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
I'm looking at the Tour right now. When you use the Flexbox layouts, you
need to specify flex-grow:1 for anything you want to grow to fill the
remaining space; otherwise it uses its native or explicit size. You could
try to switch over to the normal horizontal and vertical layouts and see
if they work better. I'm trying to see if I can just add some styling
changes to get it to work. There is something that's tossing in
position:absolute which doesn't work well with the Flexbox layouts. I'm
not sure how much time I can spend on it today, but I'll keep plugging for
as long as I can.
The examples have each exposed some new caveats. But I'm confident the
core changes are close to right, just may need more tuning in the layouts.
‹peter
On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>Peter,
>
>I've started to experiment with your new classes in TourJS and I think
>I've
>achieved some good look, but not everything is working as expected.
>
>For some reason code of examples has not been loaded properly. If you
>could
>review my changes and give some feedback, whether I used your new classes
>in
>appropriate manner.
>
>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-Summary-of-Changes-tp60709p60
>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZUF
>AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
I forgot to add that "align-items:center" is not supported on the SWF side
yet. The Flexbox has a number of properties that I still have to implement
on the flex side.
On 3/28/17, 8:11 AM, "Peter Ent" <pe...@adobe.com> wrote:
>The HorizontalLayout and VerticalLayout do not center their content
>because the equivalent code on the JS side does not do that (at least it
>did not do that for me in the tests I ran). I think setting margin:auto is
>supposed to help with that.
>
>On the other hand, you can switch to HorizontalFlexLayout and
>VerticalFlexLayout. Then on the Group or Container CSS, do the following:
>
>.styleForVerticalFlexLayout {
> align-items: center;
>}
>
>.styleForHorizontalFlexLayout {
> align-items: center;
>}
>
>This is still a learning experience both understanding the complexities of
>CSS and building an system that generates clean and robust HTML/CSS/JS.
>
>Thank you for your patience.
>
>—peter
>
>On 3/27/17, 4:46 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>I probably need to examine the new “flex” layouts.
>>
>>Is there a way to have content centered using those?
>>
>>> On Mar 27, 2017, at 11:35 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> Better, but I still have some problems (there’s probably more):
>>>
>>> <js:Container width="100%" id="outerControls">
>>> <js:style>
>>> <js:SimpleCSSStyles backgroundColor="0x444444"/>
>>> </js:style>
>>> <js:Container id="controls">
>>> <js:style>
>>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>>> </js:style>
>>> <js:beads>
>>> <js:HorizontalLayout/>
>>> </js:beads>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="undo_clickHandler(event)" id="undoButton"
>>>src="assets/images/icons/0726-undo.svg">
>>> <js:beads>
>>> <js:DisableBead/>
>>> </js:beads>
>>> </js:ImageButton>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="redo_clickHandler(event)" id="redoButton"
>>>src="assets/images/icons/0727-redo.svg">
>>> <js:beads>
>>> <js:DisableBead/>
>>> </js:beads>
>>> </js:ImageButton>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="zoomin_clickHandler(event)"
>>>src="assets/images/icons/0806-zoom-in.svg"/>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="zoomout_clickHandler(event)"
>>>src="assets/images/icons/0807-zoom-out.svg"/>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="fitButton_clickHandler(event)"
>>>src="assets/images/icons/0843-expand.svg"/>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="previewButton_clickHandler(event)"
>>>src="assets/images/icons/0786-file-preview-white.svg"/>
>>> <js:Spacer width="10"/>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="finishButton_clickHandler()"
>>>src="assets/images/icons/0821-check.svg"/>
>>> <js:Spacer width="10"/>
>>> <js:ImageButton className="iconButton white" width="30" height="30"
>>>click="cancelButton_clickHandler()"
>>>src="assets/images/icons/0822-cross2.svg"/>
>>> </js:Container>
>>>
>>> 1. This used to create a centered group of buttons. Now, the container
>>>has a height of 0 and the buttons don’t show up.
>>>
>>> 2.
>>> <js:Container className="designOuterContainer" id="scrollContainer"
>>>width="100%" height="100%">
>>> <js:beads>
>>> <js:ScrollingViewport/>
>>> </js:beads>
>>> <components:DesignAreaHolder id="designContainer"
>>>className="_holder" y="0">
>>> <components:style>
>>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>>> </components:style>
>>> </components:DesignAreaHolder>
>>>
>>> </js:Container>
>>>
>>> This used to create a scrolling div that was centered in the the
>>>window. It now is aligned left, and I don’t know if it scrolls.
>>>
>>> There’s other issues, and I’ll see tomorrow what I can work around.
>>>
>>>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I just pushed a change to UIBase to set position="absolute" when
>>>>setting x
>>>> or y. I think this is perfectly safe and if someone does set x and y
>>>>and
>>>> then tries to use a layout where that would be a conflict, they will
>>>>get
>>>> have to avoid setting those properties.
>>>>
>>>> I figured this would eventually happen. Let's see if this fixes the
>>>>issue.
>>>>
>>>> —peter
>>>>
>>>>
>>>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> I just tried loading my app with your changes, and everything is
>>>>>totally
>>>>> borked. We rely a lot on absolute positioning and transformations.
>>>>>
>>>>> We really need the old behavior in some components.
>>>>>
>>>>> Is there any components which work the same as they used to?
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>>>
>>>>>> For the time being, the Tour main view should have a width and a
>>>>>>height:
>>>>>>
>>>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>>>
>>>>>> Then in the style section, give everything flex-grow: 1; and it
>>>>>>should
>>>>>> look better. I think some padding and/or margins might be needed,
>>>>>>but I
>>>>>> think I have more work do with the layouts. I'll bump getting the
>>>>>>tour
>>>>>> to
>>>>>> the top of the list for this week because I think its nesting of
>>>>>> elements
>>>>>> is a good test. I think it is just a matter of setting the style
>>>>>>values
>>>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>>>
>>>>>> ‹peter
>>>>>>
>>>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>>>
>>>>>>> Peter,
>>>>>>>
>>>>>>> I've started to experiment with your new classes in TourJS and I
>>>>>>>think
>>>>>>> I've
>>>>>>> achieved some good look, but not everything is working as expected.
>>>>>>>
>>>>>>> For some reason code of examples has not been loaded properly. If
>>>>>>>you
>>>>>>> could
>>>>>>> review my changes and give some feedback, whether I used your new
>>>>>>> classes
>>>>>>> in
>>>>>>> appropriate manner.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piotr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----
>>>>>>> Apache Flex PMC
>>>>>>> piotrzarzycki21@gmail.com
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
>>>>>>>h
>>>>>>>e-f
>>>>>>> le
>>>>>>>
>>>>>>>
>>>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60
>>>>>>>7
>>>>>>>09p
>>>>>>> 60
>>>>>>>
>>>>>>>
>>>>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b
>>>>>>>5
>>>>>>>a7b
>>>>>>> 34
>>>>>>>
>>>>>>>
>>>>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdggl
>>>>>>>Z
>>>>>>>FzZ
>>>>>>> UF
>>>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>>> Nabble.com.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
The HorizontalLayout and VerticalLayout do not center their content
because the equivalent code on the JS side does not do that (at least it
did not do that for me in the tests I ran). I think setting margin:auto is
supposed to help with that.
On the other hand, you can switch to HorizontalFlexLayout and
VerticalFlexLayout. Then on the Group or Container CSS, do the following:
.styleForVerticalFlexLayout {
align-items: center;
}
.styleForHorizontalFlexLayout {
align-items: center;
}
This is still a learning experience both understanding the complexities of
CSS and building an system that generates clean and robust HTML/CSS/JS.
Thank you for your patience.
—peter
On 3/27/17, 4:46 PM, "Harbs" <ha...@gmail.com> wrote:
>I probably need to examine the new “flex” layouts.
>
>Is there a way to have content centered using those?
>
>> On Mar 27, 2017, at 11:35 PM, Harbs <ha...@gmail.com> wrote:
>>
>> Better, but I still have some problems (there’s probably more):
>>
>> <js:Container width="100%" id="outerControls">
>> <js:style>
>> <js:SimpleCSSStyles backgroundColor="0x444444"/>
>> </js:style>
>> <js:Container id="controls">
>> <js:style>
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> </js:style>
>> <js:beads>
>> <js:HorizontalLayout/>
>> </js:beads>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="undo_clickHandler(event)" id="undoButton"
>>src="assets/images/icons/0726-undo.svg">
>> <js:beads>
>> <js:DisableBead/>
>> </js:beads>
>> </js:ImageButton>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="redo_clickHandler(event)" id="redoButton"
>>src="assets/images/icons/0727-redo.svg">
>> <js:beads>
>> <js:DisableBead/>
>> </js:beads>
>> </js:ImageButton>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="zoomin_clickHandler(event)"
>>src="assets/images/icons/0806-zoom-in.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="zoomout_clickHandler(event)"
>>src="assets/images/icons/0807-zoom-out.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="fitButton_clickHandler(event)"
>>src="assets/images/icons/0843-expand.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="previewButton_clickHandler(event)"
>>src="assets/images/icons/0786-file-preview-white.svg"/>
>> <js:Spacer width="10"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="finishButton_clickHandler()"
>>src="assets/images/icons/0821-check.svg"/>
>> <js:Spacer width="10"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="cancelButton_clickHandler()"
>>src="assets/images/icons/0822-cross2.svg"/>
>> </js:Container>
>>
>> 1. This used to create a centered group of buttons. Now, the container
>>has a height of 0 and the buttons don’t show up.
>>
>> 2.
>> <js:Container className="designOuterContainer" id="scrollContainer"
>>width="100%" height="100%">
>> <js:beads>
>> <js:ScrollingViewport/>
>> </js:beads>
>> <components:DesignAreaHolder id="designContainer"
>>className="_holder" y="0">
>> <components:style>
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> </components:style>
>> </components:DesignAreaHolder>
>>
>> </js:Container>
>>
>> This used to create a scrolling div that was centered in the the
>>window. It now is aligned left, and I don’t know if it scrolls.
>>
>> There’s other issues, and I’ll see tomorrow what I can work around.
>>
>>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> Hi,
>>>
>>> I just pushed a change to UIBase to set position="absolute" when
>>>setting x
>>> or y. I think this is perfectly safe and if someone does set x and y
>>>and
>>> then tries to use a layout where that would be a conflict, they will
>>>get
>>> have to avoid setting those properties.
>>>
>>> I figured this would eventually happen. Let's see if this fixes the
>>>issue.
>>>
>>> —peter
>>>
>>>
>>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> Peter,
>>>>
>>>> I just tried loading my app with your changes, and everything is
>>>>totally
>>>> borked. We rely a lot on absolute positioning and transformations.
>>>>
>>>> We really need the old behavior in some components.
>>>>
>>>> Is there any components which work the same as they used to?
>>>>
>>>> Harbs
>>>>
>>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>>
>>>>> For the time being, the Tour main view should have a width and a
>>>>>height:
>>>>>
>>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>>
>>>>> Then in the style section, give everything flex-grow: 1; and it
>>>>>should
>>>>> look better. I think some padding and/or margins might be needed,
>>>>>but I
>>>>> think I have more work do with the layouts. I'll bump getting the
>>>>>tour
>>>>> to
>>>>> the top of the list for this week because I think its nesting of
>>>>> elements
>>>>> is a good test. I think it is just a matter of setting the style
>>>>>values
>>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>>
>>>>> ‹peter
>>>>>
>>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>>
>>>>>> Peter,
>>>>>>
>>>>>> I've started to experiment with your new classes in TourJS and I
>>>>>>think
>>>>>> I've
>>>>>> achieved some good look, but not everything is working as expected.
>>>>>>
>>>>>> For some reason code of examples has not been loaded properly. If
>>>>>>you
>>>>>> could
>>>>>> review my changes and give some feedback, whether I used your new
>>>>>> classes
>>>>>> in
>>>>>> appropriate manner.
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> Apache Flex PMC
>>>>>> piotrzarzycki21@gmail.com
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapach
>>>>>>e-f
>>>>>> le
>>>>>>
>>>>>>
>>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp607
>>>>>>09p
>>>>>> 60
>>>>>>
>>>>>>
>>>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5
>>>>>>a7b
>>>>>> 34
>>>>>>
>>>>>>
>>>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZ
>>>>>>FzZ
>>>>>> UF
>>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>> Nabble.com.
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Harbs -
I have to rollback the setting of position="absolute" (when setting .x or
.y properties) on my next commit. This is causing other examples to behave
weirdly in situations where the parent of the element whose position is
being set does not itself have a position set.
After talking with Alex, I think the better solution is to use more
layouts. Since you are using Container whose default layout is Basic, you
should not always have a problem since BasicLayout will go through the
children and set their positions to "absolute" and set the position on the
container DIV itself to "relative".
If you are building a component and want to set sub-pieces to specific
locations, then perhaps your component should extend Group and add in a
BasicLayout bead; just make sure you dispatch a "layoutNeeded" event on
the Group. And if this is the way to proceed, we could make a
ComponentBase class that simply extended Group and added in BasicLayout as
its default layout.
—peter
On 3/27/17, 4:46 PM, "Harbs" <ha...@gmail.com> wrote:
>I probably need to examine the new “flex” layouts.
>
>Is there a way to have content centered using those?
>
>> On Mar 27, 2017, at 11:35 PM, Harbs <ha...@gmail.com> wrote:
>>
>> Better, but I still have some problems (there’s probably more):
>>
>> <js:Container width="100%" id="outerControls">
>> <js:style>
>> <js:SimpleCSSStyles backgroundColor="0x444444"/>
>> </js:style>
>> <js:Container id="controls">
>> <js:style>
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> </js:style>
>> <js:beads>
>> <js:HorizontalLayout/>
>> </js:beads>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="undo_clickHandler(event)" id="undoButton"
>>src="assets/images/icons/0726-undo.svg">
>> <js:beads>
>> <js:DisableBead/>
>> </js:beads>
>> </js:ImageButton>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="redo_clickHandler(event)" id="redoButton"
>>src="assets/images/icons/0727-redo.svg">
>> <js:beads>
>> <js:DisableBead/>
>> </js:beads>
>> </js:ImageButton>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="zoomin_clickHandler(event)"
>>src="assets/images/icons/0806-zoom-in.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="zoomout_clickHandler(event)"
>>src="assets/images/icons/0807-zoom-out.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="fitButton_clickHandler(event)"
>>src="assets/images/icons/0843-expand.svg"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="previewButton_clickHandler(event)"
>>src="assets/images/icons/0786-file-preview-white.svg"/>
>> <js:Spacer width="10"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="finishButton_clickHandler()"
>>src="assets/images/icons/0821-check.svg"/>
>> <js:Spacer width="10"/>
>> <js:ImageButton className="iconButton white" width="30" height="30"
>>click="cancelButton_clickHandler()"
>>src="assets/images/icons/0822-cross2.svg"/>
>> </js:Container>
>>
>> 1. This used to create a centered group of buttons. Now, the container
>>has a height of 0 and the buttons don’t show up.
>>
>> 2.
>> <js:Container className="designOuterContainer" id="scrollContainer"
>>width="100%" height="100%">
>> <js:beads>
>> <js:ScrollingViewport/>
>> </js:beads>
>> <components:DesignAreaHolder id="designContainer"
>>className="_holder" y="0">
>> <components:style>
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> </components:style>
>> </components:DesignAreaHolder>
>>
>> </js:Container>
>>
>> This used to create a scrolling div that was centered in the the
>>window. It now is aligned left, and I don’t know if it scrolls.
>>
>> There’s other issues, and I’ll see tomorrow what I can work around.
>>
>>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> Hi,
>>>
>>> I just pushed a change to UIBase to set position="absolute" when
>>>setting x
>>> or y. I think this is perfectly safe and if someone does set x and y
>>>and
>>> then tries to use a layout where that would be a conflict, they will
>>>get
>>> have to avoid setting those properties.
>>>
>>> I figured this would eventually happen. Let's see if this fixes the
>>>issue.
>>>
>>> —peter
>>>
>>>
>>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> Peter,
>>>>
>>>> I just tried loading my app with your changes, and everything is
>>>>totally
>>>> borked. We rely a lot on absolute positioning and transformations.
>>>>
>>>> We really need the old behavior in some components.
>>>>
>>>> Is there any components which work the same as they used to?
>>>>
>>>> Harbs
>>>>
>>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>>
>>>>> For the time being, the Tour main view should have a width and a
>>>>>height:
>>>>>
>>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>>
>>>>> Then in the style section, give everything flex-grow: 1; and it
>>>>>should
>>>>> look better. I think some padding and/or margins might be needed,
>>>>>but I
>>>>> think I have more work do with the layouts. I'll bump getting the
>>>>>tour
>>>>> to
>>>>> the top of the list for this week because I think its nesting of
>>>>> elements
>>>>> is a good test. I think it is just a matter of setting the style
>>>>>values
>>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>>
>>>>> ‹peter
>>>>>
>>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>>
>>>>>> Peter,
>>>>>>
>>>>>> I've started to experiment with your new classes in TourJS and I
>>>>>>think
>>>>>> I've
>>>>>> achieved some good look, but not everything is working as expected.
>>>>>>
>>>>>> For some reason code of examples has not been loaded properly. If
>>>>>>you
>>>>>> could
>>>>>> review my changes and give some feedback, whether I used your new
>>>>>> classes
>>>>>> in
>>>>>> appropriate manner.
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> Apache Flex PMC
>>>>>> piotrzarzycki21@gmail.com
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapach
>>>>>>e-f
>>>>>> le
>>>>>>
>>>>>>
>>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp607
>>>>>>09p
>>>>>> 60
>>>>>>
>>>>>>
>>>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5
>>>>>>a7b
>>>>>> 34
>>>>>>
>>>>>>
>>>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZ
>>>>>>FzZ
>>>>>> UF
>>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>> Nabble.com.
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
I probably need to examine the new “flex” layouts.
Is there a way to have content centered using those?
> On Mar 27, 2017, at 11:35 PM, Harbs <ha...@gmail.com> wrote:
>
> Better, but I still have some problems (there’s probably more):
>
> <js:Container width="100%" id="outerControls">
> <js:style>
> <js:SimpleCSSStyles backgroundColor="0x444444"/>
> </js:style>
> <js:Container id="controls">
> <js:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </js:style>
> <js:beads>
> <js:HorizontalLayout/>
> </js:beads>
> <js:ImageButton className="iconButton white" width="30" height="30" click="undo_clickHandler(event)" id="undoButton" src="assets/images/icons/0726-undo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30" click="redo_clickHandler(event)" id="redoButton" src="assets/images/icons/0727-redo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30" click="zoomin_clickHandler(event)" src="assets/images/icons/0806-zoom-in.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30" click="zoomout_clickHandler(event)" src="assets/images/icons/0807-zoom-out.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30" click="fitButton_clickHandler(event)" src="assets/images/icons/0843-expand.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30" click="previewButton_clickHandler(event)" src="assets/images/icons/0786-file-preview-white.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30" click="finishButton_clickHandler()" src="assets/images/icons/0821-check.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30" click="cancelButton_clickHandler()" src="assets/images/icons/0822-cross2.svg"/>
> </js:Container>
>
> 1. This used to create a centered group of buttons. Now, the container has a height of 0 and the buttons don’t show up.
>
> 2.
> <js:Container className="designOuterContainer" id="scrollContainer" width="100%" height="100%">
> <js:beads>
> <js:ScrollingViewport/>
> </js:beads>
> <components:DesignAreaHolder id="designContainer" className="_holder" y="0">
> <components:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </components:style>
> </components:DesignAreaHolder>
>
> </js:Container>
>
> This used to create a scrolling div that was centered in the the window. It now is aligned left, and I don’t know if it scrolls.
>
> There’s other issues, and I’ll see tomorrow what I can work around.
>
>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> Hi,
>>
>> I just pushed a change to UIBase to set position="absolute" when setting x
>> or y. I think this is perfectly safe and if someone does set x and y and
>> then tries to use a layout where that would be a conflict, they will get
>> have to avoid setting those properties.
>>
>> I figured this would eventually happen. Let's see if this fixes the issue.
>>
>> —peter
>>
>>
>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Peter,
>>>
>>> I just tried loading my app with your changes, and everything is totally
>>> borked. We rely a lot on absolute positioning and transformations.
>>>
>>> We really need the old behavior in some components.
>>>
>>> Is there any components which work the same as they used to?
>>>
>>> Harbs
>>>
>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> For the time being, the Tour main view should have a width and a height:
>>>>
>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>
>>>> Then in the style section, give everything flex-grow: 1; and it should
>>>> look better. I think some padding and/or margins might be needed, but I
>>>> think I have more work do with the layouts. I'll bump getting the tour
>>>> to
>>>> the top of the list for this week because I think its nesting of
>>>> elements
>>>> is a good test. I think it is just a matter of setting the style values
>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>
>>>> ‹peter
>>>>
>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> I've started to experiment with your new classes in TourJS and I think
>>>>> I've
>>>>> achieved some good look, but not everything is working as expected.
>>>>>
>>>>> For some reason code of examples has not been loaded properly. If you
>>>>> could
>>>>> review my changes and give some feedback, whether I used your new
>>>>> classes
>>>>> in
>>>>> appropriate manner.
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> Apache Flex PMC
>>>>> piotrzarzycki21@gmail.com
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>>> le
>>>>>
>>>>> x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p
>>>>> 60
>>>>>
>>>>> 779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b
>>>>> 34
>>>>>
>>>>> 438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZ
>>>>> UF
>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com.
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
I just pushed a change to the tour code. It should be better. We should be
able to do this with the regular horizontal and vertical layouts with %
sizing, I think, and not just with Flexbox layouts.
One thing I changed was to remove the grow="1" on the layouts. I put that
in there to make it easy when you wanted everything the same size; maybe
it should have been equalSizes=true to be clearer. What happened was that
the height of the button bar (which I set to an explicit 40 just be
certain) was overridden with flex-grow:1. I also gave some other items
flex-grow:1.
I hope it is better.
‹peter
On 3/28/17, 9:22 AM, "piotrz" <pi...@gmail.com> wrote:
>Peter,
>
>Could you look into TourJS, maybe there you also found some issue with
>layout there. I'm really interesting how to resolve it there.
>
>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-Summary-of-Changes-tp60709p60
>845.html&data=02%7C01%7C%7C7bf7b688a84b4f6fe97708d475de9039%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636263046144396713&sdata=8blALd9qJE6NYqnhdx
>ex8aXxNXeY2ZK0xZpyj95yTU8%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Peter,
Could you look into TourJS, maybe there you also found some issue with
layout there. I'm really interesting how to resolve it there.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60845.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Here is a link to a Pasteboard [1] that should help. It is a set of nested
Panels. If you run this on both SWF and HTML, you'll see differences due
to the fact that the SWF side does not yet handle all of the CSS.
The HTML should be a nesting of hideously colored boxes with their content
centered.
Using Flexbox, you center along the major axis using
justify-content:center and along the second axis using align-items:center.
The justify-content style is how the collection of children along the
major axis are positioned and spaced while align-items positions the
elements of the collection within the box in the second dimension.
Another thing to keep in mind with Flexbox is the size of individual
items. Start off with specifying no size at all. This will expand the item
along the second axis. In the vertical, it will make each item as wide as
the div while in the horizontal it will make each item as tall as the div.
If you give a size to the secondary dimension (width for vertical box and
height for horizontal box), those values should be honored. See that the
buttons for the leftSide Panel have a width specified as 70px.
The flex-grow and flex-shrink styles apply to individual items for the
main axis. You'll see that in the rightSide Panel that the items (Groups)
have flex-grow:1; since they have the same grow value they expand to fill
the space equally. Flexbox supports different grow values but the SWF-side
version supports only flex-grow of 1 or 0. The 0 means to honor the
element's given size for that dimension.
I hope I explained that clearly enough! You can see why this is taking a
bit longer to sort out.
—peter
[1] https://paste.apache.org/cgoQ
On 3/27/17, 5:48 PM, "Greg Dove" <gr...@gmail.com> wrote:
>I've just done a sweep through one project fixing our 'borked' stuff, I
>guess the latest change might re-'bork' some of the fixes, but I think at
>least these changes should be easier to address.
>
>Sometimes I needed to swap a Container to a Group and other times not,
>because of the relative/absolute changes.
>I found it easier to migrate a lot of the layout stuff to pure css for now
>using flexbox, thinking that doing so might insulate us from further
>changes in the coded layout support. We would have the ability to swap
>back
>to beads etc later if we want to have that in the mxml, once things have
>become stable.
>
>
>On Tue, Mar 28, 2017 at 9:52 AM, Peter Ent <pe...@adobe.com> wrote:
>
>> Does the HTML look OK - the structure. Is there anything missing? You
>> should see a simplified nesting of DIVs. If that's the case, then maybe
>> there is more work to do with the layouts.
>>
>> The topmost Container, outer controls, doesn't look like it has a
>>layout,
>> so with Container that should default to BasicLayout. That's one thing
>>to
>> check.
>>
>> Does the Container with id scrollContainer have a parent somewhere with
>>a
>> fixed width and height? The auto margins should still work for HTML.
>> Mostly the work is on the SWF side; the JS code was "cleaned up" so
>>maybe
>> that's the problem. I took out much of the algorithmic code for Vertical
>> and Horizontal layout since I believe HTML would respond property to the
>> addition of children, removal of children, resizing, etc. I did have,
>>if I
>> remember correctly, to add "white-space:nowrap" to the
>>HorizontalLayout; I
>> don't know that will affect you.
>>
>> Would you mind tinker with the HTML DOM in the browser to see if you can
>> get the look you want? That will help determine if the layout code needs
>> to be adjusted.
>>
>> Thanks and so sorry for the problems. *must use feature branch next
>>time*
>> —peter
>>
>> On 3/27/17, 4:35 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >Better, but I still have some problems (there’s probably more):
>> >
>> > <js:Container width="100%" id="outerControls">
>> > <js:style>
>> > <js:SimpleCSSStyles
>> backgroundColor="0x444444"/>
>> > </js:style>
>> > <js:Container id="controls">
>> > <js:style>
>> > <js:SimpleCSSStyles
>> marginLeft="auto" marginRight="auto"/>
>> > </js:style>
>> > <js:beads>
>> > <js:HorizontalLayout/>
>> > </js:beads>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="undo_clickHandler(event)" id="undoButton"
>> >src="assets/images/icons/0726-undo.svg">
>> > <js:beads>
>> > <js:DisableBead/>
>> > </js:beads>
>> > </js:ImageButton>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="redo_clickHandler(event)" id="redoButton"
>> >src="assets/images/icons/0727-redo.svg">
>> > <js:beads>
>> > <js:DisableBead/>
>> > </js:beads>
>> > </js:ImageButton>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="zoomin_clickHandler(event)"
>> >src="assets/images/icons/0806-zoom-in.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="zoomout_clickHandler(event)"
>> >src="assets/images/icons/0807-zoom-out.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="fitButton_clickHandler(event)"
>> >src="assets/images/icons/0843-expand.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="previewButton_clickHandler(event)"
>> >src="assets/images/icons/0786-file-preview-white.svg"/>
>> > <js:Spacer width="10"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="finishButton_clickHandler()"
>> >src="assets/images/icons/0821-check.svg"/>
>> > <js:Spacer width="10"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="cancelButton_clickHandler()"
>> >src="assets/images/icons/0822-cross2.svg"/>
>> > </js:Container>
>> >
>> >1. This used to create a centered group of buttons. Now, the container
>> >has a height of 0 and the buttons don’t show up.
>> >
>> >2.
>> > <js:Container
>>className="designOuterContainer"
>> id="scrollContainer"
>> >width="100%" height="100%">
>> > <js:beads>
>> > <js:ScrollingViewport/>
>> > </js:beads>
>> > <components:DesignAreaHolder
>> id="designContainer"
>> >className="_holder" y="0">
>> > <components:style>
>> >
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> > </components:style>
>> > </components:DesignAreaHolder>
>> >
>> > </js:Container>
>> >
>> >This used to create a scrolling div that was centered in the the
>>window.
>> >It now is aligned left, and I don’t know if it scrolls.
>> >
>> >There’s other issues, and I’ll see tomorrow what I can work around.
>> >
>> >> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I just pushed a change to UIBase to set position="absolute" when
>> >>setting x
>> >> or y. I think this is perfectly safe and if someone does set x and y
>>and
>> >> then tries to use a layout where that would be a conflict, they will
>>get
>> >> have to avoid setting those properties.
>> >>
>> >> I figured this would eventually happen. Let's see if this fixes the
>> >>issue.
>> >>
>> >> —peter
>> >>
>> >>
>> >> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>> >>
>> >>> Peter,
>> >>>
>> >>> I just tried loading my app with your changes, and everything is
>> >>>totally
>> >>> borked. We rely a lot on absolute positioning and transformations.
>> >>>
>> >>> We really need the old behavior in some components.
>> >>>
>> >>> Is there any components which work the same as they used to?
>> >>>
>> >>> Harbs
>> >>>
>> >>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>> >>>>
>> >>>> For the time being, the Tour main view should have a width and a
>> >>>>height:
>> >>>>
>> >>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>> >>>>
>> >>>> Then in the style section, give everything flex-grow: 1; and it
>>should
>> >>>> look better. I think some padding and/or margins might be needed,
>>but
>> >>>>I
>> >>>> think I have more work do with the layouts. I'll bump getting the
>>tour
>> >>>> to
>> >>>> the top of the list for this week because I think its nesting of
>> >>>> elements
>> >>>> is a good test. I think it is just a matter of setting the style
>> >>>>values
>> >>>> right. HTML structure-wise it looks fine, so that's good.
>> >>>>
>> >>>> ‹peter
>> >>>>
>> >>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>> >>>>
>> >>>>> Peter,
>> >>>>>
>> >>>>> I've started to experiment with your new classes in TourJS and I
>> >>>>>think
>> >>>>> I've
>> >>>>> achieved some good look, but not everything is working as
>>expected.
>> >>>>>
>> >>>>> For some reason code of examples has not been loaded properly. If
>>you
>> >>>>> could
>> >>>>> review my changes and give some feedback, whether I used your new
>> >>>>> classes
>> >>>>> in
>> >>>>> appropriate manner.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Piotr
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -----
>> >>>>> Apache Flex PMC
>> >>>>> piotrzarzycki21@gmail.com
>> >>>>> --
>> >>>>> View this message in context:
>> >>>>>
>> >>>>>
>> >>>>>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fapache
>> >>>>>-f
>> >>>>> le
>> >>>>>
>> >>>>>
>> >>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-
>> of-Changes-tp6070
>> >>>>>9p
>> >>>>> 60
>> >>>>>
>> >>>>>
>> >>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e
>> 47ea%7Cfa7b1b5a
>> >>>>>7b
>> >>>>> 34
>> >>>>>
>> >>>>>
>> >>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&
>> sdata=29GdLLPJdgglZF
>> >>>>>zZ
>> >>>>> UF
>> >>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>> >>>>> Sent from the Apache Flex Development mailing list archive at
>> >>>>> Nabble.com.
>> >>>>
>> >>>
>> >>
>> >
>>
>>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
I just built another test where I nested Panels in Panels in Panels (since
they are compound components) and found some of the layouts still not
working right on the JS side.
It looks to me like the problem is not setting the style attributes right
using Flexbox. While I spent a good deal of time trying to understand
this, I think the algorithmic approach isn't applying the styles correctly
in all cases. I'm trying to figure out exactly why my structure isn't
styled correctly. Please stay tuned…
-peter
On 3/27/17, 5:48 PM, "Greg Dove" <gr...@gmail.com> wrote:
>I've just done a sweep through one project fixing our 'borked' stuff, I
>guess the latest change might re-'bork' some of the fixes, but I think at
>least these changes should be easier to address.
>
>Sometimes I needed to swap a Container to a Group and other times not,
>because of the relative/absolute changes.
>I found it easier to migrate a lot of the layout stuff to pure css for now
>using flexbox, thinking that doing so might insulate us from further
>changes in the coded layout support. We would have the ability to swap
>back
>to beads etc later if we want to have that in the mxml, once things have
>become stable.
>
>
>On Tue, Mar 28, 2017 at 9:52 AM, Peter Ent <pe...@adobe.com> wrote:
>
>> Does the HTML look OK - the structure. Is there anything missing? You
>> should see a simplified nesting of DIVs. If that's the case, then maybe
>> there is more work to do with the layouts.
>>
>> The topmost Container, outer controls, doesn't look like it has a
>>layout,
>> so with Container that should default to BasicLayout. That's one thing
>>to
>> check.
>>
>> Does the Container with id scrollContainer have a parent somewhere with
>>a
>> fixed width and height? The auto margins should still work for HTML.
>> Mostly the work is on the SWF side; the JS code was "cleaned up" so
>>maybe
>> that's the problem. I took out much of the algorithmic code for Vertical
>> and Horizontal layout since I believe HTML would respond property to the
>> addition of children, removal of children, resizing, etc. I did have,
>>if I
>> remember correctly, to add "white-space:nowrap" to the
>>HorizontalLayout; I
>> don't know that will affect you.
>>
>> Would you mind tinker with the HTML DOM in the browser to see if you can
>> get the look you want? That will help determine if the layout code needs
>> to be adjusted.
>>
>> Thanks and so sorry for the problems. *must use feature branch next
>>time*
>> —peter
>>
>> On 3/27/17, 4:35 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >Better, but I still have some problems (there’s probably more):
>> >
>> > <js:Container width="100%" id="outerControls">
>> > <js:style>
>> > <js:SimpleCSSStyles
>> backgroundColor="0x444444"/>
>> > </js:style>
>> > <js:Container id="controls">
>> > <js:style>
>> > <js:SimpleCSSStyles
>> marginLeft="auto" marginRight="auto"/>
>> > </js:style>
>> > <js:beads>
>> > <js:HorizontalLayout/>
>> > </js:beads>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="undo_clickHandler(event)" id="undoButton"
>> >src="assets/images/icons/0726-undo.svg">
>> > <js:beads>
>> > <js:DisableBead/>
>> > </js:beads>
>> > </js:ImageButton>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="redo_clickHandler(event)" id="redoButton"
>> >src="assets/images/icons/0727-redo.svg">
>> > <js:beads>
>> > <js:DisableBead/>
>> > </js:beads>
>> > </js:ImageButton>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="zoomin_clickHandler(event)"
>> >src="assets/images/icons/0806-zoom-in.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="zoomout_clickHandler(event)"
>> >src="assets/images/icons/0807-zoom-out.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="fitButton_clickHandler(event)"
>> >src="assets/images/icons/0843-expand.svg"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="previewButton_clickHandler(event)"
>> >src="assets/images/icons/0786-file-preview-white.svg"/>
>> > <js:Spacer width="10"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="finishButton_clickHandler()"
>> >src="assets/images/icons/0821-check.svg"/>
>> > <js:Spacer width="10"/>
>> > <js:ImageButton className="iconButton
>> white" width="30" height="30"
>> >click="cancelButton_clickHandler()"
>> >src="assets/images/icons/0822-cross2.svg"/>
>> > </js:Container>
>> >
>> >1. This used to create a centered group of buttons. Now, the container
>> >has a height of 0 and the buttons don’t show up.
>> >
>> >2.
>> > <js:Container
>>className="designOuterContainer"
>> id="scrollContainer"
>> >width="100%" height="100%">
>> > <js:beads>
>> > <js:ScrollingViewport/>
>> > </js:beads>
>> > <components:DesignAreaHolder
>> id="designContainer"
>> >className="_holder" y="0">
>> > <components:style>
>> >
>> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
>> > </components:style>
>> > </components:DesignAreaHolder>
>> >
>> > </js:Container>
>> >
>> >This used to create a scrolling div that was centered in the the
>>window.
>> >It now is aligned left, and I don’t know if it scrolls.
>> >
>> >There’s other issues, and I’ll see tomorrow what I can work around.
>> >
>> >> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I just pushed a change to UIBase to set position="absolute" when
>> >>setting x
>> >> or y. I think this is perfectly safe and if someone does set x and y
>>and
>> >> then tries to use a layout where that would be a conflict, they will
>>get
>> >> have to avoid setting those properties.
>> >>
>> >> I figured this would eventually happen. Let's see if this fixes the
>> >>issue.
>> >>
>> >> —peter
>> >>
>> >>
>> >> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>> >>
>> >>> Peter,
>> >>>
>> >>> I just tried loading my app with your changes, and everything is
>> >>>totally
>> >>> borked. We rely a lot on absolute positioning and transformations.
>> >>>
>> >>> We really need the old behavior in some components.
>> >>>
>> >>> Is there any components which work the same as they used to?
>> >>>
>> >>> Harbs
>> >>>
>> >>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>> >>>>
>> >>>> For the time being, the Tour main view should have a width and a
>> >>>>height:
>> >>>>
>> >>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>> >>>>
>> >>>> Then in the style section, give everything flex-grow: 1; and it
>>should
>> >>>> look better. I think some padding and/or margins might be needed,
>>but
>> >>>>I
>> >>>> think I have more work do with the layouts. I'll bump getting the
>>tour
>> >>>> to
>> >>>> the top of the list for this week because I think its nesting of
>> >>>> elements
>> >>>> is a good test. I think it is just a matter of setting the style
>> >>>>values
>> >>>> right. HTML structure-wise it looks fine, so that's good.
>> >>>>
>> >>>> ‹peter
>> >>>>
>> >>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>> >>>>
>> >>>>> Peter,
>> >>>>>
>> >>>>> I've started to experiment with your new classes in TourJS and I
>> >>>>>think
>> >>>>> I've
>> >>>>> achieved some good look, but not everything is working as
>>expected.
>> >>>>>
>> >>>>> For some reason code of examples has not been loaded properly. If
>>you
>> >>>>> could
>> >>>>> review my changes and give some feedback, whether I used your new
>> >>>>> classes
>> >>>>> in
>> >>>>> appropriate manner.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Piotr
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -----
>> >>>>> Apache Flex PMC
>> >>>>> piotrzarzycki21@gmail.com
>> >>>>> --
>> >>>>> View this message in context:
>> >>>>>
>> >>>>>
>> >>>>>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fapache
>> >>>>>-f
>> >>>>> le
>> >>>>>
>> >>>>>
>> >>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-
>> of-Changes-tp6070
>> >>>>>9p
>> >>>>> 60
>> >>>>>
>> >>>>>
>> >>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e
>> 47ea%7Cfa7b1b5a
>> >>>>>7b
>> >>>>> 34
>> >>>>>
>> >>>>>
>> >>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&
>> sdata=29GdLLPJdgglZF
>> >>>>>zZ
>> >>>>> UF
>> >>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>> >>>>> Sent from the Apache Flex Development mailing list archive at
>> >>>>> Nabble.com.
>> >>>>
>> >>>
>> >>
>> >
>>
>>
Re: [FlexJS] Summary of Changes
Posted by Greg Dove <gr...@gmail.com>.
I've just done a sweep through one project fixing our 'borked' stuff, I
guess the latest change might re-'bork' some of the fixes, but I think at
least these changes should be easier to address.
Sometimes I needed to swap a Container to a Group and other times not,
because of the relative/absolute changes.
I found it easier to migrate a lot of the layout stuff to pure css for now
using flexbox, thinking that doing so might insulate us from further
changes in the coded layout support. We would have the ability to swap back
to beads etc later if we want to have that in the mxml, once things have
become stable.
On Tue, Mar 28, 2017 at 9:52 AM, Peter Ent <pe...@adobe.com> wrote:
> Does the HTML look OK - the structure. Is there anything missing? You
> should see a simplified nesting of DIVs. If that's the case, then maybe
> there is more work to do with the layouts.
>
> The topmost Container, outer controls, doesn't look like it has a layout,
> so with Container that should default to BasicLayout. That's one thing to
> check.
>
> Does the Container with id scrollContainer have a parent somewhere with a
> fixed width and height? The auto margins should still work for HTML.
> Mostly the work is on the SWF side; the JS code was "cleaned up" so maybe
> that's the problem. I took out much of the algorithmic code for Vertical
> and Horizontal layout since I believe HTML would respond property to the
> addition of children, removal of children, resizing, etc. I did have, if I
> remember correctly, to add "white-space:nowrap" to the HorizontalLayout; I
> don't know that will affect you.
>
> Would you mind tinker with the HTML DOM in the browser to see if you can
> get the look you want? That will help determine if the layout code needs
> to be adjusted.
>
> Thanks and so sorry for the problems. *must use feature branch next time*
> —peter
>
> On 3/27/17, 4:35 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >Better, but I still have some problems (there’s probably more):
> >
> > <js:Container width="100%" id="outerControls">
> > <js:style>
> > <js:SimpleCSSStyles
> backgroundColor="0x444444"/>
> > </js:style>
> > <js:Container id="controls">
> > <js:style>
> > <js:SimpleCSSStyles
> marginLeft="auto" marginRight="auto"/>
> > </js:style>
> > <js:beads>
> > <js:HorizontalLayout/>
> > </js:beads>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="undo_clickHandler(event)" id="undoButton"
> >src="assets/images/icons/0726-undo.svg">
> > <js:beads>
> > <js:DisableBead/>
> > </js:beads>
> > </js:ImageButton>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="redo_clickHandler(event)" id="redoButton"
> >src="assets/images/icons/0727-redo.svg">
> > <js:beads>
> > <js:DisableBead/>
> > </js:beads>
> > </js:ImageButton>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="zoomin_clickHandler(event)"
> >src="assets/images/icons/0806-zoom-in.svg"/>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="zoomout_clickHandler(event)"
> >src="assets/images/icons/0807-zoom-out.svg"/>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="fitButton_clickHandler(event)"
> >src="assets/images/icons/0843-expand.svg"/>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="previewButton_clickHandler(event)"
> >src="assets/images/icons/0786-file-preview-white.svg"/>
> > <js:Spacer width="10"/>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="finishButton_clickHandler()"
> >src="assets/images/icons/0821-check.svg"/>
> > <js:Spacer width="10"/>
> > <js:ImageButton className="iconButton
> white" width="30" height="30"
> >click="cancelButton_clickHandler()"
> >src="assets/images/icons/0822-cross2.svg"/>
> > </js:Container>
> >
> >1. This used to create a centered group of buttons. Now, the container
> >has a height of 0 and the buttons don’t show up.
> >
> >2.
> > <js:Container className="designOuterContainer"
> id="scrollContainer"
> >width="100%" height="100%">
> > <js:beads>
> > <js:ScrollingViewport/>
> > </js:beads>
> > <components:DesignAreaHolder
> id="designContainer"
> >className="_holder" y="0">
> > <components:style>
> >
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> > </components:style>
> > </components:DesignAreaHolder>
> >
> > </js:Container>
> >
> >This used to create a scrolling div that was centered in the the window.
> >It now is aligned left, and I don’t know if it scrolls.
> >
> >There’s other issues, and I’ll see tomorrow what I can work around.
> >
> >> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
> >>
> >> Hi,
> >>
> >> I just pushed a change to UIBase to set position="absolute" when
> >>setting x
> >> or y. I think this is perfectly safe and if someone does set x and y and
> >> then tries to use a layout where that would be a conflict, they will get
> >> have to avoid setting those properties.
> >>
> >> I figured this would eventually happen. Let's see if this fixes the
> >>issue.
> >>
> >> —peter
> >>
> >>
> >> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >>> Peter,
> >>>
> >>> I just tried loading my app with your changes, and everything is
> >>>totally
> >>> borked. We rely a lot on absolute positioning and transformations.
> >>>
> >>> We really need the old behavior in some components.
> >>>
> >>> Is there any components which work the same as they used to?
> >>>
> >>> Harbs
> >>>
> >>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
> >>>>
> >>>> For the time being, the Tour main view should have a width and a
> >>>>height:
> >>>>
> >>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
> >>>>
> >>>> Then in the style section, give everything flex-grow: 1; and it should
> >>>> look better. I think some padding and/or margins might be needed, but
> >>>>I
> >>>> think I have more work do with the layouts. I'll bump getting the tour
> >>>> to
> >>>> the top of the list for this week because I think its nesting of
> >>>> elements
> >>>> is a good test. I think it is just a matter of setting the style
> >>>>values
> >>>> right. HTML structure-wise it looks fine, so that's good.
> >>>>
> >>>> ‹peter
> >>>>
> >>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
> >>>>
> >>>>> Peter,
> >>>>>
> >>>>> I've started to experiment with your new classes in TourJS and I
> >>>>>think
> >>>>> I've
> >>>>> achieved some good look, but not everything is working as expected.
> >>>>>
> >>>>> For some reason code of examples has not been loaded properly. If you
> >>>>> could
> >>>>> review my changes and give some feedback, whether I used your new
> >>>>> classes
> >>>>> in
> >>>>> appropriate manner.
> >>>>>
> >>>>> Thanks,
> >>>>> Piotr
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----
> >>>>> Apache Flex PMC
> >>>>> piotrzarzycki21@gmail.com
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> >>>>>
> >>>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fapache
> >>>>>-f
> >>>>> le
> >>>>>
> >>>>>
> >>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-
> of-Changes-tp6070
> >>>>>9p
> >>>>> 60
> >>>>>
> >>>>>
> >>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e
> 47ea%7Cfa7b1b5a
> >>>>>7b
> >>>>> 34
> >>>>>
> >>>>>
> >>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&
> sdata=29GdLLPJdgglZF
> >>>>>zZ
> >>>>> UF
> >>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
> >>>>> Sent from the Apache Flex Development mailing list archive at
> >>>>> Nabble.com.
> >>>>
> >>>
> >>
> >
>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Does the HTML look OK - the structure. Is there anything missing? You
should see a simplified nesting of DIVs. If that's the case, then maybe
there is more work to do with the layouts.
The topmost Container, outer controls, doesn't look like it has a layout,
so with Container that should default to BasicLayout. That's one thing to
check.
Does the Container with id scrollContainer have a parent somewhere with a
fixed width and height? The auto margins should still work for HTML.
Mostly the work is on the SWF side; the JS code was "cleaned up" so maybe
that's the problem. I took out much of the algorithmic code for Vertical
and Horizontal layout since I believe HTML would respond property to the
addition of children, removal of children, resizing, etc. I did have, if I
remember correctly, to add "white-space:nowrap" to the HorizontalLayout; I
don't know that will affect you.
Would you mind tinker with the HTML DOM in the browser to see if you can
get the look you want? That will help determine if the layout code needs
to be adjusted.
Thanks and so sorry for the problems. *must use feature branch next time*
—peter
On 3/27/17, 4:35 PM, "Harbs" <ha...@gmail.com> wrote:
>Better, but I still have some problems (there’s probably more):
>
> <js:Container width="100%" id="outerControls">
> <js:style>
> <js:SimpleCSSStyles backgroundColor="0x444444"/>
> </js:style>
> <js:Container id="controls">
> <js:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </js:style>
> <js:beads>
> <js:HorizontalLayout/>
> </js:beads>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="undo_clickHandler(event)" id="undoButton"
>src="assets/images/icons/0726-undo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="redo_clickHandler(event)" id="redoButton"
>src="assets/images/icons/0727-redo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="zoomin_clickHandler(event)"
>src="assets/images/icons/0806-zoom-in.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="zoomout_clickHandler(event)"
>src="assets/images/icons/0807-zoom-out.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="fitButton_clickHandler(event)"
>src="assets/images/icons/0843-expand.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="previewButton_clickHandler(event)"
>src="assets/images/icons/0786-file-preview-white.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="finishButton_clickHandler()"
>src="assets/images/icons/0821-check.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="cancelButton_clickHandler()"
>src="assets/images/icons/0822-cross2.svg"/>
> </js:Container>
>
>1. This used to create a centered group of buttons. Now, the container
>has a height of 0 and the buttons don’t show up.
>
>2.
> <js:Container className="designOuterContainer" id="scrollContainer"
>width="100%" height="100%">
> <js:beads>
> <js:ScrollingViewport/>
> </js:beads>
> <components:DesignAreaHolder id="designContainer"
>className="_holder" y="0">
> <components:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </components:style>
> </components:DesignAreaHolder>
>
> </js:Container>
>
>This used to create a scrolling div that was centered in the the window.
>It now is aligned left, and I don’t know if it scrolls.
>
>There’s other issues, and I’ll see tomorrow what I can work around.
>
>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> Hi,
>>
>> I just pushed a change to UIBase to set position="absolute" when
>>setting x
>> or y. I think this is perfectly safe and if someone does set x and y and
>> then tries to use a layout where that would be a conflict, they will get
>> have to avoid setting those properties.
>>
>> I figured this would eventually happen. Let's see if this fixes the
>>issue.
>>
>> —peter
>>
>>
>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Peter,
>>>
>>> I just tried loading my app with your changes, and everything is
>>>totally
>>> borked. We rely a lot on absolute positioning and transformations.
>>>
>>> We really need the old behavior in some components.
>>>
>>> Is there any components which work the same as they used to?
>>>
>>> Harbs
>>>
>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> For the time being, the Tour main view should have a width and a
>>>>height:
>>>>
>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>
>>>> Then in the style section, give everything flex-grow: 1; and it should
>>>> look better. I think some padding and/or margins might be needed, but
>>>>I
>>>> think I have more work do with the layouts. I'll bump getting the tour
>>>> to
>>>> the top of the list for this week because I think its nesting of
>>>> elements
>>>> is a good test. I think it is just a matter of setting the style
>>>>values
>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>
>>>> ‹peter
>>>>
>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> I've started to experiment with your new classes in TourJS and I
>>>>>think
>>>>> I've
>>>>> achieved some good look, but not everything is working as expected.
>>>>>
>>>>> For some reason code of examples has not been loaded properly. If you
>>>>> could
>>>>> review my changes and give some feedback, whether I used your new
>>>>> classes
>>>>> in
>>>>> appropriate manner.
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> Apache Flex PMC
>>>>> piotrzarzycki21@gmail.com
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>>-f
>>>>> le
>>>>>
>>>>>
>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp6070
>>>>>9p
>>>>> 60
>>>>>
>>>>>
>>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a
>>>>>7b
>>>>> 34
>>>>>
>>>>>
>>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZF
>>>>>zZ
>>>>> UF
>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com.
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
Yes. I think the problem is that the size is not being set.
> On Mar 27, 2017, at 11:58 PM, Alex Harui <ah...@adobe.com> wrote:
>
> For #2, again, what does the DOM look like? Did the margins get set
> properly?
Re: [FlexJS] Summary of Changes
Posted by Alex Harui <ah...@adobe.com>.
Harbs,
For #1, that sounds like a problem with deferred loading of images. What
is in the DOM? Are heights still being set on the containers? Also,
Peter, should Harbs switch from Container to Group?
For #2, again, what does the DOM look like? Did the margins get set
properly?
Thanks,
-Alex
On 3/27/17, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
>Better, but I still have some problems (there’s probably more):
>
> <js:Container width="100%" id="outerControls">
> <js:style>
> <js:SimpleCSSStyles backgroundColor="0x444444"/>
> </js:style>
> <js:Container id="controls">
> <js:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </js:style>
> <js:beads>
> <js:HorizontalLayout/>
> </js:beads>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="undo_clickHandler(event)" id="undoButton"
>src="assets/images/icons/0726-undo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="redo_clickHandler(event)" id="redoButton"
>src="assets/images/icons/0727-redo.svg">
> <js:beads>
> <js:DisableBead/>
> </js:beads>
> </js:ImageButton>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="zoomin_clickHandler(event)"
>src="assets/images/icons/0806-zoom-in.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="zoomout_clickHandler(event)"
>src="assets/images/icons/0807-zoom-out.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="fitButton_clickHandler(event)"
>src="assets/images/icons/0843-expand.svg"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="previewButton_clickHandler(event)"
>src="assets/images/icons/0786-file-preview-white.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="finishButton_clickHandler()"
>src="assets/images/icons/0821-check.svg"/>
> <js:Spacer width="10"/>
> <js:ImageButton className="iconButton white" width="30" height="30"
>click="cancelButton_clickHandler()"
>src="assets/images/icons/0822-cross2.svg"/>
> </js:Container>
>
>1. This used to create a centered group of buttons. Now, the container
>has a height of 0 and the buttons don’t show up.
>
>2.
> <js:Container className="designOuterContainer" id="scrollContainer"
>width="100%" height="100%">
> <js:beads>
> <js:ScrollingViewport/>
> </js:beads>
> <components:DesignAreaHolder id="designContainer"
>className="_holder" y="0">
> <components:style>
> <js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
> </components:style>
> </components:DesignAreaHolder>
>
> </js:Container>
>
>This used to create a scrolling div that was centered in the the window.
>It now is aligned left, and I don’t know if it scrolls.
>
>There’s other issues, and I’ll see tomorrow what I can work around.
>
>> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> Hi,
>>
>> I just pushed a change to UIBase to set position="absolute" when
>>setting x
>> or y. I think this is perfectly safe and if someone does set x and y and
>> then tries to use a layout where that would be a conflict, they will get
>> have to avoid setting those properties.
>>
>> I figured this would eventually happen. Let's see if this fixes the
>>issue.
>>
>> —peter
>>
>>
>> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Peter,
>>>
>>> I just tried loading my app with your changes, and everything is
>>>totally
>>> borked. We rely a lot on absolute positioning and transformations.
>>>
>>> We really need the old behavior in some components.
>>>
>>> Is there any components which work the same as they used to?
>>>
>>> Harbs
>>>
>>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> For the time being, the Tour main view should have a width and a
>>>>height:
>>>>
>>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>>
>>>> Then in the style section, give everything flex-grow: 1; and it should
>>>> look better. I think some padding and/or margins might be needed, but
>>>>I
>>>> think I have more work do with the layouts. I'll bump getting the tour
>>>> to
>>>> the top of the list for this week because I think its nesting of
>>>> elements
>>>> is a good test. I think it is just a matter of setting the style
>>>>values
>>>> right. HTML structure-wise it looks fine, so that's good.
>>>>
>>>> ‹peter
>>>>
>>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> I've started to experiment with your new classes in TourJS and I
>>>>>think
>>>>> I've
>>>>> achieved some good look, but not everything is working as expected.
>>>>>
>>>>> For some reason code of examples has not been loaded properly. If you
>>>>> could
>>>>> review my changes and give some feedback, whether I used your new
>>>>> classes
>>>>> in
>>>>> appropriate manner.
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> Apache Flex PMC
>>>>> piotrzarzycki21@gmail.com
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache
>>>>>-f
>>>>> le
>>>>>
>>>>>
>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp6070
>>>>>9p
>>>>> 60
>>>>>
>>>>>
>>>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a
>>>>>7b
>>>>> 34
>>>>>
>>>>>
>>>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZF
>>>>>zZ
>>>>> UF
>>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com.
>>>>
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
Better, but I still have some problems (there’s probably more):
<js:Container width="100%" id="outerControls">
<js:style>
<js:SimpleCSSStyles backgroundColor="0x444444"/>
</js:style>
<js:Container id="controls">
<js:style>
<js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
</js:style>
<js:beads>
<js:HorizontalLayout/>
</js:beads>
<js:ImageButton className="iconButton white" width="30" height="30" click="undo_clickHandler(event)" id="undoButton" src="assets/images/icons/0726-undo.svg">
<js:beads>
<js:DisableBead/>
</js:beads>
</js:ImageButton>
<js:ImageButton className="iconButton white" width="30" height="30" click="redo_clickHandler(event)" id="redoButton" src="assets/images/icons/0727-redo.svg">
<js:beads>
<js:DisableBead/>
</js:beads>
</js:ImageButton>
<js:ImageButton className="iconButton white" width="30" height="30" click="zoomin_clickHandler(event)" src="assets/images/icons/0806-zoom-in.svg"/>
<js:ImageButton className="iconButton white" width="30" height="30" click="zoomout_clickHandler(event)" src="assets/images/icons/0807-zoom-out.svg"/>
<js:ImageButton className="iconButton white" width="30" height="30" click="fitButton_clickHandler(event)" src="assets/images/icons/0843-expand.svg"/>
<js:ImageButton className="iconButton white" width="30" height="30" click="previewButton_clickHandler(event)" src="assets/images/icons/0786-file-preview-white.svg"/>
<js:Spacer width="10"/>
<js:ImageButton className="iconButton white" width="30" height="30" click="finishButton_clickHandler()" src="assets/images/icons/0821-check.svg"/>
<js:Spacer width="10"/>
<js:ImageButton className="iconButton white" width="30" height="30" click="cancelButton_clickHandler()" src="assets/images/icons/0822-cross2.svg"/>
</js:Container>
1. This used to create a centered group of buttons. Now, the container has a height of 0 and the buttons don’t show up.
2.
<js:Container className="designOuterContainer" id="scrollContainer" width="100%" height="100%">
<js:beads>
<js:ScrollingViewport/>
</js:beads>
<components:DesignAreaHolder id="designContainer" className="_holder" y="0">
<components:style>
<js:SimpleCSSStyles marginLeft="auto" marginRight="auto"/>
</components:style>
</components:DesignAreaHolder>
</js:Container>
This used to create a scrolling div that was centered in the the window. It now is aligned left, and I don’t know if it scrolls.
There’s other issues, and I’ll see tomorrow what I can work around.
> On Mar 27, 2017, at 11:08 PM, Peter Ent <pe...@adobe.com> wrote:
>
> Hi,
>
> I just pushed a change to UIBase to set position="absolute" when setting x
> or y. I think this is perfectly safe and if someone does set x and y and
> then tries to use a layout where that would be a conflict, they will get
> have to avoid setting those properties.
>
> I figured this would eventually happen. Let's see if this fixes the issue.
>
> —peter
>
>
> On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> Peter,
>>
>> I just tried loading my app with your changes, and everything is totally
>> borked. We rely a lot on absolute positioning and transformations.
>>
>> We really need the old behavior in some components.
>>
>> Is there any components which work the same as they used to?
>>
>> Harbs
>>
>>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> For the time being, the Tour main view should have a width and a height:
>>>
>>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>>
>>> Then in the style section, give everything flex-grow: 1; and it should
>>> look better. I think some padding and/or margins might be needed, but I
>>> think I have more work do with the layouts. I'll bump getting the tour
>>> to
>>> the top of the list for this week because I think its nesting of
>>> elements
>>> is a good test. I think it is just a matter of setting the style values
>>> right. HTML structure-wise it looks fine, so that's good.
>>>
>>> ‹peter
>>>
>>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>>
>>>> Peter,
>>>>
>>>> I've started to experiment with your new classes in TourJS and I think
>>>> I've
>>>> achieved some good look, but not everything is working as expected.
>>>>
>>>> For some reason code of examples has not been loaded properly. If you
>>>> could
>>>> review my changes and give some feedback, whether I used your new
>>>> classes
>>>> in
>>>> appropriate manner.
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>>
>>>>
>>>> -----
>>>> Apache Flex PMC
>>>> piotrzarzycki21@gmail.com
>>>> --
>>>> View this message in context:
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>> le
>>>>
>>>> x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p
>>>> 60
>>>>
>>>> 779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b
>>>> 34
>>>>
>>>> 438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZ
>>>> UF
>>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>>> Sent from the Apache Flex Development mailing list archive at
>>>> Nabble.com.
>>>
>>
>
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I just pushed a change to UIBase to set position="absolute" when setting x
or y. I think this is perfectly safe and if someone does set x and y and
then tries to use a layout where that would be a conflict, they will get
have to avoid setting those properties.
I figured this would eventually happen. Let's see if this fixes the issue.
—peter
On 3/27/17, 2:58 PM, "Harbs" <ha...@gmail.com> wrote:
>Peter,
>
>I just tried loading my app with your changes, and everything is totally
>borked. We rely a lot on absolute positioning and transformations.
>
>We really need the old behavior in some components.
>
>Is there any components which work the same as they used to?
>
>Harbs
>
>> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>>
>> For the time being, the Tour main view should have a width and a height:
>>
>> <local:TourJSMainView id="mainView" width="100%" height="900" />
>>
>> Then in the style section, give everything flex-grow: 1; and it should
>> look better. I think some padding and/or margins might be needed, but I
>> think I have more work do with the layouts. I'll bump getting the tour
>>to
>> the top of the list for this week because I think its nesting of
>>elements
>> is a good test. I think it is just a matter of setting the style values
>> right. HTML structure-wise it looks fine, so that's good.
>>
>> ‹peter
>>
>> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>>
>>> Peter,
>>>
>>> I've started to experiment with your new classes in TourJS and I think
>>> I've
>>> achieved some good look, but not everything is working as expected.
>>>
>>> For some reason code of examples has not been loaded properly. If you
>>> could
>>> review my changes and give some feedback, whether I used your new
>>>classes
>>> in
>>> appropriate manner.
>>>
>>> Thanks,
>>> Piotr
>>>
>>>
>>>
>>> -----
>>> Apache Flex PMC
>>> piotrzarzycki21@gmail.com
>>> --
>>> View this message in context:
>>>
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>le
>>>
>>>x-development.2333347.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p
>>>60
>>>
>>>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b
>>>34
>>>
>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZ
>>>UF
>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>
>
Re: [FlexJS] Summary of Changes
Posted by Harbs <ha...@gmail.com>.
Peter,
I just tried loading my app with your changes, and everything is totally borked. We rely a lot on absolute positioning and transformations.
We really need the old behavior in some components.
Is there any components which work the same as they used to?
Harbs
> On Mar 26, 2017, at 6:55 PM, Peter Ent <pe...@adobe.com> wrote:
>
> For the time being, the Tour main view should have a width and a height:
>
> <local:TourJSMainView id="mainView" width="100%" height="900" />
>
> Then in the style section, give everything flex-grow: 1; and it should
> look better. I think some padding and/or margins might be needed, but I
> think I have more work do with the layouts. I'll bump getting the tour to
> the top of the list for this week because I think its nesting of elements
> is a good test. I think it is just a matter of setting the style values
> right. HTML structure-wise it looks fine, so that's good.
>
> ‹peter
>
> On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>
>> Peter,
>>
>> I've started to experiment with your new classes in TourJS and I think
>> I've
>> achieved some good look, but not everything is working as expected.
>>
>> For some reason code of examples has not been loaded properly. If you
>> could
>> review my changes and give some feedback, whether I used your new classes
>> in
>> appropriate manner.
>>
>> 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-Summary-of-Changes-tp60709p60
>> 779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b34
>> 438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZUF
>> AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Thanks Peter for the tips. Digging into TourJS I learned couple of things. :)
Just committed my final changes for today with still unresolved issues:
- For some reason ButtonBar change event not working
- Layout for displaying example application is still broken (I mean here
Panel with SubAppLoader)
Looking forward to your fix for above things.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60784.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
For the time being, the Tour main view should have a width and a height:
<local:TourJSMainView id="mainView" width="100%" height="900" />
Then in the style section, give everything flex-grow: 1; and it should
look better. I think some padding and/or margins might be needed, but I
think I have more work do with the layouts. I'll bump getting the tour to
the top of the list for this week because I think its nesting of elements
is a good test. I think it is just a matter of setting the style values
right. HTML structure-wise it looks fine, so that's good.
‹peter
On 3/26/17, 11:31 AM, "piotrz" <pi...@gmail.com> wrote:
>Peter,
>
>I've started to experiment with your new classes in TourJS and I think
>I've
>achieved some good look, but not everything is working as expected.
>
>For some reason code of examples has not been loaded properly. If you
>could
>review my changes and give some feedback, whether I used your new classes
>in
>appropriate manner.
>
>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-Summary-of-Changes-tp60709p60
>779.html&data=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636261395657671115&sdata=29GdLLPJdgglZFzZUF
>AOBNCBt0S8qshiPOmXCDEbRKw%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Peter,
I've started to experiment with your new classes in TourJS and I think I've
achieved some good look, but not everything is working as expected.
For some reason code of examples has not been loaded properly. If you could
review my changes and give some feedback, whether I used your new classes in
appropriate manner.
Thanks,
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60779.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Updates to examples.
I just pushed changes to two of the examples: DataBindingExample and
DataGridExample. Use these examples to provide some guidance when making
your own changes:
- Change Container to Group if you can, although on the JS side, Container
and Group are the same.
- Employ the VerticalFlexLayout and HorizontalFlexLayout classes if you
want certain items to be stretchy. See below for more details.
- The VerticalLayout and HorizontalLayout classes work as you expect, then
just use display:block and display:inline-block on the JS side.
- To position things absolutely, use BasicLayout for your container's
layout. This is the default layout for the js:View class; the Group class
does not have a default layout at the moment so you must specify one when
you use Group.
There are some things I didn't retrofit yet, especially in the DataGrid
collection of classes. I left those in comments in the DataGridExample as
a reminder.
If you aren't familiar with the CSS Flexbox, [1] is a terrific
introduction. I've implemented only some of its features in the SWF-side
layouts. The goal of the layouts is to provide only what's needed on the
JS side and mimic that on the SWF side. So you will not see the JS side
layout's listening for some events since the browser will automatically
detect the changes and do the right thing.
VerticalFlexLayout (display:flex; flex-flow: column) aligns everything
vertically and expands items horizontally to fit the space (unless you
have specified a width somehow). The height of each item will default to
its native height (or a height you specify somehow). To make an item
stretchy, given that item a style of flex-grow:1 and to make an item not
be stretchy, use flex-grow:0. I have changed SimpleCSSStyles to include
properties flexGrow and flexShrink (my implementation of the Flexbox
layouts do not use shrink yet).
HorizontalFlexLayout (display:flex, flex-flow: row) does the same thing
but horizontally.
The OneFlexibleChild* and FlexibleFirstChild* layouts now employ Flexbox
on the JS side.
[1] https://css-tricks.com/snippets/css/a-guide-to-flexbox/
Regards,
Peter
On 3/24/17, 8:33 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Amendment to these changes:
>
>Charts: This package should compile now, but will probably not work
>completely. Next on my list.
>
>MDL: This package compiles and runs the main example for me. For those of
>you who use MDL, I changed the classes that extended ContainerBase to
>extend Group instead. Since I am not that familiar with the requirements
>of MDL, you may want to extend GroupBase instead, but take a look at the
>two classes to determine your needs. Group/GroupBase just produce a <div>
>whereas ContainerBase was creating a <div><div>Š</div></div> situation.
>Perhaps you took steps to circumvent that, and if so, those steps should
>no longer be needed.
>
>In going through all these projects, its pretty clear to me we have an
>number of unused interfaces, some confusing interfaces, and probably a
>bunch of classes that are no longer being used. A "spring cleaning" should
>be in order to tidy up FlexJS. I also recommend some refactoring
>throughout FlexJS.
>
>I hope I have done the right thing here and haven't introduced too much
>chaos. I believe the container/layout life cycle is now on track and if
>you are seeing any problems with it, look at
>org.apache.flex.html.beads.GroupView as this is the class that controls
>that life cycle (I removed redundant code where I found it).
>
>Cheers,
>Peter
>
>On 3/23/17, 1:27 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>FlexJS Container and Layout Upgrade
>>
>>My goal when starting this process was to have FlexJS produce leaner HTML
>>structures and to reduce the amount of JavaScript code getting
>>cross-compiled. My latest commit does the following:
>>
>>- Produces simpler HTML structures for the container classes, Group,
>>Container, and Panel.
>>- Simplifies a number of the layout classes for JS while fixing or tuning
>>the SWF code to mimic the browser.
>>- Moves code that only affects the SWF side into SWF code blocks.
>>
>>I touched only Core and HTML projects and fixed Effects so it would
>>compile since it had the fewest issues. MDL and Charts have larger
>>concerns and I hope to sort those out as quickly as I can.
>>
>>Here are the classes and changes you will find:
>>
>>Group: This new class (introduced in a previous commit) produces the
>>simplest container for HTML (it is just a DIV) and SWF. By default it
>>provides no layout in case you want to style in completely using CSS.
>>Group (and its view bead, GroupView), are the foundation of the container
>>classes. Group runs a layout bead (if there is one) and handles the
>>sizing of elements on the SWF side. The JS side is left alone for the
>>browser to manage (this was the biggest change).
>>
>>Container: This class, which extends Group, exists to provide scrolling
>>on the SWF side. The JS side of Container is very light adds little to
>>what Group does. On the SWF side, Container is a nested structure in
>>order to providing content masking and scrolling (which is handled on the
>>JS side by using overflow:auto style, which is all the ScrollingViewport
>>bead will do if you add it to Container).
>>
>>UIBase: The major change to UIBase is that it no longer sets the position
>>style. That means if you set the x and y properties of a component, it
>>will, on the JS side, only set the left and top style values. If you
>>intend to place elements at specific pixel coordinates, use a container
>>(Group or Container) with BasicLayout which will add position:absolute
>>style to all of the children.
>>
>>NOTE: I made UIBase (and a couple other classes, too) not set position
>>style because I saw how easily that caused other problems, especially
>>when there was a mixing of "absolute" and "relative" position values. Now
>>that this work is done, it may not be a bad thing to have UIBase's x and
>>y properties set position:absolute has a convenience. It does however,
>>have some ramifications; if you have position:absolute that will override
>>pretty much all of the layout types. But maybe the developer just sees
>>this and stops setting x and y. Also, there is no way to unset position
>>once set. These are things we will have to see how they play out.
>>
>>Layouts: The layouts no longer change the size of their container hosts
>>nor do they produce the "layoutComplete" event. The GroupView class
>>handles both of these now to make the process of layout and
>>sizing/positioning consistent.
>>
>>Lists: The DataGroup that lists use to hold the item renderers is no
>>longer in play. The DataGroup caused unnecessary nesting of elements (DIV
>>inside of DIV). To break that, components like List had to become their
>>own item renderer parents. Squaring this away is perhaps the biggest
>>challenge since a number of complex components use List as their base.
>>The DataContainer is now the basis for lists, with List being its first
>>subclass since they have so much in common. The DataContainerView bead is
>>now the basis for all list views.
>>
>>Panel: The Panel is now an extension of Group and it contains three
>>children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>>Container for the content space. When you do: panel.addElement(object),
>>the Panel code redirects this to its Container child. Similarly,
>>panel.numElements tells you the number of elements in the Container
>>child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>>uses a layout to size and position those three children. When you build
>>your own components, you can use Group + layout to achieve the look you
>>want with minimal HTML structure.
>>
>>Interfaces: There are couple of key changes to interfaces. First, there
>>is a new interface in the Core project: ILayoutView. This interface is
>>implemented by any component whose children can be manipulated by a
>>layout. The ILayoutHost interface's function, contentView, has been
>>changed to return an instance of ILayoutView. The functions listed in
>>ILayoutView may be expanded if we run into situations or layouts that
>>need more information from their layout parents; this change is probably
>>the source of most compilation issues you will see.
>>
>>Using Layouts inside of Components: As stated above, Panel (and
>>PanelWithControlBar), now uses a layout for its own purposes. This is the
>>VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
>>CSS creation makes the code much simpler and cleaner. Basically, the JS
>>layout code is a few lines with maybe a loop to set each child's display
>>correctly. The SWF side then has the task to mimic the layout. I have not
>>completed the transition on all of the layouts, but the common ones have
>>tested correctly.
>>
>>Regards,
>>Peter Ent
>>Adobe Systems/Apache Flex Project
>>
>
Re: [FlexJS] Summary of Changes
Posted by piotrz <pi...@gmail.com>.
Thanks Peter!
I will try MDLExamples over the weekend and see whether everything is
working as it was. :)
For sure some interfaces cleanup would be awesome.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Summary-of-Changes-tp60709p60742.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Summary of Changes
Posted by Peter Ent <pe...@adobe.com>.
Amendment to these changes:
Charts: This package should compile now, but will probably not work
completely. Next on my list.
MDL: This package compiles and runs the main example for me. For those of
you who use MDL, I changed the classes that extended ContainerBase to
extend Group instead. Since I am not that familiar with the requirements
of MDL, you may want to extend GroupBase instead, but take a look at the
two classes to determine your needs. Group/GroupBase just produce a <div>
whereas ContainerBase was creating a <div><div>Š</div></div> situation.
Perhaps you took steps to circumvent that, and if so, those steps should
no longer be needed.
In going through all these projects, its pretty clear to me we have an
number of unused interfaces, some confusing interfaces, and probably a
bunch of classes that are no longer being used. A "spring cleaning" should
be in order to tidy up FlexJS. I also recommend some refactoring
throughout FlexJS.
I hope I have done the right thing here and haven't introduced too much
chaos. I believe the container/layout life cycle is now on track and if
you are seeing any problems with it, look at
org.apache.flex.html.beads.GroupView as this is the class that controls
that life cycle (I removed redundant code where I found it).
Cheers,
Peter
On 3/23/17, 1:27 PM, "Peter Ent" <pe...@adobe.com> wrote:
>FlexJS Container and Layout Upgrade
>
>My goal when starting this process was to have FlexJS produce leaner HTML
>structures and to reduce the amount of JavaScript code getting
>cross-compiled. My latest commit does the following:
>
>- Produces simpler HTML structures for the container classes, Group,
>Container, and Panel.
>- Simplifies a number of the layout classes for JS while fixing or tuning
>the SWF code to mimic the browser.
>- Moves code that only affects the SWF side into SWF code blocks.
>
>I touched only Core and HTML projects and fixed Effects so it would
>compile since it had the fewest issues. MDL and Charts have larger
>concerns and I hope to sort those out as quickly as I can.
>
>Here are the classes and changes you will find:
>
>Group: This new class (introduced in a previous commit) produces the
>simplest container for HTML (it is just a DIV) and SWF. By default it
>provides no layout in case you want to style in completely using CSS.
>Group (and its view bead, GroupView), are the foundation of the container
>classes. Group runs a layout bead (if there is one) and handles the
>sizing of elements on the SWF side. The JS side is left alone for the
>browser to manage (this was the biggest change).
>
>Container: This class, which extends Group, exists to provide scrolling
>on the SWF side. The JS side of Container is very light adds little to
>what Group does. On the SWF side, Container is a nested structure in
>order to providing content masking and scrolling (which is handled on the
>JS side by using overflow:auto style, which is all the ScrollingViewport
>bead will do if you add it to Container).
>
>UIBase: The major change to UIBase is that it no longer sets the position
>style. That means if you set the x and y properties of a component, it
>will, on the JS side, only set the left and top style values. If you
>intend to place elements at specific pixel coordinates, use a container
>(Group or Container) with BasicLayout which will add position:absolute
>style to all of the children.
>
>NOTE: I made UIBase (and a couple other classes, too) not set position
>style because I saw how easily that caused other problems, especially
>when there was a mixing of "absolute" and "relative" position values. Now
>that this work is done, it may not be a bad thing to have UIBase's x and
>y properties set position:absolute has a convenience. It does however,
>have some ramifications; if you have position:absolute that will override
>pretty much all of the layout types. But maybe the developer just sees
>this and stops setting x and y. Also, there is no way to unset position
>once set. These are things we will have to see how they play out.
>
>Layouts: The layouts no longer change the size of their container hosts
>nor do they produce the "layoutComplete" event. The GroupView class
>handles both of these now to make the process of layout and
>sizing/positioning consistent.
>
>Lists: The DataGroup that lists use to hold the item renderers is no
>longer in play. The DataGroup caused unnecessary nesting of elements (DIV
>inside of DIV). To break that, components like List had to become their
>own item renderer parents. Squaring this away is perhaps the biggest
>challenge since a number of complex components use List as their base.
>The DataContainer is now the basis for lists, with List being its first
>subclass since they have so much in common. The DataContainerView bead is
>now the basis for all list views.
>
>Panel: The Panel is now an extension of Group and it contains three
>children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>Container for the content space. When you do: panel.addElement(object),
>the Panel code redirects this to its Container child. Similarly,
>panel.numElements tells you the number of elements in the Container
>child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>uses a layout to size and position those three children. When you build
>your own components, you can use Group + layout to achieve the look you
>want with minimal HTML structure.
>
>Interfaces: There are couple of key changes to interfaces. First, there
>is a new interface in the Core project: ILayoutView. This interface is
>implemented by any component whose children can be manipulated by a
>layout. The ILayoutHost interface's function, contentView, has been
>changed to return an instance of ILayoutView. The functions listed in
>ILayoutView may be expanded if we run into situations or layouts that
>need more information from their layout parents; this change is probably
>the source of most compilation issues you will see.
>
>Using Layouts inside of Components: As stated above, Panel (and
>PanelWithControlBar), now uses a layout for its own purposes. This is the
>VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
>CSS creation makes the code much simpler and cleaner. Basically, the JS
>layout code is a few lines with maybe a loop to set each child's display
>correctly. The SWF side then has the task to mimic the layout. I have not
>completed the transition on all of the layouts, but the common ones have
>tested correctly.
>
>Regards,
>Peter Ent
>Adobe Systems/Apache Flex Project
>
Re: Peter Ent's emails being flagged
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I got some emails again in February routed to spam, then I march it went to
inbox normaly.
Very strange behaviour...
2017-03-24 16:35 GMT+01:00 Alex Harui <ah...@adobe.com>:
> Carlos had a problem with Peter's email in January. I'm not sure what the
> answer is.
>
> -Alex
>
> On 3/24/17, 7:54 AM, "Dave Glasser" <dg...@pobox.com> wrote:
>
> >I use Yahoo email, and it seems that the majority of Peter Ent's (and
> >others from this list) get routed into my spam folder. Marking the
> >flagged messages as "Not Spam" seems to have no effect on subsequent
> >mails.
> >Is anyone else experiencing this with Yahoo email?
> >
> >
> > From: Peter Ent <pe...@adobe.com>
> > To: "dev@flex.apache.org" <de...@flex.apache.org>
> > Sent: Thursday, March 23, 2017 1:44 PM
> > Subject: [FlexJS] Summary of Changes
> >
> >FlexJS Container and Layout Upgrade
> >
> >My goal when starting this process was to have FlexJS produce leaner HTML
> >structures and to reduce the amount of JavaScript code getting
> >cross-compiled. My latest commit does the following:
> >
> >- Produces simpler HTML structures for the container classes, Group,
> >Container, and Panel.
> >- Simplifies a number of the layout classes for JS while fixing or tuning
> >the SWF code to mimic the browser.
> >- Moves code that only affects the SWF side into SWF code blocks.
> >
> >I touched only Core and HTML projects and fixed Effects so it would
> >compile since it had the fewest issues. MDL and Charts have larger
> >concerns and I hope to sort those out as quickly as I can.
> >
> >Here are the classes and changes you will find:
> >
> >Group: This new class (introduced in a previous commit) produces the
> >simplest container for HTML (it is just a DIV) and SWF. By default it
> >provides no layout in case you want to style in completely using CSS.
> >Group (and its view bead, GroupView), are the foundation of the container
> >classes. Group runs a layout bead (if there is one) and handles the
> >sizing of elements on the SWF side. The JS side is left alone for the
> >browser to manage (this was the biggest change).
> >
> >Container: This class, which extends Group, exists to provide scrolling
> >on the SWF side. The JS side of Container is very light adds little to
> >what Group does. On the SWF side, Container is a nested structure in
> >order to providing content masking and scrolling (which is handled on the
> >JS side by using overflow:auto style, which is all the ScrollingViewport
> >bead will do if you add it to Container).
> >
> >UIBase: The major change to UIBase is that it no longer sets the position
> >style. That means if you set the x and y properties of a component, it
> >will, on the JS side, only set the left and top style values. If you
> >intend to place elements at specific pixel coordinates, use a container
> >(Group or Container) with BasicLayout which will add position:absolute
> >style to all of the children.
> >
> >NOTE: I made UIBase (and a couple other classes, too) not set position
> >style because I saw how easily that caused other problems, especially
> >when there was a mixing of "absolute" and "relative" position values. Now
> >that this work is done, it may not be a bad thing to have UIBase's x and
> >y properties set position:absolute has a convenience. It does however,
> >have some ramifications; if you have position:absolute that will override
> >pretty much all of the layout types. But maybe the developer just sees
> >this and stops setting x and y. Also, there is no way to unset position
> >once set. These are things we will have to see how they play out.
> >
> >Layouts: The layouts no longer change the size of their container hosts
> >nor do they produce the "layoutComplete" event. The GroupView class
> >handles both of these now to make the process of layout and
> >sizing/positioning consistent.
> >
> >Lists: The DataGroup that lists use to hold the item renderers is no
> >longer in play. The DataGroup caused unnecessary nesting of elements (DIV
> >inside of DIV). To break that, components like List had to become their
> >own item renderer parents. Squaring this away is perhaps the biggest
> >challenge since a number of complex components use List as their base.
> >The DataContainer is now the basis for lists, with List being its first
> >subclass since they have so much in common. The DataContainerView bead is
> >now the basis for all list views.
> >
> >Panel: The Panel is now an extension of Group and it contains three
> >children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
> >Container for the content space. When you do: panel.addElement(object),
> >the Panel code redirects this to its Container child. Similarly,
> >panel.numElements tells you the number of elements in the Container
> >child. Because Panel is now a Group (so are TitleBar and ControlBar), it
> >uses a layout to size and position those three children. When you build
> >your own components, you can use Group + layout to achieve the look you
> >want with minimal HTML structure.
> >
> >Interfaces: There are couple of key changes to interfaces. First, there
> >is a new interface in the Core project: ILayoutView. This interface is
> >implemented by any component whose children can be manipulated by a
> >layout. The ILayoutHost interface's function, contentView, has been
> >changed to return an instance of ILayoutView. The functions listed in
> >ILayoutView may be expanded if we run into situations or layouts that
> >need more information from their layout parents; this change is probably
> >the source of most compilation issues you will see.
> >
> >Using Layouts inside of Components: As stated above, Panel (and
> >PanelWithControlBar), now uses a layout for its own purposes. This is the
> >VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
> >CSS creation makes the code much simpler and cleaner. Basically, the JS
> >layout code is a few lines with maybe a loop to set each child's display
> >correctly. The SWF side then has the task to mimic the layout. I have not
> >completed the transition on all of the layouts, but the common ones have
> >tested correctly.
> >
> >Regards,
> >Peter Ent
> >Adobe Systems/Apache Flex Project
> >
> >
> >
>
>
--
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: Peter Ent's emails being flagged
Posted by Alex Harui <ah...@adobe.com>.
Carlos had a problem with Peter's email in January. I'm not sure what the
answer is.
-Alex
On 3/24/17, 7:54 AM, "Dave Glasser" <dg...@pobox.com> wrote:
>I use Yahoo email, and it seems that the majority of Peter Ent's (and
>others from this list) get routed into my spam folder. Marking the
>flagged messages as "Not Spam" seems to have no effect on subsequent
>mails.
>Is anyone else experiencing this with Yahoo email?
>
>
> From: Peter Ent <pe...@adobe.com>
> To: "dev@flex.apache.org" <de...@flex.apache.org>
> Sent: Thursday, March 23, 2017 1:44 PM
> Subject: [FlexJS] Summary of Changes
>
>FlexJS Container and Layout Upgrade
>
>My goal when starting this process was to have FlexJS produce leaner HTML
>structures and to reduce the amount of JavaScript code getting
>cross-compiled. My latest commit does the following:
>
>- Produces simpler HTML structures for the container classes, Group,
>Container, and Panel.
>- Simplifies a number of the layout classes for JS while fixing or tuning
>the SWF code to mimic the browser.
>- Moves code that only affects the SWF side into SWF code blocks.
>
>I touched only Core and HTML projects and fixed Effects so it would
>compile since it had the fewest issues. MDL and Charts have larger
>concerns and I hope to sort those out as quickly as I can.
>
>Here are the classes and changes you will find:
>
>Group: This new class (introduced in a previous commit) produces the
>simplest container for HTML (it is just a DIV) and SWF. By default it
>provides no layout in case you want to style in completely using CSS.
>Group (and its view bead, GroupView), are the foundation of the container
>classes. Group runs a layout bead (if there is one) and handles the
>sizing of elements on the SWF side. The JS side is left alone for the
>browser to manage (this was the biggest change).
>
>Container: This class, which extends Group, exists to provide scrolling
>on the SWF side. The JS side of Container is very light adds little to
>what Group does. On the SWF side, Container is a nested structure in
>order to providing content masking and scrolling (which is handled on the
>JS side by using overflow:auto style, which is all the ScrollingViewport
>bead will do if you add it to Container).
>
>UIBase: The major change to UIBase is that it no longer sets the position
>style. That means if you set the x and y properties of a component, it
>will, on the JS side, only set the left and top style values. If you
>intend to place elements at specific pixel coordinates, use a container
>(Group or Container) with BasicLayout which will add position:absolute
>style to all of the children.
>
>NOTE: I made UIBase (and a couple other classes, too) not set position
>style because I saw how easily that caused other problems, especially
>when there was a mixing of "absolute" and "relative" position values. Now
>that this work is done, it may not be a bad thing to have UIBase's x and
>y properties set position:absolute has a convenience. It does however,
>have some ramifications; if you have position:absolute that will override
>pretty much all of the layout types. But maybe the developer just sees
>this and stops setting x and y. Also, there is no way to unset position
>once set. These are things we will have to see how they play out.
>
>Layouts: The layouts no longer change the size of their container hosts
>nor do they produce the "layoutComplete" event. The GroupView class
>handles both of these now to make the process of layout and
>sizing/positioning consistent.
>
>Lists: The DataGroup that lists use to hold the item renderers is no
>longer in play. The DataGroup caused unnecessary nesting of elements (DIV
>inside of DIV). To break that, components like List had to become their
>own item renderer parents. Squaring this away is perhaps the biggest
>challenge since a number of complex components use List as their base.
>The DataContainer is now the basis for lists, with List being its first
>subclass since they have so much in common. The DataContainerView bead is
>now the basis for all list views.
>
>Panel: The Panel is now an extension of Group and it contains three
>children: a TitleBar, a ControlBar (for PanelWithControlBar), and a
>Container for the content space. When you do: panel.addElement(object),
>the Panel code redirects this to its Container child. Similarly,
>panel.numElements tells you the number of elements in the Container
>child. Because Panel is now a Group (so are TitleBar and ControlBar), it
>uses a layout to size and position those three children. When you build
>your own components, you can use Group + layout to achieve the look you
>want with minimal HTML structure.
>
>Interfaces: There are couple of key changes to interfaces. First, there
>is a new interface in the Core project: ILayoutView. This interface is
>implemented by any component whose children can be manipulated by a
>layout. The ILayoutHost interface's function, contentView, has been
>changed to return an instance of ILayoutView. The functions listed in
>ILayoutView may be expanded if we run into situations or layouts that
>need more information from their layout parents; this change is probably
>the source of most compilation issues you will see.
>
>Using Layouts inside of Components: As stated above, Panel (and
>PanelWithControlBar), now uses a layout for its own purposes. This is the
>VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose
>CSS creation makes the code much simpler and cleaner. Basically, the JS
>layout code is a few lines with maybe a loop to set each child's display
>correctly. The SWF side then has the task to mimic the layout. I have not
>completed the transition on all of the layouts, but the common ones have
>tested correctly.
>
>Regards,
>Peter Ent
>Adobe Systems/Apache Flex Project
>
>
>
Peter Ent's emails being flagged
Posted by Dave Glasser <dg...@pobox.com>.
I use Yahoo email, and it seems that the majority of Peter Ent's (and others from this list) get routed into my spam folder. Marking the flagged messages as "Not Spam" seems to have no effect on subsequent mails.
Is anyone else experiencing this with Yahoo email?
From: Peter Ent <pe...@adobe.com>
To: "dev@flex.apache.org" <de...@flex.apache.org>
Sent: Thursday, March 23, 2017 1:44 PM
Subject: [FlexJS] Summary of Changes
FlexJS Container and Layout Upgrade
My goal when starting this process was to have FlexJS produce leaner HTML structures and to reduce the amount of JavaScript code getting cross-compiled. My latest commit does the following:
- Produces simpler HTML structures for the container classes, Group, Container, and Panel.
- Simplifies a number of the layout classes for JS while fixing or tuning the SWF code to mimic the browser.
- Moves code that only affects the SWF side into SWF code blocks.
I touched only Core and HTML projects and fixed Effects so it would compile since it had the fewest issues. MDL and Charts have larger concerns and I hope to sort those out as quickly as I can.
Here are the classes and changes you will find:
Group: This new class (introduced in a previous commit) produces the simplest container for HTML (it is just a DIV) and SWF. By default it provides no layout in case you want to style in completely using CSS. Group (and its view bead, GroupView), are the foundation of the container classes. Group runs a layout bead (if there is one) and handles the sizing of elements on the SWF side. The JS side is left alone for the browser to manage (this was the biggest change).
Container: This class, which extends Group, exists to provide scrolling on the SWF side. The JS side of Container is very light adds little to what Group does. On the SWF side, Container is a nested structure in order to providing content masking and scrolling (which is handled on the JS side by using overflow:auto style, which is all the ScrollingViewport bead will do if you add it to Container).
UIBase: The major change to UIBase is that it no longer sets the position style. That means if you set the x and y properties of a component, it will, on the JS side, only set the left and top style values. If you intend to place elements at specific pixel coordinates, use a container (Group or Container) with BasicLayout which will add position:absolute style to all of the children.
NOTE: I made UIBase (and a couple other classes, too) not set position style because I saw how easily that caused other problems, especially when there was a mixing of "absolute" and "relative" position values. Now that this work is done, it may not be a bad thing to have UIBase's x and y properties set position:absolute has a convenience. It does however, have some ramifications; if you have position:absolute that will override pretty much all of the layout types. But maybe the developer just sees this and stops setting x and y. Also, there is no way to unset position once set. These are things we will have to see how they play out.
Layouts: The layouts no longer change the size of their container hosts nor do they produce the "layoutComplete" event. The GroupView class handles both of these now to make the process of layout and sizing/positioning consistent.
Lists: The DataGroup that lists use to hold the item renderers is no longer in play. The DataGroup caused unnecessary nesting of elements (DIV inside of DIV). To break that, components like List had to become their own item renderer parents. Squaring this away is perhaps the biggest challenge since a number of complex components use List as their base. The DataContainer is now the basis for lists, with List being its first subclass since they have so much in common. The DataContainerView bead is now the basis for all list views.
Panel: The Panel is now an extension of Group and it contains three children: a TitleBar, a ControlBar (for PanelWithControlBar), and a Container for the content space. When you do: panel.addElement(object), the Panel code redirects this to its Container child. Similarly, panel.numElements tells you the number of elements in the Container child. Because Panel is now a Group (so are TitleBar and ControlBar), it uses a layout to size and position those three children. When you build your own components, you can use Group + layout to achieve the look you want with minimal HTML structure.
Interfaces: There are couple of key changes to interfaces. First, there is a new interface in the Core project: ILayoutView. This interface is implemented by any component whose children can be manipulated by a layout. The ILayoutHost interface's function, contentView, has been changed to return an instance of ILayoutView. The functions listed in ILayoutView may be expanded if we run into situations or layouts that need more information from their layout parents; this change is probably the source of most compilation issues you will see.
Using Layouts inside of Components: As stated above, Panel (and PanelWithControlBar), now uses a layout for its own purposes. This is the VerticalFlexLayout, modeled on the HTML/CSS Flexbox. This general purpose CSS creation makes the code much simpler and cleaner. Basically, the JS layout code is a few lines with maybe a loop to set each child's display correctly. The SWF side then has the task to mimic the layout. I have not completed the transition on all of the layouts, but the common ones have tested correctly.
Regards,
Peter Ent
Adobe Systems/Apache Flex Project