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. >
