TL;DR, I’ll be quite happy to get rid of the need for initScope and like exploring a common way to share model other than events.
|From: Richard Jones <r1chardj0...@gmail.com> | Date: Sunday, July 17, 2016 at 6:55 PM | I think this is a bad idea because in the angular world "factory" means singleton | (which is totally opposite to what everyone else in the programming world [and the rest] | thinks "factory" means but hey, angular gonna angular) and we'd be changing that, and | the potential for confusion would be very high. | Controllers are already not singletons - I see no reason why mutable state shouldn't be | | contained in *them*. We don't need to invent something new to hold that mutable state. As FYI, the way I mentioned for factories is *not* inventing something new and is how they were intended and even used in angular in that way. A factory is a singleton object whose job is to create instances of objects. It is even used that way in angular code. See $cacheFactory [0] [0] https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js The differentiation of .factory vs .service is still obtuse since they are both singletons, but the concept of a factory object whether .service or .factory still remains. |From: Richard Jones <r1chardj0...@gmail.com> | Date: Sunday, July 17, 2016 at 6:55 PM |Thus the controller and action service, which are quite independent pieces of code, | must have intimate knowledge of each other's internal operation. I'm not so keen on that ;-) That is yuck! |From: Richard Jones <r1chardj0...@gmail.com> | Date: Sunday, July 17, 2016 at 6:55 PM | But the workflow implementation has no concept of an over-arching model for | the workflow. If that was changed, I believe all the current $scope shenanigans |(which are basically about short-circuiting the workflow not doing its job ;-) would | go away. The event based mechanism was an attempt originally proposed by Thai to get around the essentially hard coded shared model service in launch instance where the steps are tightly bound to that model service. There was also some idea that some steps could be reusable / recomposable across work flows (such as update metadata) if you didn’t tightly bind things. |From: Richard Jones <r1chardj0...@gmail.com> | Date: Sunday, July 17, 2016 at 6:55 PM | So, here's my rough thought: workflow.model is an object with properties named for | each of the workflow steps - using the step formName as the name (hell, schema | form could probably make this a doddle). The workflow model is passed to the | controller for each step, which uses its own named model to store the data captured | by the step - and as a side effect it can poke at (and watch) the data captured by other | steps, which is often useful. Workflow $modal resolution supplies the workflow model | for the consumer of the workflow to then to something with all that data. We’ve roughly talked about a need for something like this for sometime and I think it would be great to explore it. It is similar to some of the Django workflow concepts. Effectively, this boils down to steps declaring with data they require and which data they provide. I’d prefer it if we can disassociate the step name from the data name. We want to keep the steps from being tightly coupled to each other, but rather be declarative about the data they use. For example, if we later want to split out steps (see History of Launch Instance, Chapter 1: Source and Details) or want to combine steps (See History of Launch Instance: Chapter Boy it would be nice if we could have a quick launch step as the first step), it will be easier to do if we don’t couple the model to the current presentation. By the way, yes the ability to watch the data or react to changes in the data is definitely useful. For example, in Launch Instance if you increase the number of instances, this may mean that the flavor you’ve chosen will now go over your quota (select smaller), which is a different step. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
