royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: States problem [was: Re: Royale Transitions, Effects, States infrastructure]
Date Mon, 17 Sep 2018 18:10:09 GMT
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 (<aharui@adobe.com.invalid>)
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" <carlosrovira@apache.org> 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
> (<aharui@adobe.com.invalid>)
>     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" <carlosrovira@apache.org>
> 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 (<
>     > carlosrovira@apache.org>)
>     >     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&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=PvO7zAzeiFSXmOksUs4T%2FmcX9B920%2BNSsqkYzFbrsoY%3D&amp;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
>     > (<aharui@adobe.com.invalid>)
>     >     > 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" <carlosrovira@apache.org
> >
>     > 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 (<
>     >     >> carlosrovira@apache.org>)
>     >     >>     escribió:
>     >     >>
>     >     >>     > Hi Alex,
>     >     >>     >
>     >     >>     > El sáb., 15 sept. 2018 a las 1:00, Alex Harui
>     >     >> (<aharui@adobe.com.invalid>)
>     >     >>     > 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" <
>     > carlosrovira@apache.org>
>     >     >> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=HdMYRGixb5jJpqGztOqu%2FiaQqK29L%2B1H8mPq2AkFYXk%3D&amp;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
>     >     >>     >> (<aharui@adobe.com.invalid>)
>     >     >>     >>     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&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>     >     >>     >>
>     >     >>     >>
>     >     >>     >>
>     >     >>     >
>     >     >>     > --
>     >     >>     > Carlos Rovira
>     >     >>     >
>     >     >>
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>     >     >>     >
>     >     >>     >
>     >     >>
>     >     >>     --
>     >     >>     Carlos Rovira
>     >     >>
>     >     >>
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>     >     >>
>     >     >>
>     >     >>
>     >     >
>     >     > --
>     >     > Carlos Rovira
>     >     >
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>     >     >
>     >     >
>     >
>     >     --
>     >     Carlos Rovira
>     >
>     >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>     >
>     >
>     >
>
>     --
>     Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C8cbf14502c2547b8422908d61c848e26%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636727752992793400&amp;sdata=3auShYSoaqu95scOoEhzyZXh4outMJY7RpcXw3AcDiQ%3D&amp;reserved=0
>
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message