From: Steve Baker <sba...@redhat.com<mailto:sba...@redhat.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, November 26, 2013 4:29 PM To: "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [heat][horizon]Heat UI related requirements & roadmap
On 11/27/2013 11:02 AM, Christopher Armstrong wrote: On Tue, Nov 26, 2013 at 3:24 PM, Tim Schnell <tim.schn...@rackspace.com<mailto:tim.schn...@rackspace.com>> wrote: Use Case #3 Grouping parameters would help the client make smarter decisions about how to display the parameters for input to the end-user. This is so that all parameters related to some database resource can be intelligently grouped together. In addition to grouping these parameters together, there should be a method to ensuring that the order within the group of parameters can be explicitly stated. This way, the client can return a group of database parameters and the template author can indicate that the database instance name should be first, then the username, then the password, instead of that group being returned in a random order. Parameters: db_name: group: db order: 0 db_username: group: db order: 1 db_password: group: db order: 2 web_node_name: group: web_node order: 0 keypair: group: web_node order: 1 Have you considered just rendering them in the order that they appear in the template? I realize it's not the name (since you don't have any group names that you could use as a title for "boxes" around groups of parameters), but it might be a good enough compromise. If you think it's absolutely mandatory to be able to group them in named groups, then I would actually propose a prettier syntax: ParameterGroups: db: name: ... username: ... password: ... web_node: name: ... keypair: ... The ordering would be based on the ordering that they appear within the template, and you wouldn't have to repeat yourself naming the group for each parameter. Thanks very much for writing up these use cases! Good point, I'd like to revise my previous parameter-groups example: parameter-groups: - name: db description: Database configuration options parameters: [db_name, db_username, db_password] - name: web_node description: Web server configuration parameters: [web_node_name, keypair] parameters: # as above, but without requiring any order or group attributes Here, parameter-groups is a list which implies the order, and parameters are specified in the group as a list, so we get the order from that too. This means a new parameter-groups section which contains anything required to build a good parameters form, and no modifications required to the parameters section at all. +1 This structure gives me all of the information that I would need for organizing the parameters on the screen in an exact way. Thanks, Tim
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
