[openstack-dev] [horizon] Angular form framework

Tripp, Travis S travis.tripp at hpe.com
Fri May 6 18:25:24 UTC 2016

Yes, it is angular specific. If there is something that can work across all frameworks, then that would be good to know.

From: Michael Krotscheck <krotscheck at gmail.com<mailto:krotscheck at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 5, 2016 at 8:51 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] Angular form framework

This feels like a thing for AngularJS projects only, yes? What about projects like Fuel that use React?


On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S <travis.tripp at hpe.com<mailto:travis.tripp at hpe.com>> wrote:
Hello everybody,

I sent a message about this direclty to a couple of people for their quick thoughts. It looks like there is enough interest that I should have just sent it to the whole ML from the start. I’d like to keep folks in the loop, so, I’m copying it all below with all of the responses To date.


From: "Borland, Matt" <matthew.borland at hpe.com<mailto:matthew.borland at hpe.com><mailto:matthew.borland at hpe.com<mailto:matthew.borland at hpe.com>>>

That sounds great, it would be good to use something we don’t have to maintain.  Timur, thanks for researching that!


From: Timur Sufiev [mailto:tsufiev at mirantis.com<mailto:tsufiev at mirantis.com>]


I was going to research this library as the possible prerequisite to angularization murano-dashboard 'dynamic ui' feature. So i'm planning to start next week looking into it.

On Mon, 2 May 2016 at 20:21, Thai Q Tran <tqtran at us.ibm.com<mailto:tqtran at us.ibm.com><mailto:tqtran at us.ibm.com<mailto:tqtran at us.ibm.com>>> wrote:
I think that it will remove a lot of boilerplate HTML, and is much more extensible than the current way of creating forms. But we may need to extend the directive to do more things.

The options they provide does not cover the 2 cases that I brought up. hz-password and hz-if-* are both directives.
For example: <input hz-if-policy="some_rules">

This says that if some_rules passes, then show this input, otherwise, hide it. Essentially, what we need is the ability to inject additional attrs into each form field so that we can include our own directives. If we can somehow extend ngSchemaForm to support this, it should work.

Alternately, we can do the policy check in javascript instead. It just means we have to use the services directly rather than their directive counterparts (most of the directives we have are backed by a service, i.e. hz-if-policy uses the policy service). It's less nice but should also work.

Ultimately, I think going this direction is right, as the extensible benefits outweighs the declarative readability. There is still a separation of concerns, the forms can be declare like how we declare actions today (in a service that we can extend).

----- Original message -----
From: "Rob Cresswell (rcresswe)" <rcresswe at cisco.com<mailto:rcresswe at cisco.com><mailto:rcresswe at cisco.com<mailto:rcresswe at cisco.com>>>

I’m a pretty big fan of this idea, I’ve mentioned it at basically every meet up we’ve had. Building up content like this is a great way of preventing duplication.

Thai, the forms can take specific conditions to control their display: https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options as well as custom form fields, so it looks like that solves both of your issues?


On 27 Apr 2016, at 11:44, tsufiev at mirantis.com<mailto:tsufiev at mirantis.com><mailto:tsufiev at mirantis.com<mailto:tsufiev at mirantis.com>> wrote:

I recall mentioning model-directed generation of forms layout (since they are pretty verbose) at Hillsboro midcycle, the response was that 'mixing logic/model and presentation is not the best pattern'.

On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran <tqtran at us.ibm.com<mailto:tqtran at us.ibm.com><mailto:tqtran at us.ibm.com<mailto:tqtran at us.ibm.com>>> wrote:
Looks interesting, but I'm not too sure it will work for all cases. I can think of a few cases where this might not work.

Case 1. We have custom directives that modify existing input forms such as hz-password. Not sure how we will be able to incorporate it if we use an auto-generated form.

Case 2. We have things like hz-if that we may use to control which form fields to show. Again, not sure how this will work if we are auto-generating the form. I suppose you would have to do the check in the controller and modify the JSON to reflect this. But that will make it less declarative.

----- Original message -----
From: "Tripp, Travis S" <travis.tripp at hpe.com<mailto:travis.tripp at hpe.com><mailto:travis.tripp at hpe.com<mailto:travis.tripp at hpe.com>>>

Alex Tivelkov at Mirantis mentioned this to me.  Has anybody looked at this to see if it is something we might want to incorporate. He said it allows using JSON schema definitions to generate forms.  As FYI, the Metadata Definitions in Glance are in JSON schema format and many of the services actually provide JSON schema of their fields.
ar form framework


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>

More information about the OpenStack-dev mailing list