Richard, I have been thinking for some time that each step controller should be able to define the data it needs as well as manipulating it. Perhaps in the morning before you get up in Australia I could take a pass at converting that for access & security. I’ll talk it over with Sean, since there are some cross step dependencies it may complicate things a little and better understand his initialization states.
Travis From: Richard Jones <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, March 9, 2015 at 10:59 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Horizon] Rethinking the launch-instance wizard model Hi folks, Currently the launch instance model file does all the fetching of various bits of data. Combined with all of the controllers also being loaded at wizard startup, this results in some very difficult synchronisation issues*. An issue I've run into is the initialisation of the controller based on model data. Specifically, loading the "allocated" and "available" lists into the security groups transfer table. I can load a reference to the model securityGroups array as the "available" set, but since that data is generally not loaded (by some other code) when the controller is setting up, I can't also select the first group in the array as the default group in "allocated". So, I propose that the model data for a particular pane be loaded *by that pane*, so that pane can then attach a callback to run once the data is loaded, to handle situations like this (which will be common, IIUC). Or the model needs to provide promises for the pane controllers to attach callbacks to. Richard * one issue is the problem of the controllers running for the life of the wizard and not knowing when they're active (having them only be temporarily active would solve the issue of having to watch the transfer tables for changes of data - we could just read the allocated lists when the controller "exits"). __________________________________________________________________________ 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
