<div dir="ltr">Thanks for the response, Thai!<div><br></div><div>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:</div><div><br></div><div>  <a href="https://review.openstack.org/#/c/345145">https://review.openstack.org/#/c/345145</a></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 July 2016 at 08:23, Thai Q Tran <span dir="ltr"><<a href="mailto:tqtran@us.ibm.com" target="_blank">tqtran@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-family:Arial;font-size:10.5pt"><div dir="ltr">You all sort of touched on what I am about to reiterate:</div>
<div dir="ltr"> </div>
<div dir="ltr">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 <strong>make steps independent</strong> <strong>and reusable</strong> 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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-family:Arial;font-size:10.5pt">
<div dir="ltr"><strong style="font-size:10.5pt">The root of the problem is, how does my table know to update once the form is submitted?</strong></div></div></blockquote><div><br></div><div>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>).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" style="font-family:Arial;font-size:10.5pt">
<div dir="ltr"> <span style="font-size:10.5pt">2. Going with Richards idea of a shared workflow.model idea.</span></div>
<div dir="ltr"><span class=""><div><i>...</i></div></span>
<div>To me there are two questions we should answer before we jump and do another rewrite.</div>
<div>1. How are we going to glue the various controllers together if we don't use scope.</div>
<div>2. How is data between the steps going to be shared.</div></div></div></blockquote><div><br></div><div>I believe I've addressed these questions in my POC patch.</div><div><br></div><div><br></div><div>     Richard</div><div><br></div></div><br></div></div></div>