Re: [openstack-dev] [horizon] Angular form framework

[Tripp, Travis S]

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 <krotsch...@gmail.com<mailto:krotsch...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 5, 2016 at 8:51 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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?

Michael

On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S 
<travis.tr...@hpe.com<mailto:travis.tr...@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.

Thanks,
Travis

From: "Borland, Matt" 
<matthew.borl...@hpe.com<mailto:matthew.borl...@hpe.com><mailto:matthew.borl...@hpe.com<mailto:matthew.borl...@hpe.com>>>

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

Matt

From: Timur Sufiev [mailto:tsuf...@mirantis.com<mailto:tsuf...@mirantis.com>]

Folks,

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 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com><mailto:tqt...@us.ibm.com<mailto:tqt...@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: 

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)" 
<rcres...@cisco.com<mailto:rcres...@cisco.com><mailto:rcres...@cisco.com<mailto:rcres...@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?

Rob

On 27 Apr 2016, at 11:44, 
tsuf...@mirantis.com<mailto:tsuf...@mirantis.com><mailto:tsuf...@mirantis.com<mailto:tsuf...@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 
<tqt...@us.ibm.com<mailto:tqt...@us.ibm.com><mailto:tqt...@us.ibm.com<mailto:tqt...@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.tr...@hpe.com<mailto:travis.tr...@hpe.com><mailto:travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>>>

Alex Tivelkov at Mirant

Re: [openstack-dev] [horizon] Angular form framework

[Michael Krotscheck]

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

Michael

On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S  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.
>
> Thanks,
> Travis
>
> From: "Borland, Matt" >
>
> That sounds great, it would be good to use something we don’t have to
> maintain.  Timur, thanks for researching that!
>
> Matt
>
> From: Timur Sufiev [mailto:tsuf...@mirantis.com]
>
> Folks,
>
> 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 > 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: 
>
> 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)" >
>
> 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?
>
> Rob
>
> On 27 Apr 2016, at 11:44, tsuf...@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 > 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"  >>
>
> 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
>
> http://schemaform.io
>
>
>
> __
> 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

[openstack-dev] [horizon] Angular form framework

[Tripp, Travis S]

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.

Thanks,
Travis

From: "Borland, Matt" >

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

Matt

From: Timur Sufiev [mailto:tsuf...@mirantis.com]

Folks,

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

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)" >

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?

Rob

On 27 Apr 2016, at 11:44, tsuf...@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 
> 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" >

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

http://schemaform.io



__
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