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="http://ns.adobe.com/mxml/2009"; 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%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992266487&sdata=T5KqlcfJnzeLhMottox6U0l3%2FyvtcywEhX6IHdxQplg%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%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0 > >> > >> > >> > > > > -- > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0 > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfc98689f0646455d73f308d61b22d9f3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636726233992276496&sdata=PjL2j0Fy8BAb4Av9Nq0u2Ju1xcLGg%2B38dD1E3fQkVXY%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
