Open Stack

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.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.
>
> Thanks,
> Travis
>
> From: "Borland, Matt" <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!
>
> Matt
>
> From: Timur Sufiev [mailto:tsufiev at 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 <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>>
>
> 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, 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>> 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
> >>
>
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160505/6b8253ff/attachment.html>