Hi Carlos, I didn't look at your example yet, but I point out that this may not be an issue with States. 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.
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. 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? 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%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=NaIJmC4%2Bbhr3Ysba%2BOxsjFnmliemEWq6nHGIDkzoxwc%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%7C2592599a6d224d94342b08d61a917fea%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636725609577539201&sdata=bHjSWhNbYwkhNfQbX2Q%2BQDUQWTtVXNozSTe6eHyX61Y%3D&reserved=0
