Hi Alex, ok, I'll try to get again over it as I get some time and report here my findings. thanks! Carlos
El lun., 17 sept. 2018 a las 20:19, Alex Harui (<[email protected]>) escribió: > Hi Carlos, > > It simply will not scale for me to have to debug every hard problem. We > need others to increase their skills in debugging the framework. I tried > to help as much as I can. I pointed you to files like ContainerBase which > dispatches a childrenAdded event and to LayoutBase which listens for it. > It looks like your example calls addElement. Step into it, and see why it > doesn't dispatch the event, or if the event is dispatched and not picked up > by LayoutBase. Even if it would only take me 30 minutes to figure it out, > and take you longer, it doesn't matter. If we end up with more users and I > have to spend 30 minutes on all of their bugs, there is no way I will be > able to keep up. > > Thanks, > -Alex > > On 9/17/18, 11:10 AM, "Carlos Rovira" <[email protected]> wrote: > > Hi Alex, > > I'm very interested in now the essence of each part of Royale, and > trying > to use it all the things behind at maximum level. It's intrinsic to me > :) > Since most of the things were invented by you, Peter or others, I'm > trying > to get the knowledge browsing code and trying things, since most of > this > things can only be learn by experience and continuos work with the > framework. > > Begin said that, I said in other email that I trace all methods in > LayoutBase and in the layouts used in the example ( in this case > VerticalLayout). I found that removing and adding doesn't trigger any > more > calls to this methods (either by a event dispatched or by calling > expressly > a method). > > So maybe the resolution way is not ok, but to get the proper, I'll > need you > take the code I posted to test and see what's happening. I think I can > get > far from here without you revising the example and looking where the > premise you propose is failing and why. > > I think this should doesn't get you much time since the code of test is > very simple and maybe you could find something that is not set as you > suppose and by this reason I'm not getting the proper results. > > Let me know if you can take a look, If you find it, then I can > propagate > the changes you instruct over the rest of layouts. > > Thanks! > > Carlos > > > > > El lun., 17 sept. 2018 a las 18:34, Alex Harui > (<[email protected]>) > escribió: > > > Hi Carlos, > > > > I looked at your changes. I cannot understand why that would fix > your > > problem. beadsAdded gets run pretty early in the lifecycle and > shouldn't > > be a factor. I think you may be relying on a bug where beadsAdded > gets > > called every time you are added to a parent. Someday that > beadsAdded will > > check that beads have already been added and not get fired again. > > > > It is important (maybe just to me) that we try to really understand > the > > fundamentals of a framework, especially Royale, were PAYG is > important. If > > you are still unclear how containers and assignable layouts work, > then let > > us know and we'll try to explain it in more detail. The Basic > Containers > > and Layouts rely on notification events being dispatched by the > Container > > as children are added to the Container. Adding a beadsAdded handler > should > > not normally get called if the Container itself did not get added to > a > > parent. So I don't know how these changes worked unless the test > scenario > > also added and removed the Container. > > > > Fundamentally, when you call addElement, the Container's addElement > should > > be dispatching a childrenAdded from ContainerBase. I see in > LayoutBase > > that it has set up a listener for it. If that listener is not > getting > > called, figuring out why it isn't should be the first step in > proposing a > > solution. So I would recommend starting there. > > > > HTH, > > -Alex > > > > On 9/17/18, 3:01 AM, "Carlos Rovira" <[email protected]> > wrote: > > > > I put traces on LayoutBase and in VerticalLayout to see what > happens: > > > > The layout runs for a component only when it's created (all the > implied > > methods, called to strand, handle chidren added, handle init > complete > > and > > perform layout... > > then if I remove and add again no method in the layout runs > again... > > > > I get to fix it by adding a handler to "beadsAdded" in > StyledLayoutBase > > (hope others could see if this problem affects layouts that > doesn't > > modify > > strand class names). > > In this way when the component is added to parent it runs the > code to > > add > > class selectors. > > > > Let me know if you consider the resolution way right, or if it's > > better to > > deal with it in other way. > > > > Thanks > > > > > > El lun., 17 sept. 2018 a las 9:50, Alex Harui > > (<[email protected]>) > > escribió: > > > > > 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%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316726792&sdata=khDl6qSrCv9X45hccsm8lbbp5NCyz73UI4q2BPej6nk%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%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=iKrJ4hGQkP8fy8ionHbRr0Dw8wZNLDJWxwBLJylQQgY%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%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > >> >> > > > >> >> > > > >> >> > > > >> > > > > >> > -- > > > >> > Carlos Rovira > > > >> > > > > >> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > >> > > > > >> > > > > >> > > > >> -- > > > >> Carlos Rovira > > > >> > > > >> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > >> > > > >> > > > >> > > > > > > > > -- > > > > Carlos Rovira > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5ff016831e14fff179e08d61cc8da46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636728046316736801&sdata=KhzgoR89hU7lBU4arvQZHD3dKz%2FARFYhGkKCHY53WIo%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
