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 <[email protected]> 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" <[email protected]<mailto: > [email protected]>> > > 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:[email protected]] > > 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 <[email protected]<mailto: > [email protected]>> 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)" <[email protected]<mailto: > [email protected]>> > > 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, [email protected]<mailto:[email protected]> > 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 <[email protected]<mailto: > [email protected]>> 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" <[email protected]<mailto:[email protected] > >> > > 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<http://schemaform.io/> > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
