Open Stack

On 18 July 2016 at 11:34, Tripp, Travis S <travis.tripp at hpe.com> wrote:

> 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 <r1chardj0n3s at 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.
>

Ah, yep, sorry for the confusion there - what I was getting at is that the
data for doing things is already handled by controllers, so let's use
those, rather than create something new to do it. My grumpiness about
"factory" was a distraction ;-)



> |From: Richard Jones <r1chardj0n3s at 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.
>

I'd like to call YAGNI here :-)



> |From: Richard Jones <r1chardj0n3s at 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.


Quite reasonable to have the data model be named more after the data being
captured in the panel than the step of the panel, yep, but...



> 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.
>

Yeah, this is especially tricky, and I think Launch Instance Quick Launch
is a special snowflake and we shouldn't necessarily make everything else
have to work around it. If we could just define pages of workflows which
have their own model (with SchemaForm models once that lands, but manually
for now) that would solve 80-90% of workflow cases while being much simpler
to implement (not needing a whole separate model definition aside the form
definition).


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.


Completely agreed.


     Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160718/a2ebffe9/attachment.html>