Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Bead Lifecycle (was Re: git commit: [flex-asjs] [refs/heads/develop] - Add FileUploaderWithResponseData)
From: Harbs <harbs.lists@gmail.com>
In-Reply-To: <D58D48D8.99255%aharui@adobe.com>
Date: Fri, 14 Jul 2017 03:38:31 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <64A57A48-9B14-4592-AED5-3049D5A32AB5@gmail.com>
References: <CAP37iKE6Ae-XYJxY=KxTk5X-kARbvGHiP1=y4om=fabiuA8c+g@mail.gmail.com> <MWHPR12MB1279AB51E5B06C73F221484BC8A90@MWHPR12MB1279.namprd12.prod.outlook.com> <1499825023212-63131.post@n4.nabble.com> <D58B0415.9895F%aharui@adobe.com> <1499837322605-63136.post@n4.nabble.com> <D58B0838.98988%aharui@adobe.com> <1499840517683-63139.post@n4.nabble.com> <D58B138D.989E2%aharui@adobe.com> <BN6PR12MB12682CE1E0E25D62B3300CD0C8AF0@BN6PR12MB1268.namprd12.prod.outlook.com> <D58CEE3D.9916A%aharui@adobe.com> <7FC767AE-37C7-4727-A53E-50179BE29F6B@gmail.com> <D58D48D8.99255%aharui@adobe.com>
To: dev@flex.apache.org
archived-at: Fri, 14 Jul 2017 00:38:42 -0000

1. I think so, or at most, only slightly. We=E2=80=99d probably save =
some code by not adding lots of functions for events and the like. I =
feel like the event system in general is bloated more than it needs to =
be.
2. I think there=E2=80=99s probably some and some. There=E2=80=99s =
probably going to be some lazy beads, and that=E2=80=99s ok. The way I =
see it is that there are two kinds of beads. There=E2=80=99s required =
ones which are not lazy and then there=E2=80=99s possibly-required, lazy =
ones. Lazy ones by definition will not need to listen for every =
notification. As long as there=E2=80=99s structure for the required =
ones, it=E2=80=99s good.
3. I think it=E2=80=99s okay to require certain classes of beads to be =
loaded in a certain order (i.e. controllers and views), as long as it =
doesn=E2=80=99t lead to pitfall bugs, but there=E2=80=99s probably =
others where requiring the order makes things difficult.

Totally agree about the compiler bit.

I generally think better by doing rather than writing.

What I might do when I have some spare time is to do some experiments on =
a branch and see what happens. I have no problem if my experiments turn =
out to be pointless. Either way, it should be educational. I think it =
would give a concrete point of reference.

Harbs

> On Jul 14, 2017, at 2:48 AM, Alex Harui <aharui@adobe.com.INVALID> =
wrote:
>=20
> These are good points.  I'm glad I sent my PAYG email earlier today.  =
I'm
> not sure I understood points #3 (dependencies) and #5 =
(cross-referencing)
> so apologies if my thoughts below didn't take them into account.
>=20
> I'd say that some of these ideas simply need to be tried and measured
> against the PAYG metrics I proposed.  For example:
> 1) Can we implement a second, lighterweight notification system =
without
> increasing download size?  Besides mediators I think there is another
> mechanism called AS3Signals.
> 2) Can we have more consistency in when beads get instantiated or will
> that cause too many beads to be instantiated "just-in-case"?  It may =
just
> be that "just-in-time" or "lazy" instantiation of beads is going to =
make
> it hard to know when a bead will be added to the strand, but I think
> "just-in-time" instantiation is always going to provide best =
performance.
> Too much consistency sometimes results in too much just-in-case code.
> 3) Is it better to require certain beads to be placed on the strand =
before
> other beads?  Does doing so make the code smaller or faster?  Will it =
be
> more painful for developers to get the order right?  It might be best =
just
> to find the best patterns for waiting for your partner beads.  One =
thing
> to consider is that we have more control over when beads get added in
> MXML, but we probably shouldn't have control over when beads get added =
in
> AS.  I don't think the compiler can or should detect when the =
application
> developer is going to add a bead and tell them not to do it.
>=20
> There are probably at least two different "lifecycles".  Any =
individual
> bead's lifecycle should be pretty simple: Instantiation, Initial
> Properties, Add To Strand, Listen for Events/Notifications/Property
> Changes.  Depending on how we decide #3 above, some beads may have a =
"wait
> for my partner bead" phase.
> A UI Component has a lifecycle of: Instantiation, Initial Properties, =
Add
> To Parent, Add Beads.  But model beads may be instantiated and added =
on
> demand in Initial Properties.  In "Add Beads" the model is added first =
if
> not already added, then the view, then everything else.  In theory, =
the
> "beadsAdded" event can be used by beads to know when significant =
changes
> to the set of beads has occurred and that can be used to finish =
setting up
> if you are waiting for partner beads, but otherwise, I think you can =
count
> on model being instantiated on-demand and finish up in your strand =
setter.
>=20
> The idea I liked the least was the notion that the Strand was some
> intermediary and beads talk to the Strand, tell the Strand what their
> interest are and things like that.  In my view the strand is just a =
bus
> like you mentioned and isn't involved in any communications.  The =
beads
> simply use the bus to find each other and find the most PAYG way of
> communicating. =20
>=20
> Have you found common/popular patterns?  I don't really know because =
I've
> been spending most of my time in the compiler.  If you have, then yes,
> please document them.
>=20
> My 2 cents,
> -Alex
>=20
> On 7/13/17, 3:40 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>=20
>> Now that Yishay and I have spent quite some time with beads, I have =
some
>> thoughts on the architecture.
>>=20
>> Here=E2=80=99s some things I=E2=80=99ve noticed (somewhat randomly):
>>=20
>> 1. There=E2=80=99s no clear place to add beads to components in AS. =
It seems like
>> the catch-all place to do so is in addedToParent(), but many =
components
>> add beads at other places. Many of these are lazy initialization and =
the
>> like. There=E2=80=99s probably good reasons for all of these, but =
it=E2=80=99s confusing.
>> Here=E2=80=99s a list of places where addBead() is called in Basic:
>> start
>> initHandler
>> finishSetup
>> set states
>> get/set model
>> get/set view
>> get measurementBead
>> setCursor
>> get accordionCollapseBead
>> get layout
>> set strand
>> createViewport
>> createLists
>> displayBackgroundAndBorder
>> setupForBorder
>> handleMessageChange
>> get presentationModel
>> constructor
>>=20
>> Especially for someone who is new to this, it=E2=80=99s very =
confusing to know
>> where the right place to add a bead is.
>>=20
>> 2. It=E2=80=99s not immediately obvious that Beads can also be =
Strands. There are
>> quite a few cases where that=E2=80=99s true. The only ones I=E2=80=99ve=
 noticed were View
>> Beads.
>>=20
>> 3. It=E2=80=99s hard to follow which beads have which dependencies. =
There are
>> event listeners added at seemingly random places and events =
dispatched
>> seemingly randomly as well. It=E2=80=99s hard to follow the flow.
>>=20
>> 4. It=E2=80=99s hard to know when beads are added and in what order.
>>=20
>> 5. Even if you know what other beads and events your bead relies on, =
you
>> need to cross-reference to know what exact events are being =
dispatched.
>>=20
>> 6. The use of events is probably overkill for the needs of stands and
>> beads. Strands are effectively a command bus for the beads (there=E2=80=
=99s many
>> terms for the same concept). Events have significant overhead and
>> indirection. Really what we need is for beads to tell the Strand =
=E2=80=9Chey, I
>> need to know when x happens so I can react and/or change what=E2=80=99s=

>> happening=E2=80=9D and when beads do things they need to say =E2=80=9Ch=
ey here=E2=80=99s what I
>> did/ want to do=E2=80=9D.
>>=20
>> 7. Beads have no way of knowing when they can finish setting up. The =
only
>> way to do so is attach event listeners which is a bit awkward.
>>=20
>> I really like the Notification architecture in PureMVC, and I think =
it=E2=80=99s
>> perfect for Strands and Beads.
>>=20
>> Without going into all the nitty gritty details, the classes have =
some
>> standard info that the =E2=80=9Cmediator=E2=80=9D can use to find =
who=E2=80=99s interested in
>> what. The classes which need to react to specific notifications (i.e.
>> Mediators) list their interests and they are directly notified when
>> something that interests them happened.
>>=20
>> There=E2=80=99s also a clear lifecycle where functions can be called =
at
>> predetermined times. Notification is done by using a Notification =
object
>> which has three properties: name, type and body. Subscription to =
events
>> happens through their names, but Notifications of the same name can
>> modify their behavior by their type. body is an Object and can =
contain
>> any kind of payload.
>>=20
>> I=E2=80=99d like to see a couple of things with Strands and Beads.
>>=20
>> 1. We should publish popular patterns for Strand/Bead interaction. =
(I=E2=80=99m
>> talking to myself as much as anyone else.)
>>=20
>> 2. I=E2=80=99d like to have a clearly documented lifecycle for beads. =
There are
>> some standard bead types such as Model, Controller, View, Content =
View.
>> When should each of these be created and how? At critical points in =
this
>> cycle, things should happen automatically: The strand should pull =
from
>> each bead which is added what interests it has.
>>=20
>> 3. At the point when all =E2=80=9Cnecessary=E2=80=9D beads are added, =
the beads should
>> have some method automatically called so they can =E2=80=9Cfinish=E2=80=
=9D their setup if
>> they rely on another bead.
>>=20
>> 4. All Strands should have a =E2=80=9Cnotify=E2=80=9D method that =
beads can call to let
>> the strand know to let the appropriate beads know about an event. The
>> beads should send a notification with the necessary payload if one is
>> needed. Other beads can modify this payload and/or change the
>> notification type if necessary. The publisher of the notification can
>> examine the notification after it=E2=80=99s sent to know if it needs =
to do
>> something different.
>>=20
>> Bonus points if there=E2=80=99s some kind of =E2=80=9Cpost process=E2=80=
=9D on notifications in
>> case a bead needs to wait until after some other bead did their =
thing.
>> This can take the form of a =E2=80=9CregisterPostProcess=E2=80=9D =
call to the bead which
>> is only every called once per registration.
>>=20
>> 5. I=E2=80=99m likely missing some points in the lifecycle=E2=80=A6
>>=20
>> This is something that I=E2=80=99d work on if others think this makes =
any kind of
>> sense. While a lot of this is not very different from how events are
>> working today, it feels to me like it would help give the strand/bead
>> relationships a lot more structure.
>>=20
>> Thoughts?
>> Harbs
>>=20
>>>=20
>>> On Jul 13, 2017, at 7:34 PM, Alex Harui <aharui@adobe.com.INVALID>
>>> wrote:
>>>=20
>>> Yes, that's how I think of it.  You are right that getting one bead =
in a
>>> multi bead set to listen to other beads is tricky.  UIBase defines a
>>> particular order of model first, then view, then controller.  But
>>> otherwise, you either have to dictate your own order or find another
>>> event
>>> to listen to that will give a bead another chance to search the =
strand
>>> for
>>> other beads to listen to.  There is a "beadsAdded" event that can be
>>> used.
>>>=20
>>> Maybe as more folks implement multi-bead sets we'll see patterns =
emerge
>>> and make it is simpler and faster.
>>>=20
>>> My 2 cents,
>>> -Alex
>>>=20
>>> On 7/13/17, 3:54 AM, "Yishay Weiss" <yishayjobs@hotmail.com> wrote:
>>>=20
>>>> Generally speaking it feels like sometimes I need to insure the =
order
>>>> of
>>>> invocation. Since beads communicate with one another through events
>>>> it=E2=80=99s
>>>> difficult to achieve. Regarding the upload response data I =
understand
>>>> your suggestion as follows (edges contain event names):
>>>>=20
>>>> <Strand>--uploadRequested--<controllerForWithResponse (sends
>>>> request)>---complete---<ModelWithResponse (after controller wrote =
to
>>>> model>---modelChanged--<UserClassListening>
>>>>=20
>>>> And for the case where the user isn=E2=80=99t interested in the =
response, just
>>>> in
>>>> the status:
>>>>=20
>>>>=20
>>>> =
<Strand>---uploadRequested--<controllerForWithoutResponse>---complete---
>>>> <M
>>>> odelWithoutResponse>--modelChanged--<UserClassListening>
>>>>=20
>>>> Is that right?
>>>>=20
>>>>=20
>>>> From: Alex Harui<mailto:aharui@adobe.com.INVALID>
>>>> Sent: Wednesday, July 12, 2017 9:58 AM
>>>> To: dev@flex.apache.org<mailto:dev@flex.apache.org>
>>>> Subject: Re: git commit: [flex-asjs] [refs/heads/develop] - Add
>>>> FileUploaderWithResponseData
>>>>=20
>>>> I think I still don't understand.
>>>>=20
>>>> It is ok for beads to require other beads.  If a ResponseData bead
>>>> requires a model with a slot for responseData and a controller that
>>>> knows
>>>> to record that data, that's how you are supposed to "re-compose"
>>>> components.  There doesn't have to be one model or controller per
>>>> component.  The strand is a gathering place for small pieces to =
work
>>>> together.
>>>>=20
>>>> I'm not sure what work CheckPermissions needs to do, but is totally
>>>> fine
>>>> to split its work amongst a set of beads.
>>>>=20
>>>> HTH,
>>>> -Alex
>>>>=20
>>>> On 7/11/17, 11:21 PM, "yishayw" <yishayjobs@hotmail.com> wrote:
>>>>=20
>>>>> Ideally we wouldn't have to record data that's never read. This =
may
>>>>> be an
>>>>> extreme case, but some users will want to know the response on an
>>>>> upload,
>>>>> while some will just want to make sure the status is ok. I'd =
rather
>>>>> not
>>>>> anticipate too many use cases when writing the strand and the =
model
>>>>> because
>>>>> I might end up with code that's never used. If the bead was
>>>>> responsible
>>>>> for
>>>>> both recording the response and exposing it to the user, we =
wouldn't
>>>>> have
>>>>> to
>>>>> do that.
>>>>>=20
>>>>> Perhaps a better example is permissions. I already have an Upload
>>>>> bead.
>>>>> Now
>>>>> I want an alert to pop up if the user is not permitted to upload. =
I'd
>>>>> like
>>>>> to be able to add a 'CheckPemissionsOnUpload' bead. Right now I =
don't
>>>>> see
>>>>> how to do that, instead I would probably have to replace =
'UploadBead'
>>>>> with
>>>>> 'UploadButCheckPermissionsBead'. This takes us away from =
composition
>>>>> and
>>>>> forces inheritance.
>>>>>=20
>>>>> Maybe we don't need to modify class definitions. I think it's =
enough
>>>>> to
>>>>> modify the bead instance. In JS we could simply replace the =
function,
>>>>> and
>>>>> in
>>>>> flash we could maybe replace the whole original bead with a
>>>>> flash.utils.Proxy. But this will make things a bit complicated to =
read
>>>>> and
>>>>> maintain.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> View this message in context:
>>>>>=20
>>>>> =
https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fapache-
>>>>> fl
>>>>> e
>>>>>=20
>>>>> =
x-development.2333347.n4.nabble.com%2FRe-git-commit-flex-asjs-refs-head
>>>>> s-
>>>>> d
>>>>>=20
>>>>> =
evelop-Add-FileUploaderWithResponseData-tp63051p63139.html&data=3D02%7C01
>>>>> %7
>>>>> C
>>>>>=20
>>>>> =
%7Cbd5414b3ced9495c188908d4c8f0f59b%7Cfa7b1b5a7b34438794aed2c178decee1%
>>>>> 7C
>>>>> 0
>>>>>=20
>>>>> =
%7C0%7C636354384624691027&sdata=3DBGn1g0wbTZr7ikn3uuhcIGDGPEmSVWTwIF%2Bla
>>>>> F6
>>>>> d
>>>>> v8w%3D&reserved=3D0
>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>> Nabble.com.
>>>>=20
>>>=20
>>=20
>=20