[FlexJS] Merge feature into develop

[Peter Ent]

Hi,

I'm going to merge feature/chart-work into develop in about an hour (I think 
that's around 6pm UTC).  If you have any objections, please let me know ASAP.

To recap: These changes removed redundant events being dispatched when 
components were created and it removes extra DIVs in the HTML DOM.

I have 8 samples working (DataBinding, Charts, DataGrid, FlexJSStore, 
MDLExample, DesktopMap, DateChooser, TodoList).  I know that the MobileTrader 
and MobileStocks app are not working because the Mobile framework project needs 
to be updated to use the new container set and layouts.

Regards,
Peter Ent
Adobe Systems/Apache Flex Project

Re: [FlexJS] feature/chart_work status

[Peter Ent]

Thank you for your patience on this. I did run maven as well on my
directories and got a clean run.

On 4/10/17, 4:29 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:

>+1 for merging as you say you tested FlexJSStore and it¹s working, we
>might get develop working again, which is a rather desirable thing ;-)
>
>Chris
>
>
>Am 10.04.17, 20:40 schrieb "Peter Ent" <p...@adobe.com>:
>
>I now have the feature/chart-work branch in good shape: the frameworks
>projects build and so do all of the examples; both ANT and maven
>builds
>ran. I'm much, much more confident in the changes and stability of
>this
>feature branch than I was last week.
>
>I ran the following examples successfully: ChartExample,
>DataBindingExample, DataGridExample, FlexJSStore, DesktopMap,
>DateChooser,
>MDLExample, and TreeExample. Several of the others need some
>reworking but
>I think they are just layout issues.
>
>The changes in this feature branch reduce the amount of HTML nodes
>created
>and reduce the number of times layouts are invoked upon component
>start-up. I found several cases of redundant events and shifted some
>code
>around to make things more consistent and streamlined.
>
>My next task is to write up a Wiki page on the FlexJS site (or amend
>existing pages, as needed). I will be writing about component
>creation,
>life cycle, and layout development.
>
>I would like to merge feature/chart-work into development tomorrow. I
>do
>not anticipate any further changes unless someone finds issues that
>would
>prevent this.
>
>If there are specific examples or build questions, I'll be happy to
>answer
>them as best I can.
>
>Regards,
>Peter
>
>On 4/10/17, 9:44 AM, "Peter Ent" <p...@adobe.com> wrote:
>
>>I know have MDLExample working.
>>
>>I think I did this unwittingly: The MaterialDesignLite project's
>>default.css has the IDateProviderItemRendererMapper for the Tabs and
>>TabBar components specified as
>TabsItemRendererFactoryForArrayListData.
>>But the dataProvider being supplied to the tab components were
>Arrays and
>>not ArrayLists.
>>
>>I changed the data models to supply ArrayLists for the dataProviders
>and
>>now the tabs are working. I think our changes together made this work
>>again.
>>
>>Perhaps MDL should have a single item renderer data factory that is
>>universal in that it can accept either Array or ArrayList data and
>help
>>prevent this from happening in the future. I set this type of thing
>up in
>>the Express package (which I still have to test, now that I write
>this).
>>
>>This is the feature/chart-work branch.
>>
>>Regards,
>>Peter
>>
>>On 4/9/17, 6:26 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>>
>>>Ahh I forgot to mention that you can see issue when you look into
>>>MDLExample.
>>>Main TabBar do not display Tabs.
>>>
>>>Basically in TabBarView itemsCreated method has not been called.
>>>
>>>If you lost in there I will put some basic example.
>>>
>>>Piotr
>>>
>>>
>>>
>>>-
>>>Apache Flex PMC
>>>piotrzarzyck...@gmail.com
>>>--
>>>View this message in context:
>
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>l
>>>e
>
>>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-t
>>>p
>>>6
>
>>>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7
>>>b
>>>1
>
>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmO
>>>D
>>>B
>>>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>>>Sent from the Apache Flex Development mailing list archive at
>Nabble.com.
>>
>
>
>

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I now have the feature/chart-work branch in good shape: the frameworks
projects build and so do all of the examples; both ANT and maven builds
ran. I'm much, much more confident in the changes and stability of this
feature branch than I was last week.

I ran the following examples successfully: ChartExample,
DataBindingExample, DataGridExample, FlexJSStore, DesktopMap, DateChooser,
MDLExample, and TreeExample. Several of the others need some reworking but
I think they are just layout issues.

The changes in this feature branch reduce the amount of HTML nodes created
and reduce the number of times layouts are invoked upon component
start-up. I found several cases of redundant events and shifted some code
around to make things more consistent and streamlined.

My next task is to write up a Wiki page on the FlexJS site (or amend
existing pages, as needed). I will be writing about component creation,
life cycle, and layout development.

I would like to merge feature/chart-work into development tomorrow. I do
not anticipate any further changes unless someone finds issues that would
prevent this.

If there are specific examples or build questions, I'll be happy to answer
them as best I can.

Regards,
Peter

On 4/10/17, 9:44 AM, "Peter Ent" <p...@adobe.com> wrote:

>I know have MDLExample working.
>
>I think I did this unwittingly: The MaterialDesignLite project's
>default.css has the IDateProviderItemRendererMapper for the Tabs and
>TabBar components specified as TabsItemRendererFactoryForArrayListData.
>But the dataProvider being supplied to the tab components were Arrays and
>not ArrayLists. 
>
>I changed the data models to supply ArrayLists for the dataProviders and
>now the tabs are working. I think our changes together made this work
>again.
>
>Perhaps MDL should have a single item renderer data factory that is
>universal in that it can accept either Array or ArrayList data and help
>prevent this from happening in the future. I set this type of thing up in
>the Express package (which I still have to test, now that I write this).
>
>This is the feature/chart-work branch.
>
>Regards,
>Peter
>
>On 4/9/17, 6:26 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>
>>Ahh I forgot to mention that you can see issue when you look into
>>MDLExample.
>>Main TabBar do not display Tabs.
>>
>>Basically in TabBarView itemsCreated method has not been called.
>>
>>If you lost in there I will put some basic example.
>>
>>Piotr
>>
>>
>>
>>-
>>Apache Flex PMC
>>piotrzarzyck...@gmail.com
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp
>>6
>>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b
>>1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmOD
>>B
>>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I know have MDLExample working.

I think I did this unwittingly: The MaterialDesignLite project's
default.css has the IDateProviderItemRendererMapper for the Tabs and
TabBar components specified as TabsItemRendererFactoryForArrayListData.
But the dataProvider being supplied to the tab components were Arrays and
not ArrayLists. 

I changed the data models to supply ArrayLists for the dataProviders and
now the tabs are working. I think our changes together made this work
again.

Perhaps MDL should have a single item renderer data factory that is
universal in that it can accept either Array or ArrayList data and help
prevent this from happening in the future. I set this type of thing up in
the Express package (which I still have to test, now that I write this).

This is the feature/chart-work branch.

Regards,
Peter

On 4/9/17, 6:26 PM, "piotrz"  wrote:

>Ahh I forgot to mention that you can see issue when you look into
>MDLExample.
>Main TabBar do not display Tabs.
>
>Basically in TabBarView itemsCreated method has not been called.
>
>If you lost in there I will put some basic example.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmODB
>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I will look into it and let you know. I changed the life cycle for lists
just a little. I found that the item renderers were being created more
than once (sometimes) and the layouts were being run several times
(sometimes) so I tracked down redundant event dispatches and eliminated
them. Then I went back through examples to see what was depending on the
eliminated events and adjusted them. This is probably the same case. Once
this works out the event flow should be consistent.

‹peter

On 4/9/17, 6:26 PM, "piotrz"  wrote:

>Ahh I forgot to mention that you can see issue when you look into
>MDLExample.
>Main TabBar do not display Tabs.
>
>Basically in TabBarView itemsCreated method has not been called.
>
>If you lost in there I will put some basic example.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61069.html=02%7C01%7C%7Ca87dd5981445498e7c8508d47f98cec9%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636273741673604657=%2BiQ9rmODB
>jFFdb9Ii3fx8Ci1OAWwUPUBiVbTK0RRrHY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: git commit: [flex-asjs] [refs/heads/feature/chart-work] - Updates to MDL.

[Peter Ent]

I don't need to have DataProviderChangeNotifier do what I made it do. I
was thinking that using the same event was causing the problem in the MDL
tabs because that event causes all of the item renderers to be thrown
away. 

‹peter

On 4/9/17, 9:47 AM, "piotrz"  wrote:

>Peter,
>
>I just tested your changes. They are breaking the cases where I would like
>to change whole data provider once everything is renderer. I'm going to
>get
>back to the previous version and implement beads as I wrote above, late I
>will deeply look into the Tabs problems.
>
>Thanks,
>Piotr 
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FRe-git-commit-flex-asjs-refs-heads-f
>eature-chart-work-Updates-to-MDL-tp61043p61062.html=02%7C01%7C%7C67f6
>2c2e6d78473cc45c08d47f50565e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
>636273430404170114=4eDrhNX%2BaPt0UDNbmmEybSlhOWqTLvOJKQeMZrERQhk%3D&
>reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature/chart_work status

[Peter Ent]

Thanks. I'm having trouble understanding what code is changing the active
tab panel. I can see in the DOM, a tab with is-active set and a
corresponding tab panel has is-active set.

After I add a new tab, things look normal in the DOM. I can now select the
new tab and see that the new tab gets is-active set and the new panel gets
is-active set; no other tab or panel has is-active set.

Then I click from the new tab to a previous tab and the new tab has
is-active removed and the other tab has is-active set. But the new panel
is still is-active while the panel corresponding to the tab I clicked also
has is-active set. I'm trying to figure out where that is happening, but
the tab selection code isn't being called as far as I can tell. Is it now
just happening in CSS?

There is also a number of extra events happening, but I don't think that
is specific to the MDL code. Since a lot of this code is reused for
multiple components, its a little difficult to tell what is actually
happening. 

Thanks for any help or advice you can give.

‹peter

On 4/7/17, 2:46 PM, "piotrz"  wrote:

>Peter,
>
>If you stack on something let me know I will have some free cycles on
>Sunday. 
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61041.html=02%7C01%7C%7Cc624155aceee4a08d1b608d47de7b1ad%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636271881449970250=K4snMf9mXOg
>z7a80ci98IBhOckcZxWuv1LxhhOP3P0M%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I've been working on this most of the day. I think there is something more
fundamental going on that this example has uncovered. There appear to be
duplicate events happening causing event handlers to be registered
multiple times. I'm not comfortable releasing this yet into develop.

I'll continue to work on it over the weekend and we'll see where I get by
Monday.

Regards,
Peter

On 4/7/17, 7:41 AM, "Peter Ent" <p...@adobe.com> wrote:

>I see that. I thought I fixed that. I'll look it while I'm building the
>examples.
>‹peter
>
>On 4/6/17, 5:55 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>
>>Hi Peter,
>>
>>I just tried MDLExample and it look good, but MDLDynamicTabsExample has
>>same
>>problem. Something is going wrong when Tab is being added.
>>
>>Piotr
>>
>>
>>
>>-
>>Apache Flex PMC
>>piotrzarzyck...@gmail.com
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp
>>6
>>1035p61036.html=02%7C01%7C%7Ceab9e55a09c44c3abba808d47d38ecc1%7Cfa7b
>>1
>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636271130849952954=WQwjZQCjhY
>>E
>>ugbdoLNyqOtuIJX%2FtAh94muXgCW9GKIs%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] feature/chart_work status

[Peter Ent]

I see that. I thought I fixed that. I'll look it while I'm building the
examples.
‹peter

On 4/6/17, 5:55 PM, "piotrz"  wrote:

>Hi Peter,
>
>I just tried MDLExample and it look good, but MDLDynamicTabsExample has
>same
>problem. Something is going wrong when Tab is being added.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-chart-work-status-tp6
>1035p61036.html=02%7C01%7C%7Ceab9e55a09c44c3abba808d47d38ecc1%7Cfa7b1
>b5a7b34438794aed2c178decee1%7C0%7C0%7C636271130849952954=WQwjZQCjhYE
>ugbdoLNyqOtuIJX%2FtAh94muXgCW9GKIs%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] feature/chart_work status

[Peter Ent]

Hi,

Yesterday I intended to merge the feature/chart_work branch into develop. After 
I ran some more tests with more complex container structures I found a problem 
with one of the layouts. I finally worked it out, so now I'm running through 
all of the examples to make sure they compile so the build completes.

I will not merge into develop until tomorrow, Friday 7 Apr 2017, in the 
afternoon EDT (after 6pm UTC). I will keep you posted.

Regards,
Peter Ent
Adobe Systems/Apache Flex Project

Re: [FlexJS] Merge feature/chart-work into develop

[Peter Ent]

I fixed the missing piece for the text fields example. Still looking into
the tabs.
‹peter

On 4/5/17, 5:46 PM, "piotrz"  wrote:

>Peter,
>
>I just tried your changes and check MDLExample and MDLDynamicTabsExample.
>
>In MDLExample:
>TextFields are not displayed
>
>In MDLDynamicTabsExample:
>I see that switching between tabs, once I add Tab dynamically is broken.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Merge-feature-chart-work-into
>-develop-tp61019p61031.html=02%7C01%7C%7Ca61c76fe02a3403fbdd508d47c6e
>81c1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636270261444943615
>=AGxXFnSHBUum2L1OaMO4fw%2B2hORlmjW0PpNOorXt%2F5g%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Merge feature/chart-work into develop

[Peter Ent]

I have decided not to merge today. I ran an example with DataGrid embedded
within a Container and sized to width="100%" and it did not respond
properly to the resize. I know what happened, just working on how to make
it work correctly.

‹peter

On 4/5/17, 1:35 PM, "piotrz"  wrote:

>Peter I just merged falcon develop branch to your chart-work.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Merge-feature-chart-work-into
>-develop-tp61019p61027.html=02%7C01%7C%7C781716181b2b415be00308d47c4b
>7a92%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636270111006084015
>=fRYvuMsfPzFz7V7JU8K%2BCmpWiWFDokA%2FM8f8RBZAzoY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Merge feature/chart-work into develop

[Peter Ent]

I just changed Menu to extend DataContainer and now that works fine, for
me, in MDLExample. Thank you for reminding me.

‹peter

On 4/5/17, 11:37 AM, "piotrz"  wrote:

>Hi Peter,
>
>I didn't check MDLExample after your last push, but didn't you mention
>that
>MDL Menu is blank ?
>If it's not working I would say -1 till we have it look ok.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Merge-feature-chart-work-into
>-develop-tp61019p61020.html=02%7C01%7C%7C5d646cbc71544f2db0c808d47c3a
>eeae%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636270039930866144
>=FcdgwvNpXrJKpBYZFABsml8ww27%2B75P3eYM8%2FNNNWf0%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] Merge feature/chart-work into develop

[Peter Ent]

Hi,

I would like to merge the feature/chart-work into the develop branch in about 5 
hours from now which would make it 4:30pm EDT (9:30pm UTC, I think). Does 
anyone have a strong objection to that?

To recap:
The thrust of this feature branch was to get Charts working, but that lead to 
re-examinging the class structures of the containers. I cleaned this up and 
kept the HTML/JS side output to a minimum. I have also improved the SWF-side 
layouts to more closely mimic CSS Flexbox.

It looks like most, if not all, of MDLExample is working. DataBindingExample, 
DataGridExample, ChartExample are working. I will go back and try the Tour and 
several others as well.

Regards,
Peter

Re: [FlexJS] State of the examples

[Peter Ent]

I haven't tried it yet. I have it on my list. I'll take a look at it today.
‹peter

On 4/4/17, 11:05 AM, "Harbs"  wrote:

>Has anyone tested js:ComboBox recently? I just tried one and it¹s not
>working very well. I don¹t know if it¹s something I¹m doing wrong, or
>it¹s currently broken.
>
>> On Apr 3, 2017, at 5:33 PM, Christofer Dutz 
>>wrote:
>> 
>> Hi,
>> 
>> Today I finally found some time to investigate why the Maven Jenkins
>>Build is red for over 10 days now. It turns out that one of my
>>integration-tests was failing.
>> So, I thought that this might be related to some recent refactoring
>>reducing the number of divs and generally the structure of the generated
>>HTML and all I would have to do is to adjust some selectors.
>> 
>> So, I fired up the integration-test tomcat and had a look at the
>>application.
>> 
>> Right now, I¹m only testing FlexJSStore and the HelloWorld in my
>>rudimentary test-suite. And FlexJSStore seems completely broken. I can
>>see the logo and three buttons, but nothing is happening if I click on
>>one of them. So, it seems my little integration-test is doing its job
>>nicely. Unfortunately, right now I have no clue at why it¹s not working
>>and I¹m still filled up with a shi*load of work for my paid job. It
>>would however be great if you could have a look and eventually fix
>>what¹s broken.
>> 
>> 
>> -  ChartExample (is an empty browser window, but I know you¹re
>>still working on this)
>> 
>> -  DataBindingExample (Doesn¹t seem to get a quote)
>> 
>> -  DataBindingExample_as (Same Š but additionally layout seems
>>changed/broken)
>> 
>> -  DataBindingExample_Flat (Same as DataBindingExample)
>> 
>> -  FlexJSStore (Only the logo and three buttons displayed and
>>these have no function)
>> 
>> -  FlexJSStore_jquery (Only the logo and three buttons
>>displayed and these have no function)
>> 
>> -  FlexTeamPage_MDL (Empty browser page)
>> 
>> -  FlexWebsiteStatsViewer (Doesn¹t get/display any stats)
>> 
>> -  MobileTrader (Buttons don¹t seem to be doing anything)
>> 
>> -  TeamPage (All text in one line, can¹t scroll)
>> 
>> -  TodoListSampleApp (All entries seem to be in one place above
>>the list Š no list shown)
>> 
>> Right now, it seems as if most of our examples no longer work. I think
>>we should make sure they do. And I think it would be worth investing
>>more time in creating some Integration tests, which rudimentary test our
>>applications. I doubt we will make people fond of FlexJS if most of our
>>examples don¹t work. Or is there just some work in progress and things
>>will be running smoothly in a few days?
>> 
>> Chris
>

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Much, much more of the MDLExample is now working the changes to Tabs and
TabBar. 

- In the MDLDynamicTabsExample, the tabs appear and can be selected, but
when a new tab is added, the information about what tab was previously
selected is lost.
- In the MDLExample, Tabs selection, the first tab bar is blank and it
looks to me like it should be the same tab bar from the
MDLDynamicTabsExample, so that is strange.
- In the MDLExample, TextFields selection, there are no text fields.
- In the MDLExample, Menu selection, the menu is blank.

To get things to work I mostly removed code since the HTML classes do most
of the work now. 

Let me know what you think.

‹peter


On 4/3/17, 4:38 PM, "piotrz"  wrote:

>Peter,
>
>There is such app in the example: MDLDynamicTabsExample :)
>
>Try it out - it also do not display Tabs.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60986
>.html=02%7C01%7C%7C46e4ae0cdf604ff0050108d47ad2a216%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636268492465473589=%2BcHHrM5vs4fhxMzSZvM
>Nq3FS1VIiMf%2BA4GMDHDIJiJY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Thanks. I didn't see that. I will work on that next.

‹peter

On 4/3/17, 4:38 PM, "piotrz"  wrote:

>Peter,
>
>There is such app in the example: MDLDynamicTabsExample :)
>
>Try it out - it also do not display Tabs.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60986
>.html=02%7C01%7C%7C46e4ae0cdf604ff0050108d47ad2a216%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636268492465473589=%2BcHHrM5vs4fhxMzSZvM
>Nq3FS1VIiMf%2BA4GMDHDIJiJY%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Hi,
I think I need your help again. I noticed that when I tap on something I'm
taken to getmdl.io. Could you put another sample together that uses Tabs?
That should help make it go faster.

Thanks.
Peter

On 4/3/17, 11:28 AM, "piotrz"  wrote:

>Peter,
>
>I think falcon on your branch is synced, cause I did it.
>
>Did you check whether MDLExample is running, cause yesterday when I was
>checking - I did run MDLExample but Tabs component did not display any
>Tab.
>
>It look like to me that Tabs should extend List, but I thought that you
>will
>handle this one, so I left investigation.
>
>Let me know what are you going to work.
>
>Piotr
>
>
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60981
>.html=02%7C01%7C%7C11be79c8a91348e6593608d47aa75b57%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636268306591754509=gfyAS8irauxCjhoJcCxhR
>cM5EvPWLlYRiBARIFEQgM4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

I guess I forgot what the example actually looked like - so much stuff
appeared when I ran it! I will look into Tabs, and you are probably right,
it would extend List if it were a list.

‹peter

On 4/3/17, 11:28 AM, "piotrz"  wrote:

>Peter,
>
>I think falcon on your branch is synced, cause I did it.
>
>Did you check whether MDLExample is running, cause yesterday when I was
>checking - I did run MDLExample but Tabs component did not display any
>Tab.
>
>It look like to me that Tabs should extend List, but I thought that you
>will
>handle this one, so I left investigation.
>
>Let me know what are you going to work.
>
>Piotr
>
>
>
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60981
>.html=02%7C01%7C%7C11be79c8a91348e6593608d47aa75b57%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636268306591754509=gfyAS8irauxCjhoJcCxhR
>cM5EvPWLlYRiBARIFEQgM4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Hi,

I now have the MDLExample running. I've committed and pushed my changes
onto feature/chart-work. I have not sync'd with flex-falcon in a while -
so I don't know if that makes a difference.

I am hoping that any issues now are related to SWF-side layout code.

Going forward, if your component needs to accept MXML children, inherit
from Group or Container (depending on your SWF-side needs), not from
GroupBase or ContainerBase.

I will be writing all of this up in the FlexJS Wiki once I get it merged.
Targeting Wednesday (5 Apr 2017) for that now.

Thanks again for everyone's help trying this out.
‹peter

On 4/2/17, 5:08 PM, "Harbs"  wrote:

>Our MDL is not working because it does not support MXML.
>
>My understanding is that Peter is working on that, though.
>
>Harbs
>
>> On Apr 2, 2017, at 3:05 PM, piotrz  wrote:
>> 
>> Peter,
>> 
>> My simple example is working for me. I was looking into the MDL library
>>but
>> it look there are also work with other components which are based on
>>List.
>> 
>> If you are looking into that just let me know if you find some
>>stoppers. 
>> 
>> Piotr
>> 
>> 
>> 
>> -
>> Apache Flex PMC
>> piotrzarzyck...@gmail.com
>> --
>> View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>ex-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p609
>>69.html=02%7C01%7C%7Cf8b367e8608c460ead2808d47a0c7788%7Cfa7b1b5a7b34
>>438794aed2c178decee1%7C0%7C0%7C636267641346880904=qEUjIY7CL13M7tdzw
>>sPhsqWeTftD121DoYyXLGmeN%2FM%3D=0
>> Sent from the Apache Flex Development mailing list archive at
>>Nabble.com.
>

Re: [FlexJS] OneFlexibleChildVerticalLayout

[Peter Ent]

Hi,

I believe I have fixed part of the problem. Please refresh your copy of
feature/chart-work. There was a problem with the
OneFlexibleChildVerticalLayout.

However, there is also another problem, but that might take longer to
resolve. In the meantime, leave your example exactly as you have it.

Ideally, the flexible child should not have a height specified since that
is the child whose height you want to be determined by the layout; you
don't know how high to make it. But for some reason (yet to be
determined), removing the height attribute causes it to have a height of
zero.

When I now run your sample using the correction I just pushed, I see a
green bar all the way across the top of the browser and blue fills the
rest of the browser space.

Regards,
Peter

On 4/3/17, 8:50 AM, "Peter Ent" <p...@adobe.com> wrote:

>Something is not right with the layouts. I'm looking into it today.
>‹peter
>
>On 4/3/17, 2:43 AM, "yishayw" <yishayj...@hotmail.com> wrote:
>
>>I just tested the test case upthread on feature/chart-work and I'm
>>getting
>>the same problem. 'cont2' does not get sized and is not shown.
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-OneFlexibleChildVerticalLayo
>>u
>>t-tp60953p60975.html=02%7C01%7C%7C96b52cdb2e66494ea8c308d47a5deed0%7
>>C
>>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636267991233417705=6Ug8j
>>d
>>VRghPx47WMNiewf7e1qfhIIf1wjwqJmmP2eAg%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] OneFlexibleChildVerticalLayout

[Peter Ent]

Something is not right with the layouts. I'm looking into it today.
‹peter

On 4/3/17, 2:43 AM, "yishayw"  wrote:

>I just tested the test case upthread on feature/chart-work and I'm getting
>the same problem. 'cont2' does not get sized and is not shown.
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-OneFlexibleChildVerticalLayou
>t-tp60953p60975.html=02%7C01%7C%7C96b52cdb2e66494ea8c308d47a5deed0%7C
>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636267991233417705=6Ug8jd
>VRghPx47WMNiewf7e1qfhIIf1wjwqJmmP2eAg%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Yes. I hope to resolve this quickly.

What I did was move the MXML support from the
GroupBase/ViewBase/ContainerBase classes into the Group/View/Container
classes. I did this so that there was an easy inheritance chain:
ChartBase->ListBase->DataContainerBase->ContainerBase->GroupBase with each
of those bases contributing something along the way. But now anything that
relied on ContainerBase for its MXML needs to extend Group or Container.
For MDL, I think Group is best since it doesn't need the
viewport/contentView stuff.  The List-based classes are affected as well.

In the end, I think this will result in simpler code, cleaner HTML.
Fingers crossed anyway!

Thanks again for your help.
‹peter


On 4/2/17, 5:08 PM, "Harbs"  wrote:

>Our MDL is not working because it does not support MXML.
>
>My understanding is that Peter is working on that, though.
>
>Harbs
>
>> On Apr 2, 2017, at 3:05 PM, piotrz  wrote:
>> 
>> Peter,
>> 
>> My simple example is working for me. I was looking into the MDL library
>>but
>> it look there are also work with other components which are based on
>>List.
>> 
>> If you are looking into that just let me know if you find some
>>stoppers. 
>> 
>> Piotr
>> 
>> 
>> 
>> -
>> Apache Flex PMC
>> piotrzarzyck...@gmail.com
>> --
>> View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>ex-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p609
>>69.html=02%7C01%7C%7Cf8b367e8608c460ead2808d47a0c7788%7Cfa7b1b5a7b34
>>438794aed2c178decee1%7C0%7C0%7C636267641346880904=qEUjIY7CL13M7tdzw
>>sPhsqWeTftD121DoYyXLGmeN%2FM%3D=0
>> Sent from the Apache Flex Development mailing list archive at
>>Nabble.com.
>

Re: [FlexJS] MDL Help Needed

[Peter Ent]

I've pushed changes to HTML and MDL libraries in the feature/chart-work
branch. In order to get the small example you made to work, I had to
change MDL's List. Actually, I simplified it a great deal so that is 90%
the HTML List with just a few changes now.

The main MDLExample still isn't running, but I was able to get your
smaller example to work. I will continue to work the MDL library to get
the MDLExample running.

When you have a chance, please re-try to smaller example to verify my
changes.

Thanks again,
Peter

On 4/2/17, 9:54 AM, "piotrz"  wrote:

>Hi Peter,
>
>I was thinking that would be a solution, but I prefered to leave fix for
>you
>cause I wasn't sure.
>
>Thanks,
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60965
>.html=02%7C01%7C%7Ca8e1c2d1fa1f43d35ad508d479d0fa40%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636267385847753416=WOo9%2BdRbE7ZhVIuV7%2
>FoilVkCD7MKw%2FaFHd3kCROrQeg%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] OneFlexibleChildVerticalLayout

[Peter Ent]

Yes - In the feature/chart-work branch it is not. That was an oversight on
my part. As soon as I get MDL framework back up and running I think I can
safely merge my feature branch into develop, but I will give you all time
to do a final check.

‹peter

On 4/2/17, 9:33 AM, "Harbs" <harbs.li...@gmail.com> wrote:

>It looks like the problem is that layoutViewAfterContentLayout(); is now
>wrapped in a COMPILE::SWF block.
>
>> On Apr 2, 2017, at 8:56 AM, yishayw <yishayj...@hotmail.com> wrote:
>> 
>> Peter Ent wrote
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> The VerticalLayout will not resize the Container to fit the content.
>>>The
>>> Container (actually, GroupView), will do that after it runs the
>>>layout. So
>>> if you are seeing that a container is NOT sizing to fit its content -
>>> that's a bug.
>> 
>> That seems to be the case here.
>> 
>> 
>> 
>> 
>> --
>> View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>ex-development.247.n4.nabble.com%2FFlexJS-OneFlexibleChildVerticalLay
>>out-tp60953p60961.html=02%7C01%7C%7Cd3f7731e7b8b4bbf312e08d479ccd719
>>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636267368090489377=a4
>>giL0RsenJ%2BjkXMQV9K0rd1cLrafUMkMzkZk%2FzoKS8%3D=0
>> Sent from the Apache Flex Development mailing list archive at
>>Nabble.com.
>

Re: [FlexJS] MDL Help Needed

[Peter Ent]

HI,

I haven't got MDL working completely, but I found the cause of the
problem.  The Span class is extending ContainerBase. That won't work now
because ContainerBase no longer supports MXML children - I moved that into
Container (and Group and View).

I also don't think you need Container for HTML-only stuff like MDL, so I
have changed the HTML classes (A, Div, P, etc) to extend Group. Now a Span
inside of a Span works.

I am looking into MDL's List and probably a few others. In the end, the
MDL library should be better.

Thanks for your help.
‹peter

On 4/1/17, 1:46 PM, "piotrz"  wrote:

>Peter,
>
>I got it! :) After 3 hours of fight I was able to expose problem. I've
>prepared simple application where you can reproduce it [1].
>
>In general for some reason compiler is not generating second span:
>
>
> - this span will be missing in HTML.
>
>
>If you launch even simpler application than my example [2] you will see in
>the HTML DOM that second span is missing:
>
>ex-development.247.n4.nabble.com%2Ffile%2Fn60950%2Fspan_span.png=
>02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b5a7b34438794aed2c178
>decee1%7C0%7C0%7C63620989299044=gOO6acfka%2FGYGhqe5OQohzzCLtX%2B
>SRj9wb82Rn%2BxK8E%3D=0>
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2
>Fu%2Fs!ApVpLyjpHDC2zQBWadDWCpbMMBKM=02%7C01%7C%7Ce4cd079979434e380a9d
>08d479283621%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636209892990
>44=%2BTzTxfZpu9sHw3x4gZfMliboJRM70Hubh9QA0tHxCBY%3D=0
>[2] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2F7ImM=02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C63620989309056=yo6gCdGzzUvY
>Yy%2BcxBjgnhODWW7RhB44ijWLmaEgR7U%3D=0
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60950
>.html=02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C63620989309056=FDbFl1ZyQ25CZ1b1f%2BW
>qpms4RwUx0B9Q2lk1ry7y%2FAQ%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] OneFlexibleChildVerticalLayout

[Peter Ent]

Hi - just saw this (Sunday morning here).

When you use the "flexible" layouts, you don't need percent sizing. If you
do put explicit or percent sizing in, the layout code (SWF side) probably
won't do the right thing with it and I'd have to see what HTML does with
it.

I'm still understanding the HTML sizing and layout process. The
feature/chart-work has better - but by no means perfect - layouts. I've
been looking at several examples, like the Tour, and finding small things
to change in the code to make the layouts better.

On the JS-side, the VerticalFlexLayout, HorizontalFlexLayout,
OneFlexiableChild*, etc layouts ALL use CSS Flexbox in one way or another.
If you don't care about making your app work on the SWF side, consider
always using Groups and putting your sizing and styling into CSS, just as
you would if you were writing the code in HTML/JS rather than MXML/AS.
Container, layouts, etc. are all really for the SWF side; their JS code
bits just go and change various style settings so you don't have to it in
CSS.

If you want a column with one child taking up the majority of the space,
then make sure the container will have an

We may have more complex layouts that would have to be written in JS, so
the layout "engine" is designed to do that.

One thing that did change is that layouts no longer resize their container
when you have size-to-fit. That is, if you do:


   
   


The VerticalLayout will not resize the Container to fit the content. The
Container (actually, GroupView), will do that after it runs the layout. So
if you are seeing that a container is NOT sizing to fit its content -
that's a bug. I have however, found cases in HTML where a DIV will not
size to fit its content. Still not 100% sure on those cases, yet.

Thanks for trying this out and a big Thank You for your patience.

Peter

On 4/2/17, 7:54 AM, "yishayw"  wrote:

>That works for the test case, but in our real case we have a toolbar
>container which lays its children out horizontally and sizes its height
>according to its child buttons. Changing the layout to VerticalFlexLayout
>doesn't seem right...
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-OneFlexibleChildVerticalLayou
>t-tp60953p60959.html=02%7C01%7C%7C42f1df302dc54f552bdb08d479c02dab%7C
>fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636267313684441085=ns9ofe
>gHWKWSG%2BirEEPwMEhiP0KI6wejHg7drvV7j60%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Thanks. I will try this as soon as I can. 

Peter 


> On Apr 1, 2017, at 1:54 PM, piotrz  wrote:
> 
> Peter,
> 
> I got it! :) After 3 hours of fight I was able to expose problem. I've
> prepared simple application where you can reproduce it [1]. 
> 
> In general for some reason compiler is not generating second span:
> 
> 
> - this span will be missing in HTML.
> 
> 
> If you launch even simpler application than my example [2] you will see in
> the HTML DOM that second span is missing:
> 
> 
>  
> 
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!ApVpLyjpHDC2zQBWadDWCpbMMBKM=02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63620989299044=%2BTzTxfZpu9sHw3x4gZfMliboJRM70Hubh9QA0tHxCBY%3D=0
> [2] 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2F7ImM=02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63620989309056=yo6gCdGzzUvYYy%2BcxBjgnhODWW7RhB44ijWLmaEgR7U%3D=0
> 
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60950.html=02%7C01%7C%7Ce4cd079979434e380a9d08d479283621%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63620989309056=FDbFl1ZyQ25CZ1b1f%2BWqpms4RwUx0B9Q2lk1ry7y%2FAQ%3D=0
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] MDL Help Needed

[Peter Ent]

Thanks so much. I'm pretty sure it will be an easy fix, depending on how
MDL thinks of things, container-wise.

‹peter

On 3/31/17, 4:51 PM, "piotrz"  wrote:

>Hi Peter,
>
>I will try to expose bug in simpler example over the weekend. I will let
>you
>know.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Help-Needed-tp60946p60947
>.html=02%7C01%7C%7C54d14089e95f488c9e7b08d47878e1d5%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636265907958364327=LtwRV3ExMoGaDATTz6Dev
>mJCiYh8uZixrfg9tSX2KtM%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] MDL Help Needed

[Peter Ent]

Hi,

I've finalized the changes I wanted to make to get the core of FlexJS to be 
more efficient. Most of the projects seem to work now, except MDL. The 
MDLExample was working for me before I undertook this last change, but now it 
fails and it looks like it is failing down in some Google JS code.

I think the problem is that I changed the Container inheritance chain and MDL 
classes need to be altered a bit. But I'm not sure which MDL class(es) would be 
the place to start.

Could someone make a much simpler alternative to MainNavigation.mxml in the 
MDLExample so I can switch to that?  I'm looking for just a couple of classes. 
I can build out the example on my own until I get the failure.

I would love to merge my changes into the develop branch on Tuesday if I can 
resolve this.

Thanks so much.
—peter

In case this helps, the class structure is now this (I will update the FlexJS 
wiki with a real diagram):

GroupBase extends UIBase
+ Group extends GroupBase and adds MXML support

ViewBase extends GroupBase
+ View extends ViewBase and adds MXML support

ContainerBase extends GroupBase (adding in the hidden contentView for the SWF 
side)
+ Container extends Container and adds MXML support

DataContainerBase extends ContainerBase (adding in data mapping)
+ DataContainer extends DataContainerBase

ListBase extends List
+ List extends ListBase

ChartBase extends ListBase
+ BarChart, ColumnChart, etc. extend ChartBase

The view beads in this chain are:

GroupView (has the layout engine in it)
+ ContainerView (has viewport/scrolling support for SWF)
++ DataContainerView extends ContainerView
+++ ListView extends DataContainerView
 ChartView extends ListView

Re: [FlexJS] feature branch

[Peter Ent]

It looks like there is more work to do with Falcon, if I'm reading this
right.
‹peter

On 3/31/17, 1:32 AM, "piotrz"  wrote:

>Peter,
>
>Develop has exactly same issue and Jenkins reported it also [1]
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap
>ache.org%2Fview%2FE-G%2Fview%2FFlex%2Fjob%2FFlexJS%2520Pipeline%2Fjob%2Ffe
>ature%25252Fchart-work%2F2%2Fconsole=02%7C01%7C%7C02bb704a9a3345b445f
>c08d477f87715%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636265356413579
>952=oN%2FbbgJon0kEjmHDRzqrK4Zn0VhV1d5USzwdqcxAr5o%3D=0
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-branch-tp60916p60936.
>html=02%7C01%7C%7C02bb704a9a3345b445fc08d477f87715%7Cfa7b1b5a7b344387
>94aed2c178decee1%7C0%7C0%7C636265356413589960=auUHCX1Lx3vKZ7eNWM76%2
>BrWVHvGHbVbolknh2PvpScU%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature branch

[Peter Ent]

Hi,

I've pushed a new set of changes to feature/chart-work branch. There has
been a little restructuring of the container classes to remove code
redundancies and improve the perform a little.

If you can, please try your stuff again. You shouldn't see any differences
(fingers crossed). I know some components aren't behaving quite right yet.
I have this list so far:

Checkbox and RadioBox are not laying out properly.
Tree on the SWF side isn't responding to clicks.
DateChooser looks good, but DateField pop-up on JS is in the wrong place
(due to missing position style and miscalculation of its location) now
that nesting of elements has disappeared.

The charts look back to normal except for the "optimized" SVG version; I
think that's a position style issue, too.

Thanks,
Peter

PS: This feature branch thing really was a good idea.


On 3/29/17, 5:28 PM, "Peter Ent" <p...@adobe.com> wrote:

>Hi,
>
>I've pushed feature/chart-work that contains updates to the Chart
>package, but also other structural changes to HTML to support it.
>
>If you have time, check it out and see if your work builds and runs with
>it. MDL might need a little refactoring; I have it compiling but I do not
>know yet if the examples work.
>
>This is still a work-in-progress.
>
>‹peter

Re: [FlexJS] feature branch

[Peter Ent]

I have to revert the change to UIBase that sets position:absolute when
either .x or .y properties are set on the JS-side. Using absolute position
messes with some layouts.

All of the layout code that requires position:absolute sets it when
needed. BasicLayout, for example, sets position:absolute on each child and
then checks the strand. If it doesn't have position set to either absolute
or relative, it sets the strand's element's position to relative to ensure
the absolute positioning of the children apply relative to the strand.

If your component work needs to set .x and .y you have a couple of
alternatives:

1: Write your component using Group or Container as its base class. Then
add in the BasicLayout bead.
2: If your component is UIBase based, then use COMPILE::JS block to set
element.style.position = "absolute" whenever you set .x or .y.

We can also make a UIComponentBase class that extends GroupBase and puts
in BasicLayout. Then you just need to trigger the layout once your view
has been created and whenever it changes side.

—peter

On 3/30/17, 8:23 AM, "Peter Ent" <p...@adobe.com> wrote:

>Yes, please push the changes when you can. Thank you!
>‹peter
>
>On 3/30/17, 12:59 AM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>
>>Hi Peter,
>>
>>I just checked your branch and MDL look fine. In order to build it I had
>>to
>>merge current develop to your branch I hope that you don't mind if I
>>pushit
>>it. Changes which come from develop wasn't also breakage. Mainly maven
>>pom
>>changes and ListExample.
>>
>>Piotr
>>
>>
>>
>>-
>>Apache Flex PMC
>>piotrzarzyck...@gmail.com
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.247.n4.nabble.com%2FFlexJS-feature-branch-tp60916p60918
>>.
>>html=02%7C01%7C%7C8361970bedab42d55bfd08d4772ac759%7Cfa7b1b5a7b34438
>>7
>>94aed2c178decee1%7C0%7C0%7C636264472995482886=VD6J1EA%2BSjGKI4VUXuH
>>o
>>zLENiwvNRmgEyaUtp4LOjWs%3D=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS] feature branch

[Peter Ent]

Hi,

I took a look at your changes to ListExample. I see I forgot to put in a
ReadMe or some comments to show why the example is written the way it is.

The example is supposed to show a deconstruction of a list, by starting
with UIBase and adding in the things that make a list a "List". The point
is to show that FlexJS "advanced" components are really compositions that
can be made in MXML by starting with UIBase and adding in the right beads
to make a component and implementing the right interfaces.

But since I never put in the note, you had no way to know that!

What I think we can do is add in an alternative View MXML file that shows
the deconstruction along with a decent explanation.

I apologize for not making the example's purpose clear. I think your
changes will do nicely to show a way to make a list using DataContainer.

‹peter

On 3/30/17, 12:59 AM, "piotrz"  wrote:

>Hi Peter,
>
>I just checked your branch and MDL look fine. In order to build it I had
>to
>merge current develop to your branch I hope that you don't mind if I
>pushit
>it. Changes which come from develop wasn't also breakage. Mainly maven pom
>changes and ListExample.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-branch-tp60916p60918.
>html=02%7C01%7C%7C8361970bedab42d55bfd08d4772ac759%7Cfa7b1b5a7b344387
>94aed2c178decee1%7C0%7C0%7C636264472995482886=VD6J1EA%2BSjGKI4VUXuHo
>zLENiwvNRmgEyaUtp4LOjWs%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature branch

[Peter Ent]

Yes, please push the changes when you can. Thank you!
‹peter

On 3/30/17, 12:59 AM, "piotrz"  wrote:

>Hi Peter,
>
>I just checked your branch and MDL look fine. In order to build it I had
>to
>merge current develop to your branch I hope that you don't mind if I
>pushit
>it. Changes which come from develop wasn't also breakage. Mainly maven pom
>changes and ListExample.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-branch-tp60916p60918.
>html=02%7C01%7C%7C8361970bedab42d55bfd08d4772ac759%7Cfa7b1b5a7b344387
>94aed2c178decee1%7C0%7C0%7C636264472995482886=VD6J1EA%2BSjGKI4VUXuHo
>zLENiwvNRmgEyaUtp4LOjWs%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] feature branch

[Peter Ent]

Thanks!
‹peter

On 3/30/17, 3:34 AM, "Christofer Dutz"  wrote:

>And I just added that branch to compiler and typedefs and now you have
>your free Jenkins Build (
>
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.ap
>ache.org%2Fview%2FE-G%2Fview%2FFlex%2Fjob%2FFlexJS%2520Pipeline%2F=02
>%7C01%7C%7Cbd0687cb04dd4f9b7ca608d4773f3d7a%7Cfa7b1b5a7b34438794aed2c178de
>cee1%7C0%7C0%7C636264560888241509=uCwt48pMvDKa5kDcHaPgaVIhRhEMXHaKXC
>MnvUNTUvU%3D=0
>
>
>Chris
>
>Am 30.03.17, 06:59 schrieb "piotrz" :
>
>Hi Peter,
>
>I just checked your branch and MDL look fine. In order to build it I
>had to
>merge current develop to your branch I hope that you don't mind if I
>pushit
>it. Changes which come from develop wasn't also breakage. Mainly
>maven pom
>changes and ListExample.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-feature-branch-tp60916p60918.
>html=02%7C01%7C%7Cbd0687cb04dd4f9b7ca608d4773f3d7a%7Cfa7b1b5a7b344387
>94aed2c178decee1%7C0%7C0%7C636264560888241509=fn8aRP19hQ6svTCkwRiT7w
>MxVcieQVwPuCNWEEeOJKY%3D=0
>Sent from the Apache Flex Development mailing list archive at
>Nabble.com.
>
>

[FlexJS] feature branch

[Peter Ent]

Hi,

I've pushed feature/chart-work that contains updates to the Chart package, but 
also other structural changes to HTML to support it.

If you have time, check it out and see if your work builds and runs with it. 
MDL might need a little refactoring; I have it compiling but I do not know yet 
if the examples work.

This is still a work-in-progress.

—peter

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <harbs.li...@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 <harbs.li...@gmail.com> wrote:
>> 
>> Better, but I still have some problems (there’s probably more):
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>>  > marginRight="auto"/>
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="undo_clickHandler(event)" id="undoButton"
>>src="assets/images/icons/0726-undo.svg">
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="redo_clickHandler(event)" id="redoButton"
>>src="assets/images/icons/0727-redo.svg">
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="zoomin_clickHandler(event)"
>>src="assets/images/icons/0806-zoom-in.svg"/>
>>  > width="30" height="30"
>>click="zoomout_clickHandler(event)"
>>src="assets/images/icons/0807-zoom-out.svg"/>
>>  > width="30" height="30"
>>click="fitButton_clickHandler(event)"
>>src="assets/images/icons/0843-expand.svg"/>
>>  > width="30" height="30"
>>click="previewButton_clickHandler(event)"
>>src="assets/images/icons/0786-file-preview-white.svg"/>
>>  
>>  > width="30" height="30"
>>click="finishButton_clickHandler()"
>>src="assets/images/icons/0821-check.svg"/>
>>  
>>  > width="30" height="30"
>>click="cancelButton_clickHandler()"
>>src="assets/images/icons/0822-cross2.svg"/>
>>  
>> 
>> 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.
>>  > id="scrollContainer"
>>width="100%" height="100%">
>>  
>>  
>>  
>>  > id="designContainer"
>>className="_holder" y="0">
>>  
>>  > marginLeft="auto" marginRight="auto"/>
>>  
>>  
>>  
>>  
>> 

Re: [DISCUSS] Changing our general mode of development?

[Peter Ent]

+1 to this. 

Having pushed my changes to develop and causing a bit of mayhem, using a
feature branch would have been the right thing to do. I'm currently trying
to get the Charts package to work which will entail a little bit more
change to HTML project, and I will put this into a features branch so
everyone can try it out first before it gets merged into develop.

We need to clean FlexJS up - I believe there are lots of unused files and
the HTML project is way too big. So keep that in mind for the near future
if you want do that.

Regards,
Peter Ent

On 3/28/17, 12:49 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
<omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:

>The general approach should be to first merge dev branch into the feature
>branch and test if any examples are broken.
>
>Then ask for volunteers to test the feature branch and report issues.
>
>After a reasonable amount of time, the feature branch can ne merged into
>dev.
>
>This will not solve all the issues, but major breakages can be contained
>this way.
>
>At my work, for feature to dev merges,  we have a Pull Request attached to
>a code review and an automated build.  But given that we are open source
>we
>need to rely on self discipline and community testing.
>
>Thanks,
>Om
>
>
>On Mar 28, 2017 4:37 AM, "Carlos Rovira" <carlos.rov...@codeoscopic.com>
>wrote:
>
>+1 to all of this.
>
>For people looking at the other's work it more easy to follow git graphs
>if
>people make it's own branch.
>I suscribe all Chris's email and agree with all.
>
>So hope folks embrace the maven way of building and abandone ANT since
>there's no benefit at all in that build system.
>
>Thanks Chris for bringing this :)
>
>
>
>2017-03-28 12:04 GMT+02:00 Harbs <harbs.li...@gmail.com>:
>
>> I do think that development should be done almost exclusively on feature
>> branches.
>>
>> If the build status for a feature branch can be verified on the server
>> (like you set it up) that¹s ideal because it does not require using
>> specifically ant or maven locally.
>>
>> > On Mar 28, 2017, at 12:59 PM, Harbs <harbs.li...@gmail.com> wrote:
>> >
>> > I still have not managed to get maven setup correctly.
>> >
>> >> On Mar 28, 2017, at 12:46 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>> >>
>> >> Hi Harbs,
>> >> (this time replying to the right name ;-) )
>> >>
>> >> I usually simply make sure I update my repos and do the full maven
>> build with tests and examples locally before pushing Š I guess this is
>> sufficient protection against most problems. In IntelliJ that¹s two
>>clicks
>> and a cup of coffee or whatever beverage you prefer.
>> >>
>> >> Chris
>> >>
>> >>
>> >> Am 28.03.17, 11:41 schrieb "Harbs" <harbs.li...@gmail.com>:
>> >>
>> >>   +1.
>> >>
>> >>   I think it¹s OK to develop however we might be comfortable on a
>> feature branch, but we definitely want an approved procedure which must
>>be
>> done before committing to the develop branch.
>> >>
>> >>   Harbs
>> >>
>> >>> On Mar 28, 2017, at 12:29 PM, Christofer Dutz <
>> christofer.d...@c-ware.de> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> For the last months, we have seen a huge increase in people working
>>on
>> the FlexJS and people working on first applications using FlexJS. I
>>think
>> we should discuss how we can make sure we don¹t have interruptions like
>the
>> current one in the future.
>> >>>
>> >>> One point that has been causing pain in the past, was that some
>>people
>> are using Ant and some are using Maven. Maven is quite a bit more
>> restrictive than Ant and it builds a lot more and tests a lot more. Just
>as
>> an example in contrast to the Ant build the Maven build builds all
>Examples
>> and it also tests some of them to be runnable in a browser. The Ant
>>build
>> only builds the framework and most of the latest problems only pop up if
>> you build an application. It has occurred several times that Changed
>failed
>> the Maven build but didn¹t fail the Ant build Š just because the Ant
>>build
>> doesn¹t build everything. We could avoid this problem if people would
>>not
>> simply ignore build failures reported by the ASF Jenkins, which is
>>taking
>> care of the Maven build. It is currently setup 

Re: [FlexJS] Summary of Changes

[Peter Ent]

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"  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
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p60
>845.html=02%7C01%7C%7C7bf7b688a84b4f6fe97708d475de9039%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636263046144396713=8blALd9qJE6NYqnhdx
>ex8aXxNXeY2ZK0xZpyj95yTU8%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <greg.d...@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 <p...@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" <harbs.li...@gmail.com> wrote:
>>
>> >Better, but I still have some problems (there’s probably more):
>> >
>> >   
>> >   
>> >   > backgroundColor="0x44"/>
>> >   
>> >   
>> >   
>> >   > marginLeft="auto" marginRight="auto"/>
>> >   
>> >   
>> >   
>> >   
>> >   > >click="undo_clickHandler(event)" id="undoButton"
>> >src="assets/images/icons/0726-undo.svg">
>> >   
>> >

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <p...@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" <harbs.li...@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 <harbs.li...@gmail.com> wrote:
>>> 
>>> Better, but I still have some problems (there’s probably more):
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> >> marginRight="auto"/>
>>> 
>>> 
>>> 
>>> 
>>> >> width="30" height="30"
>>>click="undo_clickHandler(event)" id="undoButton"
>>>src="assets/images/icons/0726-undo.svg">
>>> 
>>> 
>>> 
>>> 
>>> >> width="30" height="30"
>>>click="redo_clickHandler(event)" id="redoButton"
>>>src="assets/images/icons/0727-redo.svg">
>>> 
>>> 
>>> 
>>> 
>>> >> width="30" height="30"
>>>click="zoomin_clickHandler(event)"
>>>src="assets/images/icons/0806-zoom-in.svg"/>
>>> >> width="30" height="30"
>>>click="zoomout_clickHandler(event)"
>>>src="assets/images/icons/0807-zoom-out.svg"/>
>>> >> width="30" height="30"
>>>click="fitButton_clickHandler(event)"
>>>src="assets/images/icons/0843-expand.svg"/>
>>> >> width="30" height="30"
>>>click="previewButton_clickHandler(event)"
>>>src="assets/images/icons/0786-file-preview-white.svg"/>
>>> 
>>> >> width="30" height="30"
>>>click="finishButton_clickHandler()"
>>>src="assets/images/icons/0821-check.svg"/>
>>> 
>>> >> width="30" height="30"
>>>click="cancelButton_clickHandler()"
>>>src="assets/images/icons/0822-cross2.svg"/>
>>>     
>>> 
>>> 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.
>>> >> id="scrollContainer"
>>>width="100%" height="100%">
>>> 
>>> 
>>> 
>>> >> id="designContainer"
>>>className="_holder" y="0">
>>> 
>>>

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <harbs.li...@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 <harbs.li...@gmail.com> wrote:
>> 
>> Better, but I still have some problems (there’s probably more):
>> 
>>  
>>  
>>  
>>  
>>  
>>  
>>  > marginRight="auto"/>
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="undo_clickHandler(event)" id="undoButton"
>>src="assets/images/icons/0726-undo.svg">
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="redo_clickHandler(event)" id="redoButton"
>>src="assets/images/icons/0727-redo.svg">
>>  
>>  
>>  
>>  
>>  > width="30" height="30"
>>click="zoomin_clickHandler(event)"
>>src="assets/images/icons/0806-zoom-in.svg"/>
>>  > width="30" height="30"
>>click="zoomout_clickHandler(event)"
>>src="assets/images/icons/0807-zoom-out.svg"/>
>>  > width="30" height="30"
>>click="fitButton_clickHandler(event)"
>>src="assets/images/icons/0843-expand.svg"/>
>>  > width="30" height="30"
>>click="previewButton_clickHandler(event)"
>>src="assets/images/icons/0786-file-preview-white.svg"/>
>>  
>>  > width="30" height="30"
>>click="finishButton_clickHandler()"
>>src="assets/images/icons/0821-check.svg"/>
>>  
>>  > width="30" height="30"
>>click="cancelButton_clickHandler()"
>>src="assets/images/icons/0822-cross2.svg"/>
>>  
>> 
>> 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.
>>  > id="scrollContainer"
>>width="100%" height="100%">
>>  
>>  
>>  
>>  > id="designContainer"
>>className="_holder" y="0">
>>  
>>  > marginLeft="auto" marginRight="auto"/>
>>  
>>  
>>  
>>  
>> 
>> 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 <p...@

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <greg.d...@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 <p...@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" <harbs.li...@gmail.com> wrote:
>>
>> >Better, but I still have some problems (there’s probably more):
>> >
>> >   
>> >   
>> >   > backgroundColor="0x44"/>
>> >   
>> >   
>> >   
>> >   > marginLeft="auto" marginRight="auto"/>
>> >   
>> >   
>> >   
>> >   
>> >   > >click="undo_clickHandler(event)" id="undoButton"
>> >src="assets/images/icons/0726-undo.svg">
>> >   
>> >   
>> >   
>> >   
>> >   > >click="redo_clickHandler(event)" id="redoButton"
>> >src="assets/images/icons/0727-redo.svg">
>> >   
>> >   
>> >   
>> >   
>> >   > >click="zoomin_clickHandler(event)"
>> >src="assets/images/icons/0806-zoom-in.svg"/>
>> >   > >click="zoomout_clickHandler(event)"
>> >src="assets/images/icons/0807-zoom-out.svg"/>
>> >   > >click="fitButton_clickHandler(event)"
>> >src="assets/images/icons/0843-expand.svg"/>
>> >   > >click="previewButton_clickHandler(event)"
>> >src="assets/images/

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <harbs.li...@gmail.com> wrote:

>Better, but I still have some problems (there’s probably more):
>
>   
>   
>   
>   
>   
>   
>marginRight="auto"/>
>   
>   
>   
>   
>width="30" height="30"
>click="undo_clickHandler(event)" id="undoButton"
>src="assets/images/icons/0726-undo.svg">
>   
>   
>   
>   
>width="30" height="30"
>click="redo_clickHandler(event)" id="redoButton"
>src="assets/images/icons/0727-redo.svg">
>   
>   
>   
>   
>width="30" height="30"
>click="zoomin_clickHandler(event)"
>src="assets/images/icons/0806-zoom-in.svg"/>
>width="30" height="30"
>click="zoomout_clickHandler(event)"
>src="assets/images/icons/0807-zoom-out.svg"/>
>width="30" height="30"
>click="fitButton_clickHandler(event)"
>src="assets/images/icons/0843-expand.svg"/>
>width="30" height="30"
>click="previewButton_clickHandler(event)"
>src="assets/images/icons/0786-file-preview-white.svg"/>
>   
>width="30" height="30"
>click="finishButton_clickHandler()"
>src="assets/images/icons/0821-check.svg"/>
>   
>width="30" height="30"
>click="cancelButton_clickHandler()"
>src="assets/images/icons/0822-cross2.svg"/>
>   
>
>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.
>id="scrollContainer"
>width="100%" height="100%">
>   
>   
>   
>        id="designContainer"
>className="_holder" y="0">
>   
>marginLeft="auto" marginRight="auto"/>
>   
>   
>   
>   
>
>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 <p...@adobe.com> wrote:
>> 
>> Hi,
>> 
>> I just pushed a change to UIB

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <harbs.li...@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 <p...@adobe.com> wrote:
>> 
>> For the time being, the Tour main view should have a width and a height:
>> 
>> 
>> 
>> 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" <piotrzarzyck...@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
>>> piotrzarzyck...@gmail.com
>>> --
>>> View this message in context:
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>le
>>> 
>>>x-development.247.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p
>>>60
>>> 
>>>779.html=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b
>>>34
>>> 
>>>438794aed2c178decee1%7C0%7C0%7C636261395657671115=29GdLLPJdgglZFzZ
>>>UF
>>> AOBNCBt0S8qshiPOmXCDEbRKw%3D=0
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>> 
>

Re: [FlexJS] Summary of Changes

[Peter Ent]

For the time being, the Tour main view should have a width and a height:



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"  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
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p60
>779.html=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636261395657671115=29GdLLPJdgglZFzZUF
>AOBNCBt0S8qshiPOmXCDEbRKw%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Summary of Changes

[Peter Ent]

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"  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
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Summary-of-Changes-tp60709p60
>779.html=02%7C01%7C%7Cd418c8770a394118a2f208d4745e47ea%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636261395657671115=29GdLLPJdgglZFzZUF
>AOBNCBt0S8qshiPOmXCDEbRKw%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Anyone working on the build problems?

[Peter Ent]

I didn't think the build, built the examples. If that's the case, I'll
build the examples and see what fails and then exclude those from the
build and work on them to get them running again.
‹peter

On 3/26/17, 11:30 AM, "Christofer Dutz"  wrote:

>Hi,
>
>For the last 4 days the build of FlexJS framework has been failing while
>compiling the Examples Š is anyone working on this? I would like to have
>a green build again asap. The compiler is sort of returning an error code
>of ³3² Š if that rings any bells.
>
>Chris

Re: [FlexJS] Struggling with custom HTML

[Peter Ent]

The way it stands now, you do need to create a new component in the
framework somewhere. In the long run, developers will want to make their
own component sets that make use of conditional compilation, so now would
be a good time to come up with that. You should be able to do this outside
of the framework, IMO.

You could even imagine a company that has a bunch of JavaScript
"components" that they'd like to use. We have the extern mechanism, and
maybe that's appropriate when there is a lot of JavaScript to reference,
but perhaps a developer will just want to copy a component's JavaScript
code into their project - even temporarily - and I think we should be able
to provide for that.

‹peter 

On 3/26/17, 6:36 AM, "Harbs"  wrote:

>I want to use a Topcoat checkbox in an app. That requires some HTML like
>this:
>
>
>  
>  
>  Checkbox Label
>
>
>I cannot think of a normal way of including something like this in my app
>without creating a whole new framework component. Conditional compiles do
>not seem to work. I don¹t know why. I also considered using an InnerHTML
>bead, but that does not allow handling the checkbox clicks.
>
>The fact that FlexJS abstracts the HTML and JS most of the time is great,
>but I think there needs to be an easy way to use bog-standard HTML when
>the need comes up.
>
>Thoughts?
>
>Harbs

Re: [MAVEN-BUILD] FlexJS Framework (maven) - Build # 819 - Still Failing

[Peter Ent]

I deliberately didn't work on Basic because it would almost be a complete
duplicate of the work in HTML. I think need to decide how to proceed here
and begin to divide up the projects more. HTML has way too much in it, I
think. Perhaps start a discussion thread on it again?

‹peter

On 3/24/17, 9:48 AM, "Piotr Zarzycki"  wrote:

>Maven build is failing cause we need to disable Basic module build cause
>it
>not needed anymore ? It will be needed once Alex's dual branch got merge
>into develop ?
>
>Piotr
>
>2017-03-24 13:24 GMT+01:00 Apache Jenkins Server
>
>:
>
>> The Apache Jenkins build system has built FlexJS Framework (maven)
>>(build
>> #819)
>>
>> Status: Still Failing
>>
>> Check console output at
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.a
>>pache.org%2Fjob%2F=02%7C01%7C%7C727abc0819874e18004b08d472bc86fe%7Cf
>>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636259601424031894=2YSVw6
>>91uSX%2FWFD2WQXbdNce3lOJUh3rzMo0ej8LMX8%3D=0
>> FlexJS%20Framework%20(maven)/819/ to view the results.
>
>
>
>
>-- 
>
>Greetings
>Piotr Zarzycki
>
>Flex/AIR/.NET Developer
>
>mobile: +48 880 859 557
>e-mail: piotrzarzyck...@gmail.com
>skype: zarzycki10
>
>LinkedIn: 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linked
>in.com%2Fpiotrzarzycki=02%7C01%7C%7C727abc0819874e18004b08d472bc86fe%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636259601424031894=iGof
>Ef%2FsLTtNaLcCN34aRqLkGvN7PQaUu7HknkFRSNw%3D=0
>din.com%2Fin%2Fpiotr-zarzycki-92a53552=02%7C01%7C%7C727abc0819874e180
>04b08d472bc86fe%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6362596014240
>31894=NZYrJVATQ62oglw3YohbDu0Ha848XdvrK4vdOyGPwgo%3D=0>

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <p...@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 
>whereas ContainerBase was creating a Š 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" <p...@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 

Re: [FlexJS] Summary of Changes

[Peter Ent]

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 
whereas ContainerBase was creating a Š 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" <p...@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 Data

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

Things should build now. Charts will not work yet, but MDL example (at
least one) now runs for me.

‹peter

On 3/24/17, 2:58 AM, "Christofer Dutz"  wrote:

>Hi Guys,
>
>Well I am expecting to be able to build develop Š if there are changes
>that break things, these belong in a feature branch until they are sorted
>out and merged to develop as soon as things are finished. Now please fix
>the things that are broken in develop this time, but make sure to use
>feature-branches in the future Š would that be ok?
>
>I currently don¹t need this to build as I am full with other things, I¹m
>just keeping an eye on the build itself.
>
>Chris
>
>
>Am 23.03.17, 18:12 schrieb "piotrz" :
>
>But it was expected. I can help with MDL if you will need. Just let
>me know. 
>
>If fixes will be today, there is no point to revert anything.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Container-and-Layout-Progress
>-tp60658p60701.html=02%7C01%7C%7Cec8aa6f03a6d4c49fa0608d472832f81%7Cf
>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636259355160234851=vK9jS2s
>SWjR4zHpvXqPnmWpvJgU%2FWOTB5A1o5S3QNSY%3D=0
>Sent from the Apache Flex Development mailing list archive at
>Nabble.com.
>
>

Re: [FlexJS] Summary of Changes

[Peter Ent]

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" <harbs.li...@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 <p...@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 Pan

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

I've committed and pushed changes to MDL that should make it compile. I
don't think it will work - I'll be doing that next but I wanted to get the
project to compile.

Basically, all of the List-like MDL classes now extends Group rather than
ContainerBase, which I should delete. Then I needed to make the classes
implement the updates to IItemRendererParent. The DataGroup isn't used any
longer so those classes have to act as ItemRendererParents now. Probably a
better way is to use a proxy and consolidate the code; I used this for
Panel.

But I will get MDL to work without major structural changes since it
JS-side only which makes it easier now.

—peter

On 3/23/17, 2:01 PM, "Peter Ent" <p...@adobe.com> wrote:

>Yes, Chris does have a good point and from now on* I will definitely use
>feature branches. I thought I could squeeze this through.
>
>I checked in changes to Chart that should make it compile. I doubt it will
>run, but that is on the list. I will look into MDL now. That will take
>longer.
>
>I am leary about doing the rollback at this point. You should be able to
>remove MDL from the build temporarily. If you are relying on it, I will
>try to be as quick as possible and test against the MDL example before
>pushing my changes.
>
>* I will use feature branches once I get MDL working.
>
>Apologies,
>‹peter
>
>On 3/23/17, 1:31 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>Sure. Including me.
>>
>>But Chris does have a point that we should be using feature branches more
>>than we are.
>>
>>The tone of my question might have not come across correctly. I meant to
>>ask how difficult it would be to move all changes to a feature branch and
>>push the feature branch. If it¹s too difficult, we can just continue to
>>fix the develop branch for now.
>>
>>> On Mar 23, 2017, at 7:19 PM, Josh Tynjala <joshtynj...@gmail.com>
>>>wrote:
>>> 
>>> Peter warned the list that his changes would break some things
>>>temporarily,
>>> and he asked if he should proceed. Everyone who responded said that it
>>>was
>>> okay.
>>> 
>>> - Josh
>>> 
>>> On Thu, Mar 23, 2017 at 10:11 AM, Harbs <harbs.li...@gmail.com> wrote:
>>> 
>>>> Very good question.
>>>> 
>>>> Peter, is there any chance to roll back containers and layouts and
>>>>move
>>>> all the changes to a feature branch until things are stable?
>>>> 
>>>>> On Mar 23, 2017, at 7:58 AM, Christofer Dutz
>>>>><christofer.d...@c-ware.de>
>>>> wrote:
>>>>> 
>>>>> Why don't you guys use feature branches?
>>>> 
>>>> 
>>
>

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

I should have committed a change to the build to exclude charts. Hmm. 

Peter 


> On Mar 23, 2017, at 12:57 PM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Well I guess things are broken now (
> 
> I just updated and ran a new build and Charts is exploding at the moment … 
> 
> Chris
> 
> 
> 
> Am 23.03.17, 17:02 schrieb "Peter Ent" <p...@adobe.com>:
> 
>Hi,
> 
>I've committed the changes!! The build should skip, MDL, Charts, and Basic
>projects. I will get MDL and Charts running next. But before that, I will
>have an email out with a breakdown of the changes I've made. Look for that
>in the next couple of hours.
> 
>Good luck! Please let me know what breaks. I will tell you that the
>biggest difference is the UIBase no longer sets position style so any
>elements you have that require positioning via x,y, will need to use a
>Group or Container that has the BasicLayout.
> 
>Regards,
>Peter
> 
>>On 3/22/17, 5:02 PM, "Peter Ent" <p...@adobe.com> wrote:
>> 
>> Update: I'm 99% ready to commit. I will do this tomorrow morning, my time.
>> I've spent today fixing some last issues in HTML package, while cosmetic,
>> just didn't make things look too good. There are a couple more but I'll do
>> them later.
>> 
>> I did a local merge of the latest FlexJS code and my changes and rebuilt
>> flex-asjs. The Basic and Charts packages I expected to have issues. I'm
>> not sure if I should even bother with Basic, just let me know. I have
>> commented Charts from the build.xml so it will not cause the main build to
>> fail.
>> 
>> The other project is MDL. I will also comment that from the build and will
>> work on that after I make the commit and push. The issue is that I changed
>> a couple of interfaces in Core and replaced one interface with another. I
>> just have to sync them up. Hopefully it will not take more than a day.
>> 
>> If you prefer I do MDL before doing the commit, please let me know in the
>> next 12-14 hours.
>> 
>> Thanks,
>> Peter
>> 
>>> On 3/22/17, 10:56 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>> 
>>> Yes. Commit.
>>> 
>>> Right now we need to use an earlier version because the current status is
>>> broken.
>>> 
>>>> On Mar 22, 2017, at 4:37 PM, OK <p...@olafkrueger.net> wrote:
>>>> 
>>>> In case if something is broken for somebody maybe one option is to just
>>>> check
>>>> out a previous revision by using the particular commit hash?
>>>> 
>>>> Olaf
>>>> 
>>>> 
>>>> 
>>>> --
>>>> View this message in context:
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>> l
>>>> ex-development.247.n4.nabble.com%2FFlexJS-Container-and-Layout-Progr
>>>> e
>>>> ss-tp60658p60673.html=02%7C01%7C%7C82a3a0f402a943fbc3fa08d47133951f
>>>> %
>>>> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257913736732760=hS
>>>> A
>>>> %2FIskqdzlbteHnTLr9pZwSE5Kk%2Fer9cb%2FUTJeMrZ8%3D=0
>>>> Sent from the Apache Flex Development mailing list archive at
>>>> Nabble.com.
>>> 
>> 
> 
> 
> 

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

Yes, Chris does have a good point and from now on* I will definitely use
feature branches. I thought I could squeeze this through.

I checked in changes to Chart that should make it compile. I doubt it will
run, but that is on the list. I will look into MDL now. That will take
longer.

I am leary about doing the rollback at this point. You should be able to
remove MDL from the build temporarily. If you are relying on it, I will
try to be as quick as possible and test against the MDL example before
pushing my changes.

* I will use feature branches once I get MDL working.

Apologies,
‹peter

On 3/23/17, 1:31 PM, "Harbs"  wrote:

>Sure. Including me.
>
>But Chris does have a point that we should be using feature branches more
>than we are.
>
>The tone of my question might have not come across correctly. I meant to
>ask how difficult it would be to move all changes to a feature branch and
>push the feature branch. If it¹s too difficult, we can just continue to
>fix the develop branch for now.
>
>> On Mar 23, 2017, at 7:19 PM, Josh Tynjala  wrote:
>> 
>> Peter warned the list that his changes would break some things
>>temporarily,
>> and he asked if he should proceed. Everyone who responded said that it
>>was
>> okay.
>> 
>> - Josh
>> 
>> On Thu, Mar 23, 2017 at 10:11 AM, Harbs  wrote:
>> 
>>> Very good question.
>>> 
>>> Peter, is there any chance to roll back containers and layouts and move
>>> all the changes to a feature branch until things are stable?
>>> 
 On Mar 23, 2017, at 7:58 AM, Christofer Dutz

>>> wrote:
 
 Why don't you guys use feature branches?
>>> 
>>> 
>

[FlexJS] Summary of Changes

[Peter Ent]

rectly. 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] Container and Layout Progress

[Peter Ent]

I guess I should have used a feature branch. I'm not sure how long Charts
will take. I wrote most of that code and it got pretty gnarly using List
as a basis. It probably is better to use a feature branch. Let me see if I
understand the rollback process and can get that going. Definitely a
lesson learned on that.

‹peter

On 3/23/17, 1:19 PM, "Josh Tynjala"  wrote:

>Peter warned the list that his changes would break some things
>temporarily,
>and he asked if he should proceed. Everyone who responded said that it was
>okay.
>
>- Josh
>
>On Thu, Mar 23, 2017 at 10:11 AM, Harbs  wrote:
>
>> Very good question.
>>
>> Peter, is there any chance to roll back containers and layouts and move
>> all the changes to a feature branch until things are stable?
>>
>> > On Mar 23, 2017, at 7:58 AM, Christofer Dutz
>>
>> wrote:
>> >
>> > Why don't you guys use feature branches?
>>
>>

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

Hi,

I've committed the changes!! The build should skip, MDL, Charts, and Basic
projects. I will get MDL and Charts running next. But before that, I will
have an email out with a breakdown of the changes I've made. Look for that
in the next couple of hours.

Good luck! Please let me know what breaks. I will tell you that the
biggest difference is the UIBase no longer sets position style so any
elements you have that require positioning via x,y, will need to use a
Group or Container that has the BasicLayout.

Regards,
Peter

On 3/22/17, 5:02 PM, "Peter Ent" <p...@adobe.com> wrote:

>Update: I'm 99% ready to commit. I will do this tomorrow morning, my time.
>I've spent today fixing some last issues in HTML package, while cosmetic,
>just didn't make things look too good. There are a couple more but I'll do
>them later.
>
>I did a local merge of the latest FlexJS code and my changes and rebuilt
>flex-asjs. The Basic and Charts packages I expected to have issues. I'm
>not sure if I should even bother with Basic, just let me know. I have
>commented Charts from the build.xml so it will not cause the main build to
>fail.
>
>The other project is MDL. I will also comment that from the build and will
>work on that after I make the commit and push. The issue is that I changed
>a couple of interfaces in Core and replaced one interface with another. I
>just have to sync them up. Hopefully it will not take more than a day.
>
>If you prefer I do MDL before doing the commit, please let me know in the
>next 12-14 hours.
>
>Thanks,
>Peter
>
>On 3/22/17, 10:56 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>>Yes. Commit.
>>
>>Right now we need to use an earlier version because the current status is
>>broken.
>>
>>> On Mar 22, 2017, at 4:37 PM, OK <p...@olafkrueger.net> wrote:
>>> 
>>> In case if something is broken for somebody maybe one option is to just
>>>check
>>> out a previous revision by using the particular commit hash?
>>> 
>>> Olaf
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-f
>>>l
>>>ex-development.247.n4.nabble.com%2FFlexJS-Container-and-Layout-Progr
>>>e
>>>ss-tp60658p60673.html=02%7C01%7C%7C82a3a0f402a943fbc3fa08d47133951f
>>>%
>>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257913736732760=hS
>>>A
>>>%2FIskqdzlbteHnTLr9pZwSE5Kk%2Fer9cb%2FUTJeMrZ8%3D=0
>>> Sent from the Apache Flex Development mailing list archive at
>>>Nabble.com.
>>
>

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

Update: I'm 99% ready to commit. I will do this tomorrow morning, my time.
I've spent today fixing some last issues in HTML package, while cosmetic,
just didn't make things look too good. There are a couple more but I'll do
them later.

I did a local merge of the latest FlexJS code and my changes and rebuilt
flex-asjs. The Basic and Charts packages I expected to have issues. I'm
not sure if I should even bother with Basic, just let me know. I have
commented Charts from the build.xml so it will not cause the main build to
fail.

The other project is MDL. I will also comment that from the build and will
work on that after I make the commit and push. The issue is that I changed
a couple of interfaces in Core and replaced one interface with another. I
just have to sync them up. Hopefully it will not take more than a day.

If you prefer I do MDL before doing the commit, please let me know in the
next 12-14 hours.

Thanks,
Peter

On 3/22/17, 10:56 AM, "Harbs"  wrote:

>Yes. Commit.
>
>Right now we need to use an earlier version because the current status is
>broken.
>
>> On Mar 22, 2017, at 4:37 PM, OK  wrote:
>> 
>> In case if something is broken for somebody maybe one option is to just
>>check
>> out a previous revision by using the particular commit hash?
>> 
>> Olaf
>> 
>> 
>> 
>> --
>> View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>ex-development.247.n4.nabble.com%2FFlexJS-Container-and-Layout-Progre
>>ss-tp60658p60673.html=02%7C01%7C%7C82a3a0f402a943fbc3fa08d47133951f%
>>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257913736732760=hSA
>>%2FIskqdzlbteHnTLr9pZwSE5Kk%2Fer9cb%2FUTJeMrZ8%3D=0
>> Sent from the Apache Flex Development mailing list archive at
>>Nabble.com.
>

[FlexJS] Before and After

[Peter Ent]

Hi, I have some before and after code to show you. I don't know if the HTML 
will come through and if it does not I'll put it into an Apache paste.

I ran an example of the following MXML snippet. It is a series of nested 
Containers with different layouts.





















This is what the HTML DOM looks like using the current FlexJS 0.8.0 SDK:


  

 

 
Button 1
Button 2
Button 3
 

Button 4
 

  


This is what it will look like once I am finished:



 
Button 
1
Button 2
Button 
3
 
 Button 4



Notice that the "after" is much smaller and there are fewer style ingredients. 
You can see that in the original MXML the only specific size specified was 
width="200" on the g2 Container. In the "before" HTML, that 200 appears in 
multiple places. In the "after" HTML, the 200 size appears only on the g2 
, corresponding to the g2 MXML Container.  Now its up to HTML to maintain 
this structure and anything that happens to do (such as adding more children).

Finally, if a Container were to have the  bead added to 
it, the only thing you would see in the HTML is overflow:hidden would change to 
overflow:auto for that particular .

—peter

[FlexJS] Before and After

[Peter Ent]

Hi,

 I have some before and after code to show you. I sent it out earlier but since 
I didn't see it come back into my inbox I'll assume the HTML I put into it 
didn't pass the filters, so I've put the code into a paste[1] below.

I ran an example of the following MXML snippet. It is a series of nested 
Containers with different layouts.

Notice that the "after" is much smaller and there are fewer style ingredients. 
You can see that in the original MXML the only specific size specified was 
width="200" on the g2 Container. In the "before" HTML, that 200 appears in 
multiple places. In the "after" HTML, the 200 size appears only on the g2 
, corresponding to the g2 MXML Container.  Now its up to HTML to maintain 
this structure and anything that happens to do (such as adding more children).

Finally, if a Container were to have the  bead added to 
it, the only thing you would see in the HTML is overflow:hidden would change to 
overflow:auto for that particular .

The SWF side hasn't been changed too much except that I have (at least I hope I 
have) improved the SWF-side layouts. Where the JS side may now only be as 
simple as style="display:flex; flex-flow:column", the SWF side will be an 
algorithm to mimic that. Over time I intend to improve that.

Apache Paste URL: https://paste.apache.org/HzAS

Re: [FlexJS] MDL - Project is failing to compile, help!

[Peter Ent]

I just re-sync'd myself since I am planning to merge my code and I'm
having the same issue. I did try maven and that does build, so that's
good. But the ant build should work, too.

Thanks,
Peter

On 3/22/17, 10:34 AM, "Christofer Dutz"  wrote:

>Hi Sankar,
>
>Have you tried building with Maven? That should work as it is working on
>Jenkins without any error reports.
>
>Chris
>
>
>Am 22.03.17, 12:32 schrieb "sankar" :
>
>Hi,
>
>I downloaded the latest framework source today, compiled it well and
>after
>everything downloaded I have the SDK with AIR 25.0. In this process I
>didn't
>encountered any error.
>
>I tried to compile the MDLExample project that comes within the SDK
>folder,
>but the compilation terminates abruptly. Following is my command for
>the
>compilation:
>
>
>/E:\ApacheFlexJSFrameworkSource\source\flex-asjs\out\apache-flex-flexjs-0.
>8.0-bin\js\bin\mxmlc.bat
>-load-config+=obj/MDLExampleConfig.xml -accessible=true
>-compiler.exclude-defaults-css-files=HTML.swc:defaults.css
>-html-template=src/resources/mdl-js-index-template.html -locale=en_US/
>
>The only last output after it terminates is as follows:
>
>> 
>java.lang.String.substring(String.java:1967)org.apache.flex.compiler.inter
>nal.codegen.mxml.flexjs.MXMLFlexJSPublisher.getProvidedFile(MXMLFlexJSPubl
>isher.java:488)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLF
>lexJSPublisher.sortClosureFile(MXMLFlexJSPublisher.java:472)org.apache.fle
>x.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.closureFilesIn
>Order(MXMLFlexJSPublisher.java:440)org.apache.flex.compiler.internal.codeg
>en.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:244)or
>g.apache.flex.compiler.clients.MXMLJSC.compile(MXMLJSC.java:455)org.apache
>.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:313)org.apache.fle
>x.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:270)org.apache.flex.com
>piler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:232)org.apache.flex.co
>mpiler.clients.MXMLJSC.main(MXMLJSC.java:176)
>
>I didn't received any notable error though but it just terminates.
>
>Any idea where I should look into for this break (?)
>
>Thanks!
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-MDL-Project-is-failing-to-com
>pile-help-tp60668.html=02%7C01%7C%7C2b7cf90a5f6149f2902808d47130a009%
>7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257901039832972=CS7t
>6f0Lo%2F4ezuEYV9Y%2BIoRVs15DATkq7SYQY%2BRJ1QI%3D=0
>Sent from the Apache Flex Development mailing list archive at
>Nabble.com.
>
>

Re: [FlexJS] Container and Layout Progress

[Peter Ent]

Hi,

One more thing: When I make this commit, I'm pretty sure Charts will be
broken until I address it. I can hold off the commit and address Charts
first, but I would prefer to commit Core and HTML and then fix Charts and
anything else. 

Would that strategy (commit first, fix Charts etc after) impact you?
Should I try to get more projects working first before doing the commit?

‹peter

On 3/21/17, 6:00 PM, "piotrz"  wrote:

>Hi Peter,
>
>Thank you for a hard work.
>
>I'm concerning about one thing. Alex mentioned that he will merge soon
>dual
>branch to develop - It will be tons of conflicts - Maybe it would be good
>to
>look also into that problem.
>
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Container-and-Layout-Progress
>-tp60658p60659.html=02%7C01%7C%7C0c2dad00daa048aec35808d470a6ce38%7Cf
>a7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636257309108498545=L%2Br39
>imWqdtudyvD1HZYHTaBT61Byhqbfa%2BOHknNLR4%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] Container and Layout Progress

[Peter Ent]

Hi,

I'm am making progress toward simplifying the JS output generated from the 
components. I should be making a commit either tomorrow or the next day. There 
will be some things not working 100% correctly, mostly because they need to be 
tuned to use the new layouts or are making assumptions about positioning which 
have changed.

I've made changes to Group (which as my most recent commit), Container, List, 
Panel, etc. because they depend on some base work. I've also changed some of 
the SWF-side algorithms for layout and greatly simplified the HTML/JS versions 
of those layouts.

I've tested some of the examples and have fixed components that needed tuning. 
For example, the DateChooser is now a Group with three main parts and it uses 
VerticalFlexLayout to size and position those parts. The button header and 
days-of-week list use HorizontalFlexLayout. Panel is now a Group and it, too, 
uses VerticalFlexLayout to position the title bar and Container content area.  
So it has been a bit of time using those components to expose some short-coming 
in the layout code. I also had to go back and re-think how all of these parts 
fit together and behave on the Flash and HTML platforms.

I want to produce a before-and-after snapshot of some HTML so show you the 
differences and I will produce that tomorrow. Then I have to merge my changes 
into the develop branch.

I have only touched Core and HTML framework projects, but some of the other 
projects (like Charts) depend on these and I want to assess them before going 
further.

Regards,
Peter

Re: [FlexJS] Container work status

[Peter Ent]

Hi,

I've fixed a number of layout issues. I'm still putting things together
and testing, but this problem should be addressed in my next commit.

‹peter

On 3/20/17, 3:26 AM, "yishayw"  wrote:

>I think some of your changes in BasicLayout have broken some layout
>behavior
>on the JS side. In this [1] app the blue container ("myFlex") doesn't
>stretch to screen size. After debugging this behavior for quite a while I
>came to the conclusion that BasicLayout no longer calls
>child.dispatchEvent("sizeChanged") on the JS side, so
>OneFlexibleChildVerticalLayout.layout is never called.
>
>Can you have a look? Thanks.
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FPWfp=02%7C01%7C%7C746f5bb3e6d546e018bd08d46f6388c4%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636255920673439873=Km7OxLtrp4uv
>rWA89U%2B1XkUsUuo0qRQDHtPLvIeBtUQ%3D=0
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.247.n4.nabble.com%2FFlexJS-Container-work-status-tp60417
>p60607.html=02%7C01%7C%7C746f5bb3e6d546e018bd08d46f6388c4%7Cfa7b1b5a7
>b34438794aed2c178decee1%7C0%7C0%7C636255920673449882=LO8h7nztdGjBBzh
>St7GSWyGYdBtlWglk3UA39bWp04A%3D=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Datagrid?

[Peter Ent]

I just saw this - sorry for the delay.

I'm working on changing the structure of the container classes which also
affects list and therefore DataGrid. Once I have things stable and checked
in I'll look at the bugs and see if they are resolved and if not, start
addressing them.

Regards,
Peter Ent
Adobe Systems/Apache Flex Project

On 3/14/17, 4:19 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:

>Hi Harbs,
>
>Great that you are touching it! There are couple of jiras related to
>DataGrid. If you won't see some of those  issues let us know.
>
>https://issues.apache.org/jira/browse/FLEX-34241
>https://issues.apache.org/jira/browse/FLEX-34240
>https://issues.apache.org/jira/browse/FLEX-34998
>https://issues.apache.org/jira/browse/FLEX-35222
>
>Thanks,
>Piotr
>
>
>
>-
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Datagrid-tp604
>06p60411.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Container work status

[Peter Ent]

Thanks for letting me know. I will try to be quick.

‹peter

On 3/16/17, 4:11 AM, "Justin Mclean"  wrote:

>Hi,
>
>The current changes have broken the layout in our application (not
>unexpected). When you feel it at a stable state just say so and we set if
>we can fix it up and report back any issues.
>
>Thanks,
>Justin

[FlexJS] Container work status

[Peter Ent]

Hi,

Several days ago I wrote about making changes to FlexJS to produce cleaner and 
more useful HTML. I'm in the middle of doing that and it will take several more 
days, at least.

When I'm done there will be some fundamental changes. These center around 
Container and by extension, List. And many components rely on these two pieces. 
Plus I have removed setting position style to "relative" in all of the classes 
that were doing so.

In the course of this work I've fixed a few layout bugs, too.

What you will see is that Container and Group are just  on HTML while 
Group is a single object on SWF and Container is a nested structure in order to 
provide scrolling on SWF. The List component and its subclasses will behave 
like Container in that the HTML side will just be a  with stuff (item 
renderers) in it while the SWF version will be an outer box with an inner box 
that contains the item renders and which scrolls. You will be able to have 
greater control over styling on the HTML side.

Doing this was like pulling on a thread in a sweater and while it unravels I'm 
weaving it back together just slightly differently.

Stay tuned. if you have any concerns or questions, please let me know.

Regards,
Peter Ent
Adobe Systems/Apache Flex Project.

Re: [FlexJS] Panel

[Peter Ent]

The way things are set up right now, due to the nesting of containers (div
or DisplayObjectContainer), you do get (0,0) at the top. It will usually
be necessary to have nested containers for scrolling purposes if nothing
else.

As I'm going through the code, I don't see that IChrome is actually being
recognized!! It looks like Panel is special-casing it somehow, but right
now Panel is very messed up for me due to changes I've made in my
workspace, so I'm not really certain what is going on it with.

‹peter

On 3/9/17, 2:34 PM, "yishayw"  wrote:

>I think it makes sense to start the coordinates axis below the titlebar.
>In
>ExtJS they have the concept of docked components such as toolbars and
>titles. So I think you can do (I changed syntax to pseudo-mxml)
>
>
>
>
>docked="top"/>
>
>
>In other words, docked items override the container's layout and change
>the
>coordinates axis point of origin.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Panel-tp60285p
>60307.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] Panel

[Peter Ent]

The idea of "chrome" is that these are components that do not count as
regular children and have special locations within the component. The
TitleBar and ControlBar are considered chrome because if you ask for the
children of the Panel, they are not listed and if you have so many
children in the Panel that it requires scrolling, these items do not
scroll. You can consider the fixed scrollbars in the SWF version to be
chrome pieces too.

Let's say you wanted to have a special type of title bar that did have
images and other buttons. If your component implements IChrome, then you
could add it to a container that knew how to handle chrome:


   
   


Where your MyTitleBar.mxml might be:



   




Then the ChromedContainer would place the MyTitleBar at the top of the
container outside of the content area. But you could also do this as:



   



   
 
   
   
 


This would accomplish the same thing. The problem with "chrome" is that
you could put the chrome into the middle of the container and then I'm not
sure how the layout algorithm would handle that.

‹peter


On 3/9/17, 11:16 AM, "PKumar"  wrote:

>ChromeContainer should be fine. We should be able to modify the panel
>title
>bar style as header corlor , border etc.
>
>Can Panel title bar contain other controls as image , button , check box?
>
>
>On 09-Mar-2017 9:37 PM, "piotrz [via Apache Flex Development]" <
>ml-node+s247n60286...@n4.nabble.com> wrote:
>
>Hi Peter,
>
>Let's say that you reconstructed Panel using new Group container - How can
>we use there Chrome ?
>
>I would go with ChromedContainer.
>
>Piotr
>Apache Flex PMC
>piotrzarzyck...@gmail.com
>
>
>--
>If you reply to this email, your message will be added to the discussion
>below:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Panel-
>tp60285p60286.html
>To start a new topic under Apache Flex Development, email
>ml-node+s247n1...@n4.nabble.com
>To unsubscribe from Apache Flex Development, click here
>.jtp?macro=unsubscribe_by_code=1=cHJhc2hha3VtYXJAZ21haWwuY29tfDF
>8LTU0MTcyMzE2NA==>
>.
>NAML
>.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.
>naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-na
>bble.view.web.template.NodeNamespace=notify_subscribers%21nabb
>le%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21
>nabble%3Aemail.naml>
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Panel-tp60285p
>60287.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

[FlexJS] Panel

[Peter Ent]

Hi,

I'm trying to determine if "chrome" is a necessity as part of Container or if a 
specialty "ChromedContainer" should be made (or if at all).

Panel is one component that uses chrome (the TitleBar and ControlBar implement 
IChrome). Is Panel used a lot?

As an alternative, Panel can be re-constructed to look as it does now without 
the use of chrome simply by using Group for the Panel itself and Group for the 
TitleBar and ControlBar and a Container with a ScrollingViewport for the 
content.

Please let me know your thoughts.

Thanks,
Peter Ent
Adobe Systems/Apache Flex Project

Re: [FlexJS] Group container

[Peter Ent]

As I go through FlexJS, I am wondering if we need to continue the idea of
chrome. Chrome is not something built into HTML/CSS/JS, it is artificial.
We use it for the title bar and control bar in a Panel, but a Panel can be
composed of nesting Groups and applying the correct styles.

In Flex, scroll bars were chrome but they do not have that status in HTML.
In fact, just using overflow:auto will get scrollbars (when needed) on a
Group (aka ). To get scrollbars on the SWF side we do need to embed a
scrollable area within an area that will mask the overflowing bits and
provide interactive scroll bars.

In my mind, Container serves the purpose of allowing those apps that run
on SWF or SWF/JS platforms to have scrollable content. If you were to run
only on JS, then you don't need Container, you can just style the div
provided by Group. But we need to give SWF a hint which can be done by
using Container instead of Group when you suspect the content will need to
be scrolled. The CSS style for Container can have overflow:auto set and
otherwise extend Group for the JS side. The SWF side can nest
DisplayObjectContainers and put scrollbars into the outer container and
use it as a mask. 

Panel can be composed of an outer Group, with a Group for the title bar, a
Container for the content, and another Group for the control bar. If
anyone really needs to have chrome pieces they can do the same thing.

What do you think? Should Container continue to support chrome (aka,
components implementing IChrome interface) or should it just be for
scrollable content?

Thanks,
Peter

On 3/7/17, 10:31 AM, "Peter Ent" <p...@adobe.com> wrote:

>Thanks for the feedback!
>
>As I go through the examples, I see that we (mostly me) created a number
>of nested elements, such as a  for an item renderer.
>That makes it more difficult to lay out since the content of the div is
>not always set to fill the div's space. I think each of the components and
>renderers need to be examined and updated.
>
>—peter
>
>On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
><carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>wrote:
>
>>Hi Peter, I think this awesome. get rid of the hardcoded styles in
>>component classes is such important thing and first point not only in
>>your
>>effort of create a good layout strategy, but an important previous step
>>if
>>we want to implement theming in FlexJS.
>>
>>Great! :D
>>
>>Carlos
>>
>>
>>2017-03-07 14:23 GMT+01:00 Peter Ent <p...@adobe.com>:
>>
>>> This is the theory, yes. A way to do your own thing using AS and MXML
>>>to
>>> construct the app which then generates the right amount of HTML
>>>structure,
>>> making it easier to style. Or use pre-built constructions and layouts
>>>as
>>> templates that also generate the right amount of HTML structure.
>>>
>>> I'm thinking that Panel would be a good case for a composite component
>>>and
>>> maybe even move it into Express. In theory, you can compose a Panel
>>>from:
>>>
>>>  with VerticalFlexLayout
>>>  with Horizontal Flex Layout for the Title Bar
>>>  to provide scrollable area
>>>  with Horizontal Flex Layout for the Control Bar
>>> 
>>>
>>> We'll see how this goes.
>>> ‹peter
>>>
>>> On 3/6/17, 5:02 PM, "Alex Harui" <aha...@adobe.com> wrote:
>>>
>>> >
>>> >
>>> >On 3/6/17, 1:26 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>>> >
>>> >>Hi Peter,
>>> >>
>>> >>It looks awesome. Cause if I'm enough skilled in CSS I can do
>>>whatever
>>> >>layout I want and I don't need to know any other one. - In theory. :)
>>> >
>>> >True, but like with everything else in FlexJS, we are trying to
>>> >encapsulate common patterns and make them easier to use.
>>> >
>>> >So for example if you have 3 children in a container and want to make
>>>the
>>> >first one stretchy,  you might have to write:
>>> >
>>> >
>>> >  
>>> >  
>>> >  
>>> >
>>> >
>>> >Whereas with a layout you could write:
>>> >
>>> >  
>>> >
>>> >  
>>> >
>>> >
>>> >That way you don't have to remember the names of the styles or look up
>>>how
>>> >to do it.
>>> >
>>> >Hopefully our Layouts will essentially do just that once Peter's done

Re: [FlexJS] Group container

[Peter Ent]

Thanks for the feedback!

As I go through the examples, I see that we (mostly me) created a number
of nested elements, such as a  for an item renderer.
That makes it more difficult to lay out since the content of the div is
not always set to fill the div's space. I think each of the components and
renderers need to be examined and updated.

—peter

On 3/7/17, 10:04 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:

>Hi Peter, I think this awesome. get rid of the hardcoded styles in
>component classes is such important thing and first point not only in your
>effort of create a good layout strategy, but an important previous step if
>we want to implement theming in FlexJS.
>
>Great! :D
>
>Carlos
>
>
>2017-03-07 14:23 GMT+01:00 Peter Ent <p...@adobe.com>:
>
>> This is the theory, yes. A way to do your own thing using AS and MXML to
>> construct the app which then generates the right amount of HTML
>>structure,
>> making it easier to style. Or use pre-built constructions and layouts as
>> templates that also generate the right amount of HTML structure.
>>
>> I'm thinking that Panel would be a good case for a composite component
>>and
>> maybe even move it into Express. In theory, you can compose a Panel
>>from:
>>
>>  with VerticalFlexLayout
>>  with Horizontal Flex Layout for the Title Bar
>>  to provide scrollable area
>>  with Horizontal Flex Layout for the Control Bar
>> 
>>
>> We'll see how this goes.
>> ‹peter
>>
>> On 3/6/17, 5:02 PM, "Alex Harui" <aha...@adobe.com> wrote:
>>
>> >
>> >
>> >On 3/6/17, 1:26 PM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>> >
>> >>Hi Peter,
>> >>
>> >>It looks awesome. Cause if I'm enough skilled in CSS I can do whatever
>> >>layout I want and I don't need to know any other one. - In theory. :)
>> >
>> >True, but like with everything else in FlexJS, we are trying to
>> >encapsulate common patterns and make them easier to use.
>> >
>> >So for example if you have 3 children in a container and want to make
>>the
>> >first one stretchy,  you might have to write:
>> >
>> >
>> >  
>> >  
>> >  
>> >
>> >
>> >Whereas with a layout you could write:
>> >
>> >  
>> >
>> >  
>> >
>> >
>> >That way you don't have to remember the names of the styles or look up
>>how
>> >to do it.
>> >
>> >Hopefully our Layouts will essentially do just that once Peter's done
>>with
>> >this refactor.
>> >
>> >Of course, I could be wrong...
>> >-Alex
>> >
>>
>>
>
>
>-- 
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.

Re: [FlexJS] Group container

[Peter Ent]

This is the theory, yes. A way to do your own thing using AS and MXML to
construct the app which then generates the right amount of HTML structure,
making it easier to style. Or use pre-built constructions and layouts as
templates that also generate the right amount of HTML structure.

I'm thinking that Panel would be a good case for a composite component and
maybe even move it into Express. In theory, you can compose a Panel from:

 with VerticalFlexLayout
 with Horizontal Flex Layout for the Title Bar
 to provide scrollable area
 with Horizontal Flex Layout for the Control Bar


We'll see how this goes.
‹peter

On 3/6/17, 5:02 PM, "Alex Harui"  wrote:

>
>
>On 3/6/17, 1:26 PM, "piotrz"  wrote:
>
>>Hi Peter,
>>
>>It looks awesome. Cause if I'm enough skilled in CSS I can do whatever
>>layout I want and I don't need to know any other one. - In theory. :)
>
>True, but like with everything else in FlexJS, we are trying to
>encapsulate common patterns and make them easier to use.
>
>So for example if you have 3 children in a container and want to make the
>first one stretchy,  you might have to write:
>
>
>  
>  
>  
>
>
>Whereas with a layout you could write:
>
>  
>
>  
>
>
>That way you don't have to remember the names of the styles or look up how
>to do it.
>
>Hopefully our Layouts will essentially do just that once Peter's done with
>this refactor.
>
>Of course, I could be wrong...
>-Alex
>

Re: git commit: [flex-asjs] [refs/heads/develop] - Introducing the Group container.

[Peter Ent]

Will do on the my check-in.
‹peter

On 3/6/17, 2:28 PM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:

>Hi Peter,
>
>Nice job! Could you please add @productversion FlexJS 0.8 ? I think it can
>be useful in future.
>
>Thanks,
>Piotr
>
>2017-03-06 19:15 GMT+01:00 <p...@apache.org>:
>
>> Repository: flex-asjs
>> Updated Branches:
>>   refs/heads/develop 8fe2f0831 -> 79d45cba0
>>
>>
>> Introducing the Group container.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/79d45cba
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/79d45cba
>> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/79d45cba
>>
>> Branch: refs/heads/develop
>> Commit: 79d45cba0616e394fddb68835859b1ffc87e6c48
>> Parents: 8fe2f08
>> Author: Peter Ent <p...@apache.org>
>> Authored: Mon Mar 6 13:15:34 2017 -0500
>> Committer: Peter Ent <p...@apache.org>
>> Committed: Mon Mar 6 13:15:34 2017 -0500
>>
>> --
>>  .../projects/HTML/src/main/flex/HTMLClasses.as  |   4 +-
>>  .../main/flex/org/apache/flex/core/GroupBase.as | 301
>>+++
>>  .../src/main/flex/org/apache/flex/html/Group.as |  92 ++
>>  .../org/apache/flex/html/beads/GroupView.as | 269 +
>>  .../flex/html/beads/layouts/BasicLayout.as  |  73 +
>>  .../HTML/src/main/resources/basic-manifest.xml  |   1 +
>>  .../HTML/src/main/resources/defaults.css|  10 +
>>  7 files changed, 689 insertions(+), 61 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 79d45cba/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> --
>> diff --git a/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> b/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> index bfe204b..41cb877 100644
>> --- a/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> +++ b/frameworks/projects/HTML/src/main/flex/HTMLClasses.as
>> @@ -26,8 +26,7 @@ package
>>   *  from the classes specified in manifest.xml.
>>   */
>>  internal class HTMLClasses
>> -{
>> -
>> +{
>>  import org.apache.flex.html.ToolTip; ToolTip;
>> import 
>>org.apache.flex.html.accessories.NumericOnlyTextInputBead;
>> NumericOnlyTextInputBead;
>> import org.apache.flex.html.beads.DispatchInputFinishedBead;
>> DispatchInputFinishedBead;
>> @@ -45,6 +44,7 @@ internal class HTMLClasses
>> }
>> import org.apache.flex.html.beads.ComboBoxView; ComboBoxView;
>>  import org.apache.flex.html.beads.ContainerView; ContainerView;
>> +   import org.apache.flex.html.beads.GroupView; GroupView;
>> COMPILE::SWF
>> {
>> import org.apache.flex.html.beads.ControlBarMeasurementBead;
>> ControlBarMeasurementBead;
>>
>> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
>> 79d45cba/frameworks/projects/HTML/src/main/flex/org/apache/
>> flex/core/GroupBase.as
>> --
>> diff --git 
>>a/frameworks/projects/HTML/src/main/flex/org/apache/flex/core/GroupBase.a
>>s
>> 
>>b/frameworks/projects/HTML/src/main/flex/org/apache/flex/core/GroupBase.a
>>s
>> new file mode 100644
>> index 000..7b945cc
>> --- /dev/null
>> +++ b/frameworks/projects/HTML/src/main/flex/org/apache/flex/
>> core/GroupBase.as
>> @@ -0,0 +1,301 @@
>> +///
>> /
>> +//
>> +//  Licensed to the Apache Software Foundation (ASF) under one or more
>> +//  contributor license agreements.  See the NOTICE file distributed
>>with
>> +//  this work for additional information regarding copyright ownership.
>> +//  The ASF licenses this file to You under the Apache License, Version
>> 2.0
>> +//  (the "License"); you may not use this file except in compliance
>>with
>> +//  the License.  You may obtain a copy of the License at
>> +//
>> +//  http://www.apache.org/licenses/LICENSE-2.0
>> +//
>> +//  Unless required by applicable law or agreed to in writing, software
>> +//  distributed under the License is distributed on an "

[FlexJS] Group container

[Peter Ent]

Hi,

Today I've introduced the FlexJS Group container - a lightweight alternative to 
the Container class. The Group container provides hardly more than  on the 
HTML platform and the code generated using it should produce a DOM without the 
nested  elements that Container gives you. Further, Group does not have a 
default layout. This allows you to size and position the Group's children using 
CSS.

Along with this commit is an updated BasicLayout designed to work with Group 
(the VerticalFlexLayout and HorizontalFlexLayout beads should work as well).

The SWF side for Group may or may work too well at the moment - I have to 
complete updates to BasicLayout for that to work correctly.

The real power from Group will come when I check in additional changes to 
UIBase and some of the other core components. Right now some of those 
components automatically set an element's position style to either "absolute" 
or "relative". To provide a better experience on HTML/CSS/JS, FlexJS code 
should not be setting the position style unless it is done by a layout (or done 
via CSS).  I will also be changing the View (the one we use as MyInitialView in 
the examples) to be based on Group rather than Container which will also 
eliminate another layer.

Please give Group a test if you can.

Thanks.
Peter Ent
Adobe Systems/Apache Flex Project

Re: [FlexJS] Coordinate Space

[Peter Ent]

Hi,

I think I understand this now.

When you set x, y on a component, you will be setting the left and top
styles on the HTML element. Setting these properties will no longer set
the position style (which will remain unchanged it has been set).

The Container classes will no longer have a default layout. This means you
can use Container and place items in there and style or layout everything
using CSS if you want to go that route. Some of that may not be supported
by the SWF version, however. At least not right away.

The BasicLayout will set the container's position to "relative" if it is
not already set. Then it will go through the children and set their
position styles to "absolute". This way the left and top (as well as
bottom and right) styles will work. Without setting a position of
"absolute" those styles will not locate the components (using a position
of "relative" means that items will be placed in relation to each other,
which you can now do if you do not use the BasicLayout and set position to
"relative" yourself).

NOTE: unlike normal HTML/CSS, FlexJS containers are sized by their
contents: if you do not give a container a size, the layout will determine
the size of that container. In HTML/CSS, you would probably see the
container/div span the entire page by default or have a zero height by
default depending on the placement of the children.

You need to be aware of how margin affects placement. When using absolute
position along with margin, the item will be offset by the margin
value(s). For example, if you set left:10 (or item.x = 10) and add a
margin-left:10, then item's content position will be 20. This will be the
value the x property returns. If you are migrating from Flex 4, just leave
margin settings out.

Also, for BasicLayout (aka, a container with position:relative|absolute
and children with position:absolute), container's padding has no effect.
That is, a container with padding:10 will not change the location of any
of the children placed with BasicLayout. The padding style will affect
other types of layouts.

For the Flexbox layouts, as long as you do not set the left, top (x, y)
style (or property) the items will be placed correctly. Pixel and
percentage dimensions will be honored as well. When you examine the HTML
DOM, you should not see any position or placement styles on the items in a
Flexbox type layout.

Essentially, you should be able to do a lot more of the layout in CSS if
you are targeting HTML/CSS/JS as your main platform. The layout beads are
helpful to do programmatic placement and are how the SWF version will know
what to do.

Finally, there will probably be some new container components. Not sure
what just yet, but we need to have very light ones and others that handle
scrolling and chrome. Stay tuned.

I now need to make these changes, which I will do in a separate branch.

Thank you for your input and suggestions. I think this will solve our
layout issues once complete.

Regards,
Peter

On 3/2/17, 9:37 AM, "Peter Ent" <p...@adobe.com> wrote:

>We still have to have FlexJS work on both JS and SWF sides with some
>compatibility. We could do this:
>
>x,y sets "native" values. Reading them back on SWF vs JS might yield
>different results if padding, border, and margins are set on the parent
>element. If you don't want your coordinates messed with, then nest your
>containers and apply padding, border, background, etc to the outer
>container. And definitely do not use margins.
>
>If you want to use CSS to position items, use the top, left, bottom, right
>style properties (and margin on the children). On the SWF side, these
>styles will look at the parent's padding and border values and position
>the elements accordingly (it will use x, y). If you intend to read the
>values back, they will not necessarily be what you set since the values
>are determined by the parent's padding and border as well as the child's
>own margin values.
>
>You need to specify layouts inside containers so that the SWF side knows
>what to do. If you don't intend on using the SWF output, you can just set
>the style on the container and let HTML/CSS/JS take care of it. If you
>supply a layout bead, the bead will set the display, positioning, and
>other styles on the container as necessary and may even impose styles on
>the children for the JS side. The SWF side is purely programmatic to mimic
>the JS side and it will be as close as possible but may need to be
>multiple passes.
>
>Scrolling provides more challenges for the SWF side as nested containers
>need to be used with the outer container used to mask the inner which is
>then repositioned to simulate scrolling. When you want scrolling, use
>ScrollableContainer. This class simply sets overflow:auto on the JS side.
>If you do not want or care about the SWF output, then just s

Re: [FlexJS] Coordinate Space

[Peter Ent]

We still have to have FlexJS work on both JS and SWF sides with some
compatibility. We could do this:

x,y sets "native" values. Reading them back on SWF vs JS might yield
different results if padding, border, and margins are set on the parent
element. If you don't want your coordinates messed with, then nest your
containers and apply padding, border, background, etc to the outer
container. And definitely do not use margins.

If you want to use CSS to position items, use the top, left, bottom, right
style properties (and margin on the children). On the SWF side, these
styles will look at the parent's padding and border values and position
the elements accordingly (it will use x, y). If you intend to read the
values back, they will not necessarily be what you set since the values
are determined by the parent's padding and border as well as the child's
own margin values.

You need to specify layouts inside containers so that the SWF side knows
what to do. If you don't intend on using the SWF output, you can just set
the style on the container and let HTML/CSS/JS take care of it. If you
supply a layout bead, the bead will set the display, positioning, and
other styles on the container as necessary and may even impose styles on
the children for the JS side. The SWF side is purely programmatic to mimic
the JS side and it will be as close as possible but may need to be
multiple passes.

Scrolling provides more challenges for the SWF side as nested containers
need to be used with the outer container used to mask the inner which is
then repositioned to simulate scrolling. When you want scrolling, use
ScrollableContainer. This class simply sets overflow:auto on the JS side.
If you do not want or care about the SWF output, then just set the
overflow style on the container.

‹peter

On 3/1/17, 4:12 PM, "Justin Mclean"  wrote:

>Hi,
>
>> I think we have confusion over what FlexJS is trying to deliver. If we
>>are
>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>> that, to me, implies SWF is the preferred platform and we need to make
>> HTML/JS platform conform to it. Thus the coordinate system needs to
>> reflect that. 
>> 
>> If we are trying to make it possible to use ActionScript and MXML to
>>build
>> apps that run on HTML/JS platform primarily with SWF being a good way to
>> debug and to also run efficiently, then we need to make clean JS code
>>and
>> write code to support/mimic that on SWF.
>
>I not sure home many people are going to use the SWF output, but perhaps
>I¹m missing a use case. I expect currently if people are targeting swf,
>AIR or mobile they would still use the FlexSDK. Anyone have a different
>opionion here?
>
>The workflow I found to work well as an application developer is
>basically to ignore the AS side. Reasons being:
>- The framework code is different on the AS side to the JS and has
>different features / bugs
>- Layout is different between plaftforms and it's a lot of work to get an
>application looking the same in both
>- AS side is missing support for a number of common style attributes
>- Issues setting up debugging support in the IDE
>- Chrome has a decent JS debugger now. You can set breakpoints, look at
>variables etc etc
>- Project I¹m working on is targeting JS as final output
>
>You still get the benefits of coding in AS and the IDE and compiler pick
>up a lot of issues for you quickly because of that.
>
>> I am not a JavaScript developer so I don't know what JS
>> folks come to expect and how they work with this coordinate system.
>>Maybe
>> most of the UI is static and the apps just use form fields for input and
>> effects are set up in CSS and then triggered so programmatic
>>manipulation
>> of object position is rare; I don't know.
>
>Programmatic manipulation currently is required (IMO) if you want your
>application to resize nicely / be responsive.
>
>If % x, % y, min width / height and max width / height  were implemented
>and/or % height and % width worked differently then it may not be so
>important.
>
>Thanks,
>Justin

Re: [FlexJS] Coordinate Space

[Peter Ent]

How about this…

If you are migrating from Flex 4 to FlexJS, then you:
- use (x,y) to set position
- do not put margins on your elements (margins weren't in Flex anyway)
- Use PaddedContainer[1] whenever you need a Container.
- you can safely apply padding to PaddedContainer and the child elements'
(x,y) will not be adjusted.

If you are creating things from scratch:
- only use (x,y) in Containers[2] where you do not set the Container's
padding and you do not set margins on your elements. Otherwise the value
of (x,y) will be adjusted by the margins and padding (and border thickness
as per HTML).
- instead, set the left, top, right, bottom styles to position elements.
- or use layouts and do not set any positioning.

[1] PaddedContainer will be the current Container, just renamed to reflect
the fact that it can use padding values and will still deliver (x,y)
unchanged unless you put margins on your elements. It does this because it
nests one container inside another with the inner container offset by the
padding values. PaddedContainer will automatically use a scrollable
viewport as its default so there will no extra beads needed. You can
replace the viewport with the non-scrollable one.

[2] Regular Container will be simplified to be a single containing
element. When you use this and give it padding, elements placed into it
will be offset by the padding and their (x,y) will be calculated
accordingly. You should use left, top, right, bottom styles to place these
items or use layouts.

I recommend that Container not allow scrolling and we should instead
introduce ScrollableContainer that will provide scrollbars on the SWF side
and set overflow:auto on the JS side. If you do not care about the SWF
side, then use Container but set overflow:auto in its style. Having
scrollable content on the SWF side involves nested containers.
ScrollableContainer on the SWF side will be nested containers, but padding
will apply to the inner content area. This will make left, top, right,
bottom styles work consistently between SWF and JS while delivering (x,y)
as offset values same as Container.

Regards,
Peter

On 3/1/17, 11:52 AM, "Alex Harui" <aha...@adobe.com> wrote:

>I think there are a couple of things going on:
>
>1) Some folks have asked for an API that reduces migration pain when
>porting existing Flex apps.
>2) We want the thinnest possible overhead over hand-coded HTML/JS/CSS.
>
>These two goals are in opposition because Flex:
>A) didn't support margins
>B) had properties for x,y,width,height instead of styles
>C) used % differently for width and height
>D) you "get what you set".  If you set x=0, then on the next line of code
>(x == 0) is true.
>
>Meanwhile, it has been my experience that there are some pain points in
>HTML layouts, like making one object stretch to fill all remaining space
>horizontally or vertically.
>
>It feels like in native HTML/JS you set styles and read properties.  There
>is no read/write x and y properties.  So one option is to hide the x and y
>properties.  But that would probably make migration harder.
>
>So maybe, the first question is:
>What should x and y set, and what should it report back?
>
>Now, IMO, it is totally fine for different component sets to have
>different rules.  In the "dual" branch, I've split the more Flex-like
>components (Label, Container, Button) out into the Basic.SWC and HTML.swc
>now contains the thin wrappers of HTMLElements Carlos made which may need
>more work in order to run on SWF, but have HTML element names like A, H1,
>Select, etc.
>
>For these direct HTMLElement-named components, maybe we really should hide
>x and y properties.  Then you'd have to set left or leftMargin
>appropriately instead of x.  And read back clientX and/or offsetX.
>
>For the Flex-like components in Basic, we could make everything always use
>absolute positioning.  And Container would have a more Flex-like
>coordinate space.  Don't know if that would help or not.
>
>Thoughts?
>-Alex
>
>On 3/1/17, 7:28 AM, "Peter Ent" <p...@adobe.com> wrote:
>
>>I agree with this. Now that these layouts and containers are really
>>getting used in a more practical way we can see what's going on.
>>
>>I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
>>would read x back as 0 but on JS it might read back as 20, depending on
>>padding and border styles.
>>
>>Then .left, .top, .bottom, and .right would be universal and take
>>padding,
>>margin, and border into consideration so that both SWF and JS got the
>>same
>>result.
>>
>>Since most layouts are built in SWF to mimic JS, the SWF side code would
>>use the native .x and .y to position the elements so that each pass would
>>not have to retri

Re: [FlexJS] Coordinate Space

[Peter Ent]

I agree with this. Now that these layouts and containers are really
getting used in a more practical way we can see what's going on.

I was thinking that .x and .y would be "native" setters. On SWF, .x = 0
would read x back as 0 but on JS it might read back as 20, depending on
padding and border styles.

Then .left, .top, .bottom, and .right would be universal and take padding,
margin, and border into consideration so that both SWF and JS got the same
result.

Since most layouts are built in SWF to mimic JS, the SWF side code would
use the native .x and .y to position the elements so that each pass would
not have to retrieve the parent's padding and border. These SWF layouts
should be faster, even if they require multiple passes.

Then Container needs to be cleaned up to provide miminum repeated calls to
the layout. But we have to keep mind that size determinations might be
multiple passes when explicit sizes aren't given.

‹peter

On 3/1/17, 9:17 AM, "Harbs" <harbs.li...@gmail.com> wrote:

>I think there should be two separate value sets.
>
>There should be set values and inferred values.
>
>Currently FlexJS is relying WAY too much on the browser to get and set
>values.
>
>Case in point: We just profiled our app and using the VerticalLayout, are
>relatively simple layout was taking about 250ms to lay out. Switching the
>VerticalFlexLayout got that time down to about 70ms. However, there are
>still lots of DOM calls in ContainerView and 70ms is still a lot. The
>browser should only be used to getting and setting values when
>*absolutely* necessary.
>
>I would vote for the default x and y values to be the SET ones and have
>another measuredX and measuredY to get the values set by the browser for
>cases where that¹s important (which I think is a lot more rare than is
>currently assumed).
>
>My $0.02.
>Harbs
>
>> On Mar 1, 2017, at 3:56 PM, Peter Ent <p...@adobe.com> wrote:
>> 
>> I think we have confusion over what FlexJS is trying to deliver. If we
>>are
>> trying to make a new Flex that works on both HTML/JS and SWF platforms,
>> that, to me, implies SWF is the preferred platform and we need to make
>> HTML/JS platform conform to it. Thus the coordinate system needs to
>> reflect that. 
>> 
>> If we are trying to make it possible to use ActionScript and MXML to
>>build
>> apps that run on HTML/JS platform primarily with SWF being a good way to
>> debug and to also run efficiently, then we need to make clean JS code
>>and
>> write code to support/mimic that on SWF.
>> 
>> I don't see how it can be both ways. The coordinate systems are very
>> different and even on HTML/JS, you can get different values depending on
>> the box-sizing model being used. Keep in mind that HTML/JS was not
>> designed to be an application UI platform which is why tech like Flash,
>> Canvas, Java, etc. came along (among many other reasons).
>> 
>> This confusion is reflected currently in the code (large portions of
>>this
>> layout and container were written by yours truly). I believe our
>>intention
>> is to make HTML/JS the standard and make SWF mimic it as closely as
>> possible. However, UI application developers, whether they come from
>> Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0
>>and
>> read x back as 10. I am not a JavaScript developer so I don't know what
>>JS
>> folks come to expect and how they work with this coordinate system.
>>Maybe
>> most of the UI is static and the apps just use form fields for input and
>> effects are set up in CSS and then triggered so programmatic
>>manipulation
>> of object position is rare; I don't know.
>> 
>> But I do know this must be resolved and made consistent before we can
>>have
>> a first true release. If that means adding nested divs to adjust
>> coordinates to make x=0 read back x as zero despite padding and margin,
>> then we'll do that. Or if it means you need to be aware of padding and
>> margin when reading back values, we can do that. We can also introduce
>>new
>> getters (e.g., absoluteX and absoluteY to be x,y without margin and
>> padding). 
>> 
>> There are a bunch of options and I'm sorry this wasn't resolved a long
>> time ago, but as I said, bridging these platforms is difficult and we
>>have
>> lots of good stuff written, we just need to shore up the foundation to
>> make it tight.
>> 
>> Regards,
>> Peter
>> 
>> On 3/1/17, 4:07 AM, "Fréderic Cox" <coxfrede...@gmail.com> wrote:
>> 
>>> Isn't this what localToGlobal etc.. did for Flex?
>>> 
>>> P

Re: [FlexJS] Coordinate Space

[Peter Ent]

I think we have confusion over what FlexJS is trying to deliver. If we are
trying to make a new Flex that works on both HTML/JS and SWF platforms,
that, to me, implies SWF is the preferred platform and we need to make
HTML/JS platform conform to it. Thus the coordinate system needs to
reflect that. 

If we are trying to make it possible to use ActionScript and MXML to build
apps that run on HTML/JS platform primarily with SWF being a good way to
debug and to also run efficiently, then we need to make clean JS code and
write code to support/mimic that on SWF.

I don't see how it can be both ways. The coordinate systems are very
different and even on HTML/JS, you can get different values depending on
the box-sizing model being used. Keep in mind that HTML/JS was not
designed to be an application UI platform which is why tech like Flash,
Canvas, Java, etc. came along (among many other reasons).

This confusion is reflected currently in the code (large portions of this
layout and container were written by yours truly). I believe our intention
is to make HTML/JS the standard and make SWF mimic it as closely as
possible. However, UI application developers, whether they come from
Flex/Flash or from iOS, Windows, or Android, do not expect to set x=0 and
read x back as 10. I am not a JavaScript developer so I don't know what JS
folks come to expect and how they work with this coordinate system. Maybe
most of the UI is static and the apps just use form fields for input and
effects are set up in CSS and then triggered so programmatic manipulation
of object position is rare; I don't know.

But I do know this must be resolved and made consistent before we can have
a first true release. If that means adding nested divs to adjust
coordinates to make x=0 read back x as zero despite padding and margin,
then we'll do that. Or if it means you need to be aware of padding and
margin when reading back values, we can do that. We can also introduce new
getters (e.g., absoluteX and absoluteY to be x,y without margin and
padding). 

There are a bunch of options and I'm sorry this wasn't resolved a long
time ago, but as I said, bridging these platforms is difficult and we have
lots of good stuff written, we just need to shore up the foundation to
make it tight.

Regards,
Peter

On 3/1/17, 4:07 AM, "Fréderic Cox" <coxfrede...@gmail.com> wrote:

>Isn't this what localToGlobal etc.. did for Flex?
>
>Personally I would like testButton.x to return 0 in all instances. Unless
>I
>want it's actual screen position where I use the helper functions like
>localToGlobal etc..
>
>On Tue, Feb 28, 2017 at 8:50 PM, Peter Ent <p...@adobe.com> wrote:
>
>> Hi,
>>
>> In an effort to clean up Container and layouts, we need to look at the
>> coordinate system of FlexJS. Since the goal is to have the SWF side
>>mimic
>> the JS side, perhaps we should visit the "coordinate system" of HTML.
>> You'll find an Apache Paste at [1] below. If you could run that and make
>> any changes you'd like and see what you think.
>>
>> Basically: in Flex 4 and Flash, when you position something at (0,0) and
>> you read its x coordinates back, it is at (0,0). In HTML land, that
>>isn't
>> exactly how it works. There are several things that influence the
>>position
>> of an element: the position style of its parent, the padding of its
>>parent,
>> the margin style of the element and the position style of the element.
>>
>> If you set a div to have a padding of 10 and an element to have
>> position:relative with left:0 it will appear 10 pixels from the left
>>edge
>> of the div. That's what would expect. However, if you try to read that
>> element's position, you need to use its read-only property, offsetLeft.
>> That value will be 10, not 0.
>>
>> How would you feel if FlexJS worked the same way?
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> When you ask for testButton's x or y values it would return 10 due to
>>the
>> padding on its Container parent.
>>
>> Right now Container has this inner contentArea that tries to make sure
>> testButton is (0,0) but it is a headache to maintain, I think.
>>
>> [1] https://paste.apache.org/IM1W
>>
>> Regards,
>> Peter Ent
>> Adobe Systems/Apache Flex Project
>>

Re: [FlexJS] content being push out of the way in container

[Peter Ent]

I believe at this point, Container and perhaps the layouts need a
re-write. These are fundamental to FlexJS and must be correct. FlexJS is
trying to bridge two worlds with different ideas about coordinate systems
and it is behaving erratically at times, like this.

I think the solution is more complex than going in to fix a layout that
isn't handling visible and positioning correctly.

‹peter

On 2/28/17, 8:21 PM, "Justin Mclean"  wrote:

>Hi,
>
>I have this code:
>
>http://ns.adobe.com/mxml/2009;
>xmlns:js="library://ns.apache.org/flexjs/basic²>
>visible="false">
>
>
>
>
>
>
>
>
>Changing the visibility of the cover container causes the text to jump
>outside often container.
>
>Oddly adding x=³0² y=³0² to the cover and the label fixes the issue.
>Should all items in a Container have x and y set to zero? It¹s assume
>they overlap right? - unlike a HContainer or VContainer.
>
>Thanks,
>Justin 

[FlexJS] Coordinate Space

[Peter Ent]

Hi,

In an effort to clean up Container and layouts, we need to look at the 
coordinate system of FlexJS. Since the goal is to have the SWF side mimic the 
JS side, perhaps we should visit the "coordinate system" of HTML. You'll find 
an Apache Paste at [1] below. If you could run that and make any changes you'd 
like and see what you think.

Basically: in Flex 4 and Flash, when you position something at (0,0) and you 
read its x coordinates back, it is at (0,0). In HTML land, that isn't exactly 
how it works. There are several things that influence the position of an 
element: the position style of its parent, the padding of its parent, the 
margin style of the element and the position style of the element.

If you set a div to have a padding of 10 and an element to have 
position:relative with left:0 it will appear 10 pixels from the left edge of 
the div. That's what would expect. However, if you try to read that element's 
position, you need to use its read-only property, offsetLeft. That value will 
be 10, not 0.

How would you feel if FlexJS worked the same way?








When you ask for testButton's x or y values it would return 10 due to the 
padding on its Container parent.

Right now Container has this inner contentArea that tries to make sure 
testButton is (0,0) but it is a headache to maintain, I think.

[1] https://paste.apache.org/IM1W

Regards,
Peter Ent
Adobe Systems/Apache Flex Project

[FlexJS] Container

[Peter Ent]

Hi,

I've been wrestling with Container all day. I was working on the Flex layouts, 
but then went down the rabbit hole of Containers while trying to get the 
layouts to look right.

The issue really isn't the HTML/JS side. That's pretty easy really (in 
concept). A FlexJS Container's element is a  that gets its display style 
set to flex and then a couple of other properties.

The problem comes from the SWF-side which creates several structures: The 
Container itself, its inner content area, and a viewport. All of this is to 
support padding, chrome pieces, and scrolling. The Container's content area 
appears on the HTML side, too, because of the potential chrome elements.

Most times you want to use a Container you aren't going to need chrome 
elements, so I'd like to do away with that for Container. Maybe make a 
ChromeContainer later to support Panel or make Panel be a special-case 
Container that has chrome.

QUESTION: In your Flex apps, do you need to place chrome elements besides using 
a Panel?

Scrolling, to me, is a different issue, even though scrollbars could be 
considered chrome elements. What I'd like to do here is create a 
ScrollableContainer that will add in scrollbars on the SWF side and just set 
the overlay style appropriately on the HTML/JS side (again, the JS side is 
simple).

I'm getting hung up with the nesting of the containing elements and I think 
most of the time it isn't necessary, especially on the JS side.

Grouping elements together is a fundamental thing in UI frameworks and I'm just 
not feeling that this is being handling correctly.

Thanks,
Peter

Re: [FlexJS]Layout redux

[Peter Ent]

Maybe we need a big refactor. Things like effects are pretty advanced and maybe 
they should get coupled with more advanced/complex layouts that are in a 
different package than HTML. 

The basic packages could be simpler layouts that do minimal settings. The HTML 
package could be JS only and just wrap the HTML elements for use with 
ActionScript.

Then another pancake has the SWF and JS components and beads with light layouts 
and accessories. 

This seems more PAYG. 

Peter 


> On Feb 25, 2017, at 1:46 AM, Alex Harui  wrote:
> 
> 
> 
>> On 2/24/17, 10:37 PM, "Yishay Weiss"  wrote:
>> 
>> One more thing to consider is how effects will fit in here. I can imagine
>> scenarios where items inside of a container need to have an effect
>> applied to them. Currently, the move effect relies on changing x, y
>> values, which implies absolute positioning. If they’re all part of a
>> flexbox I’m not sure how effects would apply.
>> 
>> 
>> 
>> I ran into these issues when implementing LayoutTweener and
>> EasyCollapseBead for the Accordion component.
>> 
>> 
>> 
>> If we’re serious about having swf feature parity, I think we’ll end up
>> doing everything with absolute positioning on the swf side anyway, so we
>> might as well implement it the same way on the JS side. The only downside
>> to this that I see is possible performance issues.
>> 
>> 
>> 
>> What are your thoughts on this?
> 
> That's a valid approach, but I'd much rather let the browser do the work
> and try to emulate that in the SWF.  Leveraging the browser should result
> in smaller faster applications.  However, if it turns out to do anything
> reasonably "nice" in JS requires absolute positioning then, sure it may be
> time to give up on the browser and write the code once to run in both SWF
> and JS.
> 
> It isn't wrong to have both choices so folks can use the browser when it
> works for them and switch to a fatter/slower but perfect-
> across-all-browsers version if needed.
> 
> My 2 cents,
> -Alex
> 

Re: [FlexJS]Layout redux

[Peter Ent]

Hi,

I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout
that adds code for the SWF side. In general, the SWF and JS sides look the
same. There are some differences which I'm working on, but these should be
usable. 

In doing this I've uncovered some incomplete work and/or exposed some
issues. These are, in no particular order:

UIBase vs. IUIBase. Since some of our components do not inherit from
UIBase, you cannot cast everything to this class. Now as we should really
use interfaces and not classes, casting to IUIBase generally works.
However, IUIBase is missing a lot of useful function prototypes which is
why there is a lot of casting to UIBase. I'd like to see IUIBase become
more complete. The layout code does a lot of extra, unnecessary casts on
the SWF side.

JS vs SWF layouts. When you think about it, once you've set up your 
to have the property display style, adding/removing/changing elements gets
taken care by the browser. If I set up my  with display:flex and then
put in a number of elements and start changing them via JavaScript, they
just change. Of course that doesn't work on the SWF side because there
isn't anything to size and position elements except the layout algorithms.
But the events that trigger those algorithms to execute are in the
Container class which causes the layout - SWF or JS - to execute.
Basically, it seems unnecessary to re-execute JS layouts every time since
the browser does the work. I think this should be revisited.

Padding. This still isn't working right for the Container with layout.
Part of the problem is that padding on the SWF side isn't really padding.
What it does it offset the inner contentArea. This was done so that when
you have a Container with padding=10 and you place a child into it, the
child's (x,y) reads as (0,0) and not (10,10). When I did a test with a
 that had padding:10px, the first item in it reported left:10,
top:10. So I wonder if we shouldn't treat padding the same way?

Basically, I'm wondering if we should revisit the concept of container
components again and nail it down. The SWF and JS platforms are very, very
different here and I think we need to put more thought into it. For
example, maybe layouts should be SWF only and then only to mimic what you
can do with CSS. That might be too complex though.

What I still need to do for the Flex layouts is handle visibility. Or more
specifically, state changes. The DataBindingExample doesn't work right
when the state changes.

The next thing is to add just a couple of Flexbox features. Specially, I
think justify-content, align-items, and align-content. Easy enough to add
for JS of course.

—peter

On 2/23/17, 8:25 AM, "Peter Ent" <p...@adobe.com> wrote:

>
>
>On 2/23/17, 1:54 AM, "Alex Harui" <aha...@adobe.com> wrote:
>
>>A few comments/questions:
>>
>>What does flex-box do when it runs out of room?  Doesn't it wrap to a new
>>row/column?  Or can that be controlled?  I think most folks expect
>>VerticalLayout to not create a new column but to keep going vertically
>>and
>>be clipped or scrolled.
>
>Flexbox has a number of options. Wrapping is one of them but is not the
>default. It set these layouts to not wrap so you get a single column or
>row. I did not set overflow, but it probably should be set to hidden or
>auto; trying to match up what we want the SWF side - which takes much more
>effort/code to mimic - requires us to make a choice for default behavior.
>
>I think that using the Flexbox layout will give good results on the JS
>side. I deliberately didn't add more features just to see what people
>think of using it. It has some cool layout features and seems to solve a
>lot of layout problems people have had using CSS. It might not be right
>for all situations of course.
>
>>
>>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
>>again.  That's what the dual branch is all about.
>>
>>+1 for lighterweight (one div) Container.  I thought we'd already done
>>something like that in one of the Item Renderers.  But Panel and other
>>ChromContainers probably need to extend Container because people expect
>>it, although I'd be fine if they both just implemented some sort of
>>IContainer.
>>
>>As an alternative to flex-box, it is totally fine to have more than one
>>VerticalLayout.  One that tries to use display:block and another one that
>>runs a bunch of code and does position:absolute on everything.
>>
>>In reality, how many of you use position:absolute or position:relative in
>>a real-world HTML/JS UI?  It still feels like we are going to end up
>>using
>>it too much, but maybe that's what has to happen in order to solve some
>>of
>>the common layout issues, like making one thing stretch to fill all
>>avai

Re: [FlexJS]Layout redux

[Peter Ent]

On 2/23/17, 1:54 AM, "Alex Harui" <aha...@adobe.com> wrote:

>A few comments/questions:
>
>What does flex-box do when it runs out of room?  Doesn't it wrap to a new
>row/column?  Or can that be controlled?  I think most folks expect
>VerticalLayout to not create a new column but to keep going vertically and
>be clipped or scrolled.

Flexbox has a number of options. Wrapping is one of them but is not the
default. It set these layouts to not wrap so you get a single column or
row. I did not set overflow, but it probably should be set to hidden or
auto; trying to match up what we want the SWF side - which takes much more
effort/code to mimic - requires us to make a choice for default behavior.

I think that using the Flexbox layout will give good results on the JS
side. I deliberately didn't add more features just to see what people
think of using it. It has some cool layout features and seems to solve a
lot of layout problems people have had using CSS. It might not be right
for all situations of course.

>
>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
>again.  That's what the dual branch is all about.
>
>+1 for lighterweight (one div) Container.  I thought we'd already done
>something like that in one of the Item Renderers.  But Panel and other
>ChromContainers probably need to extend Container because people expect
>it, although I'd be fine if they both just implemented some sort of
>IContainer.
>
>As an alternative to flex-box, it is totally fine to have more than one
>VerticalLayout.  One that tries to use display:block and another one that
>runs a bunch of code and does position:absolute on everything.
>
>In reality, how many of you use position:absolute or position:relative in
>a real-world HTML/JS UI?  It still feels like we are going to end up using
>it too much, but maybe that's what has to happen in order to solve some of
>the common layout issues, like making one thing stretch to fill all
>available space.

I agree. When you look at the generated HTML, there's way too much forcing
of size and position that a natural HTML author would not use. But I'm not
sure how to really do this programmatically while allowing all sorts of
situations to work.

>
>My 2 cents,
>-Alex
>
>On 2/22/17, 2:31 PM, "Peter Ent" <p...@adobe.com> wrote:
>
>>Great. Thanks. I will take a look at these tomorrow.
>>‹peter
>>
>>On 2/22/17, 5:19 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>>This too:
>>>https://philipwalton.github.io/solved-by-flexbox/
>>>
>>>> On Feb 23, 2017, at 12:16 AM, Harbs <harbs.li...@gmail.com> wrote:
>>>> 
>>>> BTW, this might be useful:
>>>> https://github.com/philipwalton/flexbugs
>>>><https://github.com/philipwalton/flexbugs>
>>>> 
>>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.li...@gmail.com
>>>>><mailto:harbs.li...@gmail.com>> wrote:
>>>>> 
>>>>> How well do these work in IE?
>>>>> 
>>>>> It looks like Flexbox is not supported at all in IE prior to IE10 and
>>>>>even in IE10 and 11, it only has buggy support.[1]
>>>>> 
>>>>> [1]http://caniuse.com/#feat=flexbox
>>>>><http://caniuse.com/#feat=flexbox>
>>>>> 
>>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <p...@adobe.com
>>>>>><mailto:p...@adobe.com>> wrote:
>>>>>> 
>>>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>>>HorizontalFlexLayout as
>>>>>> well as a change to DataBindingExample to use them. I consider these
>>>>>> temporary and would like to make them be the VerticalLayout and
>>>>>> HorizontalLayout in the near future.
>>>>> 
>>>> 
>>>
>>
>

Re: [FlexJS] Horizontal list missing scrollbar

[Peter Ent]

Not sure yet but I will look into it tomorrow. 

Peter 


> On Feb 22, 2017, at 5:45 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Anyone have any ideas here?
> 
> Thanks,
> Justin

Re: [FlexJS]Layout redux

[Peter Ent]

Great. Thanks. I will take a look at these tomorrow.
‹peter

On 2/22/17, 5:19 PM, "Harbs" <harbs.li...@gmail.com> wrote:

>This too:
>https://philipwalton.github.io/solved-by-flexbox/
>
>> On Feb 23, 2017, at 12:16 AM, Harbs <harbs.li...@gmail.com> wrote:
>> 
>> BTW, this might be useful:
>> https://github.com/philipwalton/flexbugs
>><https://github.com/philipwalton/flexbugs>
>> 
>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.li...@gmail.com
>>><mailto:harbs.li...@gmail.com>> wrote:
>>> 
>>> How well do these work in IE?
>>> 
>>> It looks like Flexbox is not supported at all in IE prior to IE10 and
>>>even in IE10 and 11, it only has buggy support.[1]
>>> 
>>> [1]http://caniuse.com/#feat=flexbox <http://caniuse.com/#feat=flexbox>
>>> 
>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <p...@adobe.com
>>>><mailto:p...@adobe.com>> wrote:
>>>> 
>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>HorizontalFlexLayout as
>>>> well as a change to DataBindingExample to use them. I consider these
>>>> temporary and would like to make them be the VerticalLayout and
>>>> HorizontalLayout in the near future.
>>> 
>> 
>

Re: [FlexJS]Layout redux

[Peter Ent]

First, I like the idea of moving as much into CSS as possible, at least to
the extent we can support in on the SWF side.

Secondly, I think the layouts setting the display makes sense in this
case, based on what Harbs said.

I was thinking of this:

A. UIBase does not set position and display. The values of x, y, width,
height also do not set the corresponding styles (left, top, width, right).
Because we have wrapped elements now and not derived on the SWF side,
setting x, y, width, height do not have to automatically set the
corresponding values on the wrapped element; this will be done by a layout.

B. Container is lightweight and wraps its children so that it can be moved
and displayed as a single unit. Effects would also apply to all items in a
Container.

C. You may size a Container explicitly, but it will clip its children. No
support for scrolling.

D. Containers have layouts and it is the layouts that use the properties
set on the UIBase children. So the BasicLayout would set the children of
the div to display:block, position:absolute and then use the x, y, width,
height properties to set the corresponding styles. This goes against the
above idea of putting everything in CSS, but the point of a layout is to
programmatically size and position items. The VerticalLayout would set the
display:flex of the Container/div and NOT set display/position, etc styles
on its children. Then CSS can be used to set the children's styles; CSS
can also be used to set alignment values on the entire Container.

E. We could have a NoLayout layout that does nothing (the default for a
Container being BasicLayout).

F. Views (every application needs a View) as Containers and in CSS, have
their display:block, position:absolute. This enables the position:absolute
of their children and so forth to have their top, left, bottom, right
styles work correctly.

G. We have ScrollableContainer and ChromeContainer to supply the missing
parts in the PAYG system.

This approach (or something like it) would be in keeping with HTML/CSS
leading the way and then we'd just have to get SWF to follow along. I
don't think that's too much of a problem as long as the SWF version of the
layouts can read the CSS and get the values.

I'm sure there are conditions when a layout isn't used, such as building a
component via its ViewBead, but I think they can be handled by either
introducing the layout concept to those component (e.g. DataGridLayout to
be used by the DataGrid component) or having the ViewBead explicitly
change the values or have them pre-set in defaults.css.

Whew.
‹peter

On 2/22/17, 5:10 PM, "Harbs" <harbs.li...@gmail.com> wrote:

>For that to work, the bead will need to append the class name of the
>component. It cannot be applied to the bead itself.
>
>Harbs
>
>> On Feb 23, 2017, at 12:05 AM, Carlos Rovira
>><carlos.rov...@codeoscopic.com> wrote:
>> 
>> Hi Peter,
>> 
>> one of the things I'd want to do is remove "styles" in source code and
>>move
>> to css.
>> For example:
>> 
>> viewBead.contentView.element.style["display"] = "flex";
>> 
>> What do you think about to move this to default.css class, i.e.:
>> 
>> HorizontalFlexLayout {
>>   display: flex;
>> ...
>> }
>> 
>> I think we should move all that kind of code to css so we could tweak
>> (change/modifiy) easily if we need
>> 
>> thanks
>> 
>> 
>> 2017-02-22 23:00 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>> 
>>> I totally agree with this.
>>> 
>>> There should be a simple Container (with H and V variants) and a
>>>separate
>>> ChromeContainer. The vast majority of Containers do not need the extra
>>>div.
>>> 
>>> Moving Panel to Express is an option, but I¹m not sure it¹s necessary.
>>> 
>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <p...@adobe.com> wrote:
>>>> 
>>>> I think the Container needs to be redone. I also think it does too
>>>>much
>>> or
>>>> we need a lighter weight component like Group. Container generates two
>>>> s for the HTML side. This is to allow for "chrome" such as
>>>>headers
>>>> and footers. More specifically, it was designed to make it possible to
>>>> write Panel (maybe Panel should be a composite component and moved
>>>>into
>>>> Express).
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> 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
>> in

Re: [FlexJS] Spacers and positioning

[Peter Ent]

I posted this to a different email thread, but I pushed VerticalFlexLayout
and HorizontalFlexLayout. Give them a try; only the JS side is affected.

For spacing, put margins on the children of the Container. Padding on
Container is still broken; I know why, just have to decide how to address
it.

Percentage sizing for the children works, too, although the Flexbox will
override them if it feels it must. Personally, I think it does a great job
of presenting the information.

On 2/22/17, 8:55 AM, "Peter Ent" <p...@adobe.com> wrote:

>I'll be including the issues of spacing and positioning in my work with
>layouts.
>
>‹peter
>
>On 2/21/17, 5:56 AM, "yishayw" <yishayj...@hotmail.com> wrote:
>
>>That sounds like a good idea. Let me know if I can help.
>>
>>
>>
>>--
>>View this message in context:
>>http://apache-flex-development.247.n4.nabble.com/FlexJS-Spacers-and-p
>>o
>>sitioning-tp59242p59706.html
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>

Re: [FlexJS]Layout redux

[Peter Ent]

Hi,

I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
well as a change to DataBindingExample to use them. I consider these
temporary and would like to make them be the VerticalLayout and
HorizontalLayout in the near future.

If you look at their code you will see the COMPILE::JS side is very, very
short now. All it does it set the display:flex and flow-flow: row|column
on the contentView of the layout host. The SWF side remains unchanged for
now. I did not make it possible yet to use Flexbox properties of
align-items, justify-content, etc.

I spent most of the time coming to terms with the Container. I've left it
alone for now, but I think it needs work. First, padding is not working
for the container, so that will not have any affect.

I think the Container needs to be redone. I also think it does too much or
we need a lighter weight component like Group. Container generates two
s for the HTML side. This is to allow for "chrome" such as headers
and footers. More specifically, it was designed to make it possible to
write Panel (maybe Panel should be a composite component and moved into
Express).

The JS code generated for Container s provides style information that
is too much, really, unless you add in a chrome item. I think if there is
a lighter component that just provides a box that surrounds its children
it would help clean things up. The JS side should then be easier to style.

If you want scrolling, then you'd have to use a Container and we can make
the Container use a scrolling viewport by default then, since Group would
be the default non-scrolling offering.

Regards,
Peter
 

On 2/22/17, 12:03 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:

>Hi Peter, that sound very good :)
>thanks!
>
>2017-02-22 16:53 GMT+01:00 Peter Ent <p...@adobe.com>:
>
>> That's a good strategy. My experiments this morning look like Flexbox is
>> the way to go. Its widely supported now and seems pretty easy to use.
>>
>> I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
>> them extend the current versions just so the SWF side stays the same for
>> right now. The JS side will implement Flexbox. Then we can all try it
>>out
>> and see how it behaves. If that's good, I can replace the current JS
>> version with the Flexbox version and then work on the SWF side to make
>>it
>> compatible.
>>
>> Will keep you all posted.
>>
>> —peter
>>
>> On 2/22/17, 10:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>> wrote:
>>
>> >That looks very promising Peter. Look forward to see some progress :)
>> >If flexbox is the future, I think we should always look to go with that
>> >specs, and in case that still is not in some browsers, search for a
>> >polyfill that could do the job for not supported browsers for now. At
>>the
>> >end browsers will support it, and polyfill will end in no use (and we
>> >could
>> >eventually remove)
>> >
>> >2017-02-22 14:47 GMT+01:00 Peter Ent <p...@adobe.com>:
>> >
>> >> I'm going to try some experiments in my own space. Basically,
>>figuring
>> >>out
>> >> the best way to do simple layouts using CSS - vertical and horizontal
>> >>with
>> >> alignment options (center, left, right for vertical, top, middle,
>>bottom
>> >> for horizontal). Because alignment will probably require more cycles
>> >>when
>> >> implemented in SWF, I will look to making these beads or
>> >> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
>> >> percentage sizes as well. A better understanding, on my part, of
>> >>HTML/CSS
>> >> capabilities will really help.
>> >>
>> >> Once I think the JS side is simple enough, I'll mimic then for the
>>SWF
>> >> side. I really don't see why this should be complex. The big issue on
>> >>the
>> >> SWF side is not always knowing the size of the item that you want to
>> >> position and size.
>> >>
>> >> I have been reading about CSS Flexbox which seems like it is the
>>future
>> >>of
>> >> layout for HTML/CSS. It seems to be widely supported at this point.
>>The
>> >> next generation, Grid, is still in the W3C draft phase, but that
>>will be
>> >> handy too once it gets adopted. I'll look into using various
>>settings of
>> >> display and pos

Re: [FlexJS]Layout redux

[Peter Ent]

That's a good strategy. My experiments this morning look like Flexbox is
the way to go. Its widely supported now and seems pretty easy to use.

I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
them extend the current versions just so the SWF side stays the same for
right now. The JS side will implement Flexbox. Then we can all try it out
and see how it behaves. If that's good, I can replace the current JS
version with the Flexbox version and then work on the SWF side to make it
compatible.

Will keep you all posted.

—peter

On 2/22/17, 10:16 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:

>That looks very promising Peter. Look forward to see some progress :)
>If flexbox is the future, I think we should always look to go with that
>specs, and in case that still is not in some browsers, search for a
>polyfill that could do the job for not supported browsers for now. At the
>end browsers will support it, and polyfill will end in no use (and we
>could
>eventually remove)
>
>2017-02-22 14:47 GMT+01:00 Peter Ent <p...@adobe.com>:
>
>> I'm going to try some experiments in my own space. Basically, figuring
>>out
>> the best way to do simple layouts using CSS - vertical and horizontal
>>with
>> alignment options (center, left, right for vertical, top, middle, bottom
>> for horizontal). Because alignment will probably require more cycles
>>when
>> implemented in SWF, I will look to making these beads or
>> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
>> percentage sizes as well. A better understanding, on my part, of
>>HTML/CSS
>> capabilities will really help.
>>
>> Once I think the JS side is simple enough, I'll mimic then for the SWF
>> side. I really don't see why this should be complex. The big issue on
>>the
>> SWF side is not always knowing the size of the item that you want to
>> position and size.
>>
>> I have been reading about CSS Flexbox which seems like it is the future
>>of
>> layout for HTML/CSS. It seems to be widely supported at this point. The
>> next generation, Grid, is still in the W3C draft phase, but that will be
>> handy too once it gets adopted. I'll look into using various settings of
>> display and position first before resorting to Flexbox.
>>
>> —peter
>>
>> On 2/22/17, 3:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> >
>> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <aha...@adobe.com> wrote:
>> >>
>> >> It is probably time for our annual "revisiting of the layout code".
>>I
>> >> think if you look at source code history, Peter or I do this every so
>> >> often as we get more examples to work with.
>> >>
>> >> From memory, there are issues like whether we have to set
>> >> position:relative or not that came out of the MDL swc.  And when/if
>>we
>> >> need to set the width on a parent for percentage width to work in the
>> >> children/grandchildren.
>> >>
>> >> It is great to finally have some people actually paying attention
>>that
>> >> know how this stuff is actually normally done in JS.  Peter and I
>>were
>> >> mostly guessing since, if you think about it, we were basically doing
>> >>Flex
>> >> until we got into FlexJS and are not experienced in HTML/JS.
>> >>
>> >> So, fundamentally, if you have to stack things vertically, should you
>> >>use
>> >> display:block?  If you have to line up a bunch of divs horizontally,
>> >> should you use display:inline-block?
>> >
>> >It depends. If everything is position:relative, then theoretically,
>>yes.
>> >The problem with position:relative in my experience is that it’s too
>> >unpredictable. I can’t give examples right now, but I know I spent
>> >countless hours struggling with getting HTML to correctly position
>> >elements using relative positioning. So while theoretically, using CSS
>> >and built-in browser positioning sounds good, I think there are enough
>> >edge cases to make it really difficult to be reliable in practice.
>> >
>> >> Is there a better way to do BasicLayout?  We ended up using a
>>completely
>> >> handwritten set of code to essentially make everything use absolute
>> >> positioning.
>> >>
>> >> Is border-box working as expected?  Do you set the height/width to
>> >>include
>> &g

Re: [FlexJS] Spacers and positioning

[Peter Ent]

I'll be including the issues of spacing and positioning in my work with
layouts.

‹peter

On 2/21/17, 5:56 AM, "yishayw"  wrote:

>That sounds like a good idea. Let me know if I can help.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.247.n4.nabble.com/FlexJS-Spacers-and-po
>sitioning-tp59242p59706.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS] resize event not working?

[Peter Ent]

Alex will need to chime in here, but I believe his philosophy has been to
keep the number of specialized events to a minimum. I'm not 100% sure I
agree with that since it can be a lot easier to write code when you are
responding to specific events, but it does expand the final footprint of
the app having all the code for those classes.

I think FlexJS will always be a challenge between convenient and
size/performance. 


‹peter

On 2/22/17, 3:42 AM, "Harbs"  wrote:

>I think it¹s to be consistent with widthChanged and heightChanged. There
>is no ³resize² event anywhere in FlexJS. It¹s probably a good idea to not
>use the browser names for events.
>
>I do believe there should be a ResizeEvent with consts for SIZE_CHANGED,
>WIDTH_CHANGED and HEIGHT_CHANGED. This does not yet exist.
>
>> On Feb 22, 2017, at 9:20 AM, Justin Mclean 
>>wrote:
>> 
>> Hi,
>> 
>>> Looks like you¹re using a flash event instead of the flexjs one.
>> 
>> Thanks for that I tried that as well, but still doesn¹t work.
>> 
>> I can see the Resize bead is doing this:
>> window.addEventListener('resize',
>>org.apache.flex.utils.Language.closure(this.resizeHandler, this,
>>'resizeHandler'), false);
>> 
>> And dispatches a ³sizeChanged² event like so:
>> initialView.dispatchEvent('sizeChanged¹);
>> 
>> Any reason for the event name change?
>> 
>> So this code below will work. But it seems a rather roundabout way of
>>doing it.
>> 
>> 
>> http://ns.adobe.com/mxml/2009;
>>xmlns:js="library://ns.apache.org/flexjs/basic"
>>initialize="init()">
>> 
>>
>>
>>
>> 
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> Thanks,
>> Justin
>

Re: [FlexJS]Layout redux

[Peter Ent]

uld propose two sets of Layouts:
>CSSLayout which might or might not have sub-layouts to do bare-b ones
>layout optimized for as little JS code to run as possible and allow
>settings to be set using CSS. (cheap as possible PAYG layout)
>FlexLayout which would have vertical,horizontal,absolute,grid, etc.
>
>FlexLayout would use FlexJS properties to calculate layout, and support
>percentage, left,right,top,bottom properties to do proper constrained
>layout. I think that constrained layout (right,left,top,bottom) is common
>enough that it doesn’t warrant a separate layout as long as we have the
>bare-bones CSSLayout for cases that need it.
>
>> For sure, we need to the the JS side right and then worry about the SWF
>> side.  I think there are way fewer behavior issues on the SWF side to
>>deal
>> with.
>
>Agreed.
>
>Harbs
>
>> My 2 cents,
>> -Alex
>> 
>> On 2/21/17, 12:35 PM, "Peter Ent" <p...@adobe.com> wrote:
>> 
>>> I think this is generally a good approach.
>>> 
>>> I've been thinking that we have some refactoring to do which might
>>>help.
>>> For instance, Core should probably be edited to include interfaces,
>>> events, and whatever else works across all packages. HTML should
>>>probably
>>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
>>> HTML+ActionScript can use that and then use CSS to do all their
>>>layouts;
>>> HTML would not have a SWF version.
>>> 
>>> Then Basic could be SWF & JS with layouts that are light on the JS side
>>> using CSS and AS code to mimic them on the SWF side. Express would do
>>>what
>>> it is doing now and compose components by extending the Basic set and
>>> adding common beads.
>>> 
>>> I've been hung up with the JS side having stuck on the display and
>>> position values and deferring them might be the best solution.
>>> 
>>> —peter
>>> 
>>> On 2/21/17, 2:25 PM, "carlos.rov...@gmail.com on behalf of Carlos
>>>Rovira"
>>> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com>
>>> wrote:
>>> 
>>>> Hi Peter,
>>>> 
>>>> it seems HTML rely for this task heavily on CSS to the point that
>>>>almost
>>>> nothing is done in html or js code.
>>>> So maybe we are not in the right way for HTML platform and we should
>>>>make
>>>> our code be mainly CSS.
>>>> An example is here:
>>>> 
>>>> https://css-tricks.com/snippets/sass/placing-items-circle/
>>>> 
>>>> Another point is SWF. I'm not focusing in that output and even I
>>>>didn't
>>>> compile to SWF for long time, so don't know how
>>>> is looking, but for what I saw in other discussions seems that Flash
>>>> needs
>>>> to implement the old Flex architecture of
>>>> updateDisplayList to manage refresh to avoid continuous redrawing of
>>>>the
>>>> screen.
>>>> 
>>>> So my bet is that our AS3 layout components should do:
>>>> 
>>>> 1.- In JS -> add className to "some-class-layout" (for example for
>>>> circle,
>>>> if we have circle-layout, we should have a "circleLayout" css class
>>>> selector, that we could assign to out flexjs "list component"
>>>> 
>>>> 2.- in SWF -> we should stick with the way this was done in Flex4 but
>>>> implementing as a bead and with the "updateDisplayList" performance
>>>> 
>>>> What do you think?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <p...@adobe.com>:
>>>> 
>>>>> A lot of this work is mine and it seems to need to be thought through
>>>>> once
>>>>> again. The dichotomy of SWF & JS has presented problems for me in the
>>>>> past.
>>>>> 
>>>>> Maybe the layouts, for JS platform, should do as little as possible,
>>>>> replying on CSS as much as possible. Then make the SWF platform mimic
>>>>> that.
>>>>> 
>>>>> One issue that comes up for me is that we automatically set display
>>>>>and
>>>>> position for every element soon after its created. If you were to
>>>>> hand-write the HTML you probably would not do that.
>>>>> 
>>>&g

Re: [FlexJS]Layout redux

[Peter Ent]

I think this is generally a good approach.

I've been thinking that we have some refactoring to do which might help.
For instance, Core should probably be edited to include interfaces,
events, and whatever else works across all packages. HTML should probably
be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
HTML+ActionScript can use that and then use CSS to do all their layouts;
HTML would not have a SWF version.

Then Basic could be SWF & JS with layouts that are light on the JS side
using CSS and AS code to mimic them on the SWF side. Express would do what
it is doing now and compose components by extending the Basic set and
adding common beads.

I've been hung up with the JS side having stuck on the display and
position values and deferring them might be the best solution.

—peter

On 2/21/17, 2:25 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:

>Hi Peter,
>
>it seems HTML rely for this task heavily on CSS to the point that almost
>nothing is done in html or js code.
>So maybe we are not in the right way for HTML platform and we should make
>our code be mainly CSS.
>An example is here:
>
>https://css-tricks.com/snippets/sass/placing-items-circle/
>
>Another point is SWF. I'm not focusing in that output and even I didn't
>compile to SWF for long time, so don't know how
>is looking, but for what I saw in other discussions seems that Flash needs
>to implement the old Flex architecture of
>updateDisplayList to manage refresh to avoid continuous redrawing of the
>screen.
>
>So my bet is that our AS3 layout components should do:
>
>1.- In JS -> add className to "some-class-layout" (for example for circle,
>if we have circle-layout, we should have a "circleLayout" css class
>selector, that we could assign to out flexjs "list component"
>
>2.- in SWF -> we should stick with the way this was done in Flex4 but
>implementing as a bead and with the "updateDisplayList" performance
>
>What do you think?
>
>
>
>
>2017-02-21 20:10 GMT+01:00 Peter Ent <p...@adobe.com>:
>
>> A lot of this work is mine and it seems to need to be thought through
>>once
>> again. The dichotomy of SWF & JS has presented problems for me in the
>>past.
>>
>> Maybe the layouts, for JS platform, should do as little as possible,
>> replying on CSS as much as possible. Then make the SWF platform mimic
>>that.
>>
>> One issue that comes up for me is that we automatically set display and
>> position for every element soon after its created. If you were to
>> hand-write the HTML you probably would not do that.
>>
>> So perhaps FlexJS should not set these styles at all and instead let the
>> layout set them if the layout even needs to do that.
>>
>> Thoughts?
>> ‹peter
>>
>> On 2/21/17, 1:42 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> >We¹re really struggling with layout.
>> >
>> >Yishay just mentioned the fact that padding is not working, but the
>> >problems seem to go much deeper than that.
>> >
>> >1. VerticalLayout has the following code:
>> >   for (i = 0; i < n; i++)
>> >   {
>> >   var child:WrappedHTMLElement =
>> children[i];
>> >   child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> >   if (child.style.display ===
>>'none')
>> >   {
>> >   child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> >   }
>> >   else
>> >   {
>> >   // block elements don't
>> measure width correctly so set to inline
>> >for a second
>> >   child.style.display =
>> 'inline-block';
>> >   maxWidth =
>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >   child.style.display =
>> 'block';
>> >   }
>> >   child.flexjs_wrapper.
>> dispatchEvent('sizeChanged');
>> >   }
>> >
>> >There is a number of problems that