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.
 
The root of the problem is, how does my table know to update once the form is submitted? Since then, a lot more work has been done in this area and I have not followed all of them (Matt and Tyr, feel free to chime in). I understand that Tyr made it so that events were no longer required, instead we can depend on promises via the result-handler function. This function gets triggered once the action is completed and would allow the table controller to do something after the action goes through. With the introduction of the generic table and registry, I am no longer certain how the data is updated in tables. If tables are notified of changes without the use of events, then the first step is to make this the standard.
 
2. Going with Richards idea of a shared workflow.model idea.
 
"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."
 
Event if we get rid of the events model completely, how are we planning on watching objects without scope? The main reason initScope existed is to act as a glue to allow sharing of data between the various controllers. This is the direct result of us using the $modal widget. While I agree that this introduces a sticky situation concerning the purity of services, I am unsure how we can resolve this.
 
I believe that the workflow should just be a list of steps. The model should instead reside in the create-volume service where it truly belongs. Each step can store a reference to the model and we are still able to poke/watch the data as Richard suggested.
 
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 agree the solution we have isnt perfect, but at some point, we have to ask, is it good enough? And if it is, is it worth the cost of a rewrite when it can potentially break plugins and external code? To be clear, I am not against it, just adding my 2c.
 
----- Original message -----
From: Richard Jones <r1chardj0...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Cc:
Subject: Re: [openstack-dev] [Horizon] Angular action services and initScope
Date: Mon, Jul 18, 2016 3:05 PM
 
On 18 July 2016 at 11:49, Rob Cresswell <robert.cressw...@outlook.com> wrote:
Maybe I'm missing the point, but the schema stuff just defines a model and passes it to the schema directive via ctrl; doesn't that remove any issues with workflows? ui-bootstraps modal and modalinstance already provides a way to pass that data back to the initial location (table etc) again
 
In a nutshell, yes this is the goal I'm aiming for, though some of the details might vary.
 
 
      Richard 
__________________________________________________________________________
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
 

__________________________________________________________________________
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

Reply via email to