Open Stack

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 <tqtran at us.ibm.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160721/b153d692/attachment.html>