In Basic ContainerBase events are dispatched as children are added. The Basic Layouts listen for those events (in theory).
HTH, -Alex On 9/16/18, 4:10 PM, "Carlos Rovira" <[email protected]> wrote: Hi Alex, you said: "It sounds like an event like childrenAdded is not being dispatched by the component or not being picked up by the layout. It might be easier to debug with a non-States example first" But I don't really know what I'm looking for, can you develop more about this?, I see in View and Container we have this comment // - why was this added here? childrenAdded(); //?? Is this necessary since MXMLDataInterpreter will already have called it I tried to add childrenAdded but nothing changes, what it indicated that I'm going a bit blind with this. So I need to understand first if I'm looking for something related to "childrenAdded" (or was only named as an example in the phrase), and if so explain the connection between the container - the event - the layout. What scares me is that the first time is added, all goes ok, but the second time, is added, it's not. The difference is the instance is already created, so it seems a problem about process again all beads right? I'm done for today. thanks El lun., 17 sept. 2018 a las 0:02, Carlos Rovira (<[email protected]>) escribió: > Hi Alex, > > seems a bug in Layouts or UIBase/Container. I'll try to find it. > > this is the test case that make it fail. Add/remove/add the Card, makes > the second time the card doesn't get the proper class Names as with states. > I'll try to > > <j:Application xmlns:fx="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fns.adobe.com%2Fmxml%2F2009&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=M0p%2FTNB3Wpjq7CT%2FQ%2Fp0OqNcQg2evuGzFhTFbqiGI2E%3D&reserved=0"; > xmlns:j="library://ns.apache.org/royale/jewel" > xmlns:js="library://ns.apache.org/royale/basic" > xmlns:html="library://ns.apache.org/royale/html"> > <fx:Script> > <![CDATA[ > import org.apache.royale.jewel.Card; > > public var card:Card = new Card(); > > private function addCard():void > { > addElement(card); > } > > private function removeCard():void > { > removeElement(card); > } > ]]> > </fx:Script> > > <j:initialView> > <j:View id="view" > > <j:beads> > <j:VerticalLayout/> > </j:beads> > <j:Button text="add card" click="addCard()" /> > <j:Button text="remove card" click="removeCard()"/> > </j:View> > </j:initialView> > > </j:Application> > > El dom., 16 sept. 2018 a las 4:22, Alex Harui (<[email protected]>) > escribió: > >> Hi Carlos, >> >> That sounds like a bug in the layouts or UIBase/Containers. >> >> The non-States equivalent of this scenario should be, instead of setting >> currentState on a button, to instead call addElement/removeElement on >> loginForm and loggedInForm. >> >> It sounds like an event like childrenAdded is not being dispatched by the >> component or not being picked up by the layout. It might be easier to >> debug with a non-States example first. And if non-States works but it >> doesn't with States then we know we have to debug the specific state >> apply-ing logic. >> >> HTH, >> -Alex >> >> On 9/15/18, 8:49 AM, "Carlos Rovira" <[email protected]> wrote: >> >> Hi Alex, >> >> checking the States example, I can confirm that changing the demo to >> use >> dot notation works perfect. I mean this code: >> >> <j:Card id="loginForm" *visible="true" >> visible.loggedIn="false"*> >> ... >> </j:Card> >> >> <j:Card id="loggedInForm"* visible="false" >> visible.loggedIn="true"*> >> .... >> </j:Card> >> >> *But* using the other format: >> >> <j:Card id="loginForm"* includeIn="login"*> >> ... >> </j:Card> >> >> <j:Card id="loggedInForm"* includeIn="loggedIn"*> >> ... >> </j:Card> >> >> make the first time the html generate is: >> >> <div id="loginForm"* class="jewel card layout vertical >> gap-3x3px"*> >> >> but coming back from loggedIn we get: >> >> <div id="loginForm" *class="jewel card"*> >> >> This *layout vertical gap-3x3px* is set in the strand by >> VerticalLayout >> bead. >> >> What means for me that beads are not processed again in the process of >> states recreation. >> >> But, bonus is that something similar happens recreating PopUps (as I >> said >> with the case of the basic combobox popup) >> >> Make this sense? >> >> Thanks >> >> Carlos >> >> >> >> >> >> El sáb., 15 sept. 2018 a las 17:24, Carlos Rovira (< >> [email protected]>) >> escribió: >> >> > Hi Alex, >> > >> > El sáb., 15 sept. 2018 a las 1:00, Alex Harui >> (<[email protected]>) >> > escribió: >> > >> >> Hi Carlos, >> >> >> >> I didn't look at your example yet, but I point out that this may >> not be >> >> an issue with States. >> > >> > >> > it's possible. >> > >> > >> >> Currently the States support can only add and remove components >> and set >> >> properties on components. So my point is that any application >> developer >> >> can do the same thing in their business logic. If a Jewel >> component cannot >> >> be exactly restored from a set of properties, that is a problem to >> solve >> >> regardless of States. >> >> >> > >> > ok. >> > >> > >> >> >> >> The set of classNames should be directly mapped to one or more >> >> properties. I thought that was why you wanted the classList API, >> so that >> >> various Jewel properties could add/remove class selectors from the >> >> classList. >> >> >> > >> > The objective of a class list api is to be able to add >> > and/remove/toggle/check a class selector easily in a component. >> Don't >> > understand the sentence "The set of classNames should be directly >> mapped to >> > one or more properties". >> > >> > >> >> Maybe we should discuss a simple scenario without states. If I >> take a >> >> Jewel component or container and write some AS to change >> properties or >> >> add/remove children and then restore it back to the original and >> it doesn't >> >> look the same, what part of the Royale framework is preventing >> that from >> >> happening? >> >> >> > >> > ok, change properties is easy, but what do you mean with restore?, >> how do >> > you do that? >> > >> > Discussing this I remember that I found the same effect adding and >> > removing a PopUp, in concrete the combobox popup. >> > In Basic, the list popup in the ComboBox is created and then >> changed from >> > visible to invisible. In Jewel I had to change it to create and >> remove the >> > list each time, since only the first time the list was created with >> the >> > right class selectors. and then when made invisible, and visible >> again, the >> > list change the layout from vertical to horizontal, what means that >> class >> > selectors was changed. >> > >> > In the States problem, we had two versions of the demo, one based on >> > "indludeIn" and other based on dot state notation (visible.state1). >> I think >> > first fail and second was doing things right. >> > >> > I'll take a look to see if I find the problem. >> > >> > >> >> Thoughts? >> >> -Alex >> >> >> >> On 9/14/18, 3:29 PM, "Carlos Rovira" <[email protected]> >> wrote: >> >> >> >> Hi Alex, >> >> >> >> the issue comes from beads modifying strand className. This >> can be >> >> seen >> >> mixing states with jewel layouts. Jewel Layouts add or removes >> class >> >> names >> >> in the strand at runtime. >> >> Since, as you describe in the example, those changes are not >> part of >> >> some >> >> state (i.e: className.normal or className.someState, for >> example), the >> >> current class name is not stored anywhere, so when you change >> the >> >> state and >> >> comes back, Royale is not capable of recreate the right strand >> >> className >> >> >> >> You can see the issue in action if you compile the blog >> example about >> >> states [1] >> >> >> >> >> >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fdevelop%2Fexamples%2Fblog%2FBE0008_Using_View_States_to_show_or_hide_content&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=INXSBxWAPgbRaIoe1SH6cUjGedyKDkMhmtqVEO%2FTr5k%3D&reserved=0 >> >> >> >> Compile the example and run (online version works ok due to it >> was >> >> published when the work was in unfinished stated) >> >> >> >> Then push the button to change state from login form to result >> screen >> >> and >> >> push the button back to go to the other state. You'll see the >> layout >> >> is not >> >> equal. If check the html in the broswer, you'll find class >> names are >> >> lost >> >> between state changes. >> >> >> >> What do you think would be a good solution to this problem? >> >> >> >> thanks >> >> >> >> Carlos >> >> >> >> >> >> >> >> >> >> >> >> El vie., 14 sept. 2018 a las 18:23, Alex Harui >> >> (<[email protected]>) >> >> escribió: >> >> >> >> > Regarding class selectors and states, I guess I don't >> understand the >> >> > issue. The code behind Royale (and Flex) states should be >> >> capturing values >> >> > of properties changed by the state before they get changed, >> then >> >> restoring >> >> > those properties. IOW, if you were to have >> >> > >> >> > <js:states> >> >> > <js:state name="normal" /> >> >> > <js:state name="important" /> >> >> > <js:states> >> >> > <j:Button id="myButton" emphasis.normal="primary" >> >> > emphasis.important="emphasized" /> >> >> > >> >> > Then the myButton.emphasis="primary" at startup and when >> the state >> >> > changes to "important" the States impl should read >> >> myButton.emphasis and >> >> > store that value away before setting >> >> myButton.emphasis="emphasized". Then, >> >> > when the state changes back to "normal", the States impl >> should set >> >> > myButton.emphasis="primary" again. >> >> > >> >> > In the implementation for the emphasis property, if it >> involves >> >> changing >> >> > classLists, the implementation must do so in a way that >> handles >> >> having the >> >> > emphasis property changes at runtime. The States impl isn't >> really >> >> doing >> >> > anything application developer code might do, so the >> implementation >> >> must >> >> > support properties being set and re-set. >> >> > >> >> -- >> >> Carlos Rovira >> >> >> >> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0 >> >> >> >> >> >> >> > >> > -- >> > Carlos Rovira >> > >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0 >> > >> > >> >> -- >> Carlos Rovira >> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0 >> >> >> > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480500940&sdata=8gWdCS3xEEoApBwx%2FkqFn2pcF0JVHeeQ0VZ7Ffhmbfg%3D&reserved=0 > > -- Carlos Rovira https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C69879729a0154eff182908d61c29a111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727362480510945&sdata=ASYDwQMSRBw3MqwIek8An7u0%2F8GNUSpS0B%2B7Y2Xd%2FHk%3D&reserved=0
