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-heads- >>> d >>> evelop-Add-FileUploaderWithResponseData-tp63051p63139.html&data=02%7C01%7 >>> C >>> %7Cbd5414b3ced9495c188908d4c8f0f59b%7Cfa7b1b5a7b34438794aed2c178decee1%7C >>> 0 >>> %7C0%7C636354384624691027&sdata=BGn1g0wbTZr7ikn3uuhcIGDGPEmSVWTwIF%2BlaF6 >>> d >>> v8w%3D&reserved=0 >>> Sent from the Apache Flex Development mailing list archive at Nabble.com. >> >
