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.
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. 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. 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. 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. My 2 cents, -Alex On 7/13/17, 3:40 PM, "Harbs" <harbs.li...@gmail.com> wrote: >Now that Yishay and I have spent quite some time with beads, I have some >thoughts on the architecture. > >Here’s some things I’ve noticed (somewhat randomly): > >1. There’s 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’s probably good reasons for all of these, but it’s confusing. >Here’s 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 > >Especially for someone who is new to this, it’s very confusing to know >where the right place to add a bead is. > >2. It’s not immediately obvious that Beads can also be Strands. There are >quite a few cases where that’s true. The only ones I’ve noticed were View >Beads. > >3. It’s 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’s hard to follow the flow. > >4. It’s hard to know when beads are added and in what order. > >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. > >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’s many >terms for the same concept). Events have significant overhead and >indirection. Really what we need is for beads to tell the Strand “hey, I >need to know when x happens so I can react and/or change what’s >happening” and when beads do things they need to say “hey here’s what I >did/ want to do”. > >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. > >I really like the Notification architecture in PureMVC, and I think it’s >perfect for Strands and Beads. > >Without going into all the nitty gritty details, the classes have some >standard info that the “mediator” can use to find who’s 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. > >There’s 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. > >I’d like to see a couple of things with Strands and Beads. > >1. We should publish popular patterns for Strand/Bead interaction. (I’m >talking to myself as much as anyone else.) > >2. I’d 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. > >3. At the point when all “necessary” beads are added, the beads should >have some method automatically called so they can “finish” their setup if >they rely on another bead. > >4. All Strands should have a “notify” 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’s sent to know if it needs to do >something different. > >Bonus points if there’s some kind of “post process” on notifications in >case a bead needs to wait until after some other bead did their thing. >This can take the form of a “registerPostProcess” call to the bead which >is only every called once per registration. > >5. I’m likely missing some points in the lifecycle… > >This is something that I’d 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. > >Thoughts? >Harbs > >> >> On Jul 13, 2017, at 7:34 PM, Alex Harui <aha...@adobe.com.INVALID> >>wrote: >> >> 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. >> >> Maybe as more folks implement multi-bead sets we'll see patterns emerge >> and make it is simpler and faster. >> >> My 2 cents, >> -Alex >> >> On 7/13/17, 3:54 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote: >> >>> Generally speaking it feels like sometimes I need to insure the order >>>of >>> invocation. Since beads communicate with one another through events >>>it’s >>> difficult to achieve. Regarding the upload response data I understand >>> your suggestion as follows (edges contain event names): >>> >>> <Strand>--uploadRequested--<controllerForWithResponse (sends >>> request)>---complete---<ModelWithResponse (after controller wrote to >>> model>---modelChanged--<UserClassListening> >>> >>> And for the case where the user isn’t interested in the response, just >>>in >>> the status: >>> >>> >>><Strand>---uploadRequested--<controllerForWithoutResponse>---complete--- >>><M >>> odelWithoutResponse>--modelChanged--<UserClassListening> >>> >>> Is that right? >>> >>> >>> From: Alex Harui<mailto:aha...@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 >>> >>> I think I still don't understand. >>> >>> 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. >>> >>> I'm not sure what work CheckPermissions needs to do, but is totally >>>fine >>> to split its work amongst a set of beads. >>> >>> HTH, >>> -Alex >>> >>> On 7/11/17, 11:21 PM, "yishayw" <yishayj...@hotmail.com> wrote: >>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache- >>>>fl >>>> e >>>> >>>>x-development.2333347.n4.nabble.com%2FRe-git-commit-flex-asjs-refs-head >>>>s- >>>> d >>>> >>>>evelop-Add-FileUploaderWithResponseData-tp63051p63139.html&data=02%7C01 >>>>%7 >>>> C >>>> >>>>%7Cbd5414b3ced9495c188908d4c8f0f59b%7Cfa7b1b5a7b34438794aed2c178decee1% >>>>7C >>>> 0 >>>> >>>>%7C0%7C636354384624691027&sdata=BGn1g0wbTZr7ikn3uuhcIGDGPEmSVWTwIF%2Bla >>>>F6 >>>> d >>>> v8w%3D&reserved=0 >>>> Sent from the Apache Flex Development mailing list archive at >>>>Nabble.com. >>> >> >
