Thanks for the response, Thai! Before I get into addressing your specifics below, I've put up a proof of concept patch that modifies images create-volume to remove the need for scope:
https://review.openstack.org/#/c/345145 On 21 July 2016 at 08:23, Thai Q Tran <[email protected]> wrote: > You all sort of touched on what I am about to reiterate: > > 1. The scope was intended to be used as a way to propagate events up and > down the chain (from table controller to step controller) since there was > no real way to share information between controllers (remember that a modal > dialog launches an entirely different fragment of HTML with no relationship > to the current controller). Furthermore, we needed to use initScope to > explicitly set the scope so that $modal does not use the $rootScope (which > it does by default if scope is not set). As a side bonus, we were also able > to use events to share data between the steps. The idea behind was to *make > steps independent* *and reusable* in multiple workflows. The reality is > that the event propagation required both an $emit and a $broadcast to > actually share data between steps, this makes it much less desirable. > We can definitely still share data between steps, and my proposal makes it easier, I think: every step has access to the data captured by every other step (through $scope.stepModels) which they can $watch on or even modify. There's still a scope encompassing the wizard modal, it's just not tied back up to the table scope. As I said previously, I don't believe we should overly complicate things in the pursuit of making steps reusable, since outside of a potential re-use of metadata step (still to be proven whether that's even feasible) I believe YAGNI. > *The root of the problem is, how does my table know to update once the > form is submitted?* > The table knows through the new ActionResult mechanism (which is automatically handled by hz-resource-table and manually handled by the handler provided to hz-dynamic-table ... and even more manually handled if you don't use either of those <wink>). > 2. Going with Richards idea of a shared workflow.model idea. > *...* > To me there are two questions we should answer before we jump and do > another rewrite. > 1. How are we going to glue the various controllers together if we don't > use scope. > 2. How is data between the steps going to be shared. > I believe I've addressed these questions in my POC patch. Richard
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
