ciena-frost / ember-frost-bunsen Goto Github PK

We need to figure out the desired behavior when given the following model:

{
  "properties": {
    "foo": {
      "items": {
        "properties": {
          "bar": {
            "type": "string"
          }
        },
        "type": "object"
      },
      "type": "array"
    }
  },
  "type": "object"
}

paired with the following views:

View 1

{
  "cells": [
    {
      "model": "foo.0"
    }
  ],
  "type": "form",
  "version": "2.0"
}

Currently renders nothing.

Model

{
  "properties": {
    "foo": {
      "properties": {
        "bar": {
          "type": "string"
        },
        "baz": {
          "type": "string"
        }
      },
      "type": "object"
    }
  },
  "type": "object"
}

View

{
  "cells": [
    {
      "model": "foo"
    }
  ],
  "type": "form",
  "version": "2.0"
}

Value

{
  "foo": {
    "bar": "test",
    "baz": "test2"
  }
}

Currently renders nothing.

I'd expect this to actually render the inputs for all sub-properties of foo since children isn't present.

It's not the best practice to have our template files in app/, so let's move them to a more appropriate place in addon/

It appears to work in the demo until you select something and an error message appears.

Seems that you must put type: 'string' in the model. But the resulting value is an array. type: 'array' in the model causes an internal failure.

Furthermore, you cannot set the initial value.

the demo documentation page for frost-bunsen-form is missing disabled property: http://ciena-frost.github.io/ember-frost-bunsen/#/form

I will like to be able to set the default selection index on a select input.

It's a common use case to select the first element of the list as the default when you use select input and populate those with dynamic data.

Having implemented the new select renderer in Bunsen, it's clear there are two advanced features that would be really nice:

1. A label format feature that allows the schema author to compose a label, consisting of the following going into the view spec:

'labelFormat': '${someAttr} - ${someOtherAttr}'

This would accommodate the networkFunction (session) use case currently in Forch.

1. An advanced filter treatment feature:

'filter': {
  'client': true //override to client-side filtering, useful for APIs that don't a
  'attribute': 'someAttrName' // the property to filter on
}

This would accommodate the node drop-down use case in Forch, where the filtering is done on a deep property, not supported by the orchestrate API, and would support the resource-provider drop-down in the Domain create screen, where the API does not support p or q filtering.

If you update the country for the groom's address it ends up effecting both the groom and bride's addresses. Issue may have something to do with $ref's not sure.

Propagate the demo Model/View selections into a URL so when we are trying to show others examples, its easy to share a link rather than telling them which options to try out

The following should be valid in view JSON but currently only containers specified in the containers array can have the collapsible property defined.

{
  "collapsible": true,
  "item": {
    "container": "person"
  },
  "model": "people"
}

There is a bug in the demo that causes an error to display when any item is checked. It is probably wrong to put type: 'string' in the model.

It would be nice to get more of an explanation about what value you get in the bunsen form value and what you pass in to have some items selected initially. Also, is it possible to have a display name and internal value for each enum entry? In frost-core you can see that multi-select supports this.

There are fields set up to allow for submit and cancel buttons. But this feature is not implemented. Seems that it was left in a half-done state after the last framework conversion. Most of the infrastructure is there but there are some typos in the templates. The buttons in the form template should also use frost-button.

We should rename the following attributes so they don't sound like Ember/Ember Data properties and reduce confusion.

• model should be renamed to bunsenModel
• store should be renamed to bunsenStore
• view should be renamed to bunsenView

MCP example - The enum used for select in a bunsen form is ['SSH', 'Telnet'], however the display shows 'Ssh'. It should display 'SSH' instead.
See https://github.com/ciena-frost/ember-frost-bunsen/blob/master/addon/list-utils.js#L40

Not sure how difficult this one will be with the added complexity up attached files for upload.

The consumer should be able to use 'frost-form' instead of 'frost-bunsen-form' for example.

for example, on-change instead of onChange

Our demo app should document what a view is and to construct one.

It would be super-useful to include a blueprint that generates a new custom-renderer along with setting up the integration test so that the component receives what it will receive when a part of a bunsen form or detail component.

Model

{
  "properties": {
    "foo": {
      "properties": {
        "bar": {
          "properties": {
            "spam": {
              "type": "string"
            }
          },
          "type": "object"
        },
        "baz": {
          "type": "string"
        }
      },
        "required": ["baz"],
      "type": "object"
    }
  },
  "type": "object"
}

View

{
  "cells": [
    {
      "children": [
        {
          "model": "bar.spam"
        }
      ],
      "label": "Foo",
      "model": "foo"
    }
  ],
  "type": "form",
  "version": "2.0"
}

Currently the Required text shows up under the label Foo because foo.baz is required even though we aren't rendering an input for baz.

Instead of blindly using the model attribute we should determine if any of the children are required when deciding whether or not a parent cell is required.

We should get rid of the not-inline CSS and make the inline CSS the default case without having a property for switching between two classes.

open a dialog and the first input gets focus. when you dismiss the dialog, via cancel button, that triggers the validation because the Input loses focus, which then shows the error message for a fraction of a second before the dialog transitions out. It should not show the validation error if the dialog is being cancelled. Maybe bunsen should accept some kind of flag from the app, indicating that the dialog is being cancelled so don't run the validations.

When a property is an identifier for another model leverage select properties in model to lookup associated item and display user friendly text (label, title, etc).

An idea @gknoy and I came up with is to revamp the examples page to have filters that can be applied to find an example for whatever it is you are trying to do. For example we might present a multi-select filter for choosing a set of renderers that must be included in the example we desire. This would mean adding a bunch more information to the Ember Data models and Mirage mocks as well as updating the examples UI to present the filters. I'm sure we can come up with more meaningful filters beyond types of renderers as well.

I have a form with some text boxes. Previously (6.6.1) the value passed to the onChange handler would have a key for every field in the form with an empty string for empty text inputs. In 6.6.5 those fields are completely missing from the formValue. This change is not documented. Is it intentional?

As pointed out by mstaffor in Slack:

quick question. for the example of the Model Array with Defaults, is there a reason that the first superhero added does not get supplied with the defaults, but the additional ones do ?

That is certainly a bug.

The form value given to the validator is one step two old. For example that value might be missing the last character typed in a text input.

Problem happened on upgrading from 4.1.14 to 5.0.3. It seems to not happen in 5.0.1 but those versions have other issues.

A dialog launch seems to cause the onBlur to trigger which triggers validation before the user has had a chance to actually fill in any field.

Could add a property to bunsen where the user can specify whether bunsen should autofocus or leave it to the consumer.

The following model and view causes a double label to appear in bunsen 7.1.0.

Model:

{
  "properties": {
    "foo": {
      "properties": {
        "bar": {
          "type": "string"
        }
      },
      "type": "object"
    }
  },
  "type": "object"
}

View:

{
  "cellDefinitions": {
    "main": {
      "label": "Test",
      "children": [
        {
          "model": "bar"
        }
      ]
    }
  },
  "cells": [
    {
      "children": [
        {
          "extends": "main",
          "model": "foo"
        }
      ]
    }
  ],
  "type": "form",
  "version": "2.0"
}

If consumer has z-schema in their bower dependencies throw a deprecation warning that they should probably remove it.

The text/label for a checkbox should be to the right of the checkbox, not the left.

I have a select input or a button-group that has a default value that should trigger a condition to show another input and it's not working.

I have the following code:

type: 'object',
      properties: {
        resolvedCosMapping: {
          type: 'string',
          default: 'fixed',
          enum: ['fixed', 'device default']
        },
        untaggedFrames: {
          type: 'boolean',
          default: true
        },
        untaggedVlan: {
          type: 'number',
          default: 10,
          minimum: 1,
          maximum: 4095,
          conditions: [
            {
              if: [
                {
                  untaggedFrames: {
                    equals: true
                  }
                }
              ]
            }
          ]
        },
        ...
    }

Should

Ever since consuming 4.x bunsen, I've been getting the following type of DEPRECATION warnings (lots of them):

DEPRECATION: You modified (mut errors) twice in a single render. This was unreliable in Ember 1.x and will be removed in Ember 3.0 [deprecation id: ember-views.render-double-modify]
        at HANDLERS.(anonymous function) (http://localhost:4200/automation/assets/vendor.js:15791:7)
        at raiseOnDeprecation (http://localhost:4200/automation/assets/vendor.js:15699:12)
        at HANDLERS.(anonymous function) (http://localhost:4200/automation/assets/vendor.js:15791:7)
        at invoke (http://localhost:4200/automation/assets/vendor.js:15807:7)
        at deprecate (http://localhost:4200/automation/assets/vendor.js:15760:32)
        at Object.deprecate (http://localhost:4200/automation/assets/vendor.js:25799:37)
        at exports.default._emberMetalMixin.Mixin.create._Mixin$create.scheduleRevalidate (http://localhost:4200/automation/assets/vendor.js:53062:26)
        at http://localhost:4200/automation/assets/vendor.js:23312:32
        at Object.BasicStream.notifySubscribers (http://localhost:4200/automation/assets/vendor.js:31712:11)

The what that was modified seems to be more than just mut errors it has also been:

• mut value
• mut errorMessage
• mut renderValue

On a large, rather complex bunsen form, I get > 400 of these messages when it renders (with some default values), this makes finding any other messages in the midst of all that quite difficult. Not to mention the fact that bunsen appears to be doing something that is unreliable and will be removed :(

If I have a component that can be consumed via {{foo-bar …}} then I want to be able to specify "renderer": "foo-bar" without having to specify the renderer in the mapping passed into the renderers property of the detail/form component.

Add a new password renderer and update the text renderer to provide deprecation warnings when using it to generate password inputs.

I noticed bunsen repeating the 2nd layer of titles once I had hit three levels of nesting.

Int he following example, only one "Foo" is expected:

The example's model and view:
Bunsen Model:

{
    "type": "object",
    "properties": {
      "nested": {
       "type": "object",
        "properties": {
          "foo": {
            "type": "object",
            "properties": {
              "foosValue": {
                "type": "string"
              }
            }
          }
        }
      }
    }
  }

Bunsen View:
Note: cellDefinitions was needed, otherwise the view failed to work.

{
    "type": "form",
    "version": "2.0",
    "cellDefinitions": {
    },
    "cells": [
      {
        "children": [
          {
            "label": "Main",
            "model": "nested",
            "children": [
              {
                "label": "Foo",
                "model": "foo",
                "children": [
                  {
                    "label": "value",
                    "model": "foosValue"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }

Workaround is to attempt to skip a layer of nesting by directly referencing the parent in the child:

{
    "type": "form",
    "version": "2.0",
    "cellDefinitions": {
    },
    "cells": [
      {
        "children": [
          {
            "label": "Main",
           // skip setting "model": "nested" here.
            "children": [
              {
                "label": "Foo",
                // the child can directly references the 
                // "nested.foo" instead of relying on the
                // "parent" to set the context.  Limits the 
                // nesting to two levels.
                "model": "nested.foo",
                "children": [
                  {
                    "label": "value",
                    "model": "foosValue"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }

We really need to document what a model is in our demo app. We do not support all features of JSON Schema and we also have our own meaningful properties outside the scope of JSON Schema, so it'd be nice to convey this information to our consumers.

This may be related with the 3 levels of nesting bug.

When nesting values in more then 2 layers, it appears bunsen requires a cellDefinitions in the view (even if it's empty)

Example model:

{
    "type": "object",
    "properties": {
      "nested": {
       "type": "object",
        "properties": {
          "foo": {
            "type": "object",
            "properties": {
              "foosValue": {
                "type": "string"
              }
            }
          }
        }
      }
    }
  }

The following view fails:

{
    "type": "form",
    "version": "2.0",
    "cells": [
      {
        "children": [
          {
            "label": "Main",
            "model": "nested",
            "children": [
              {
                "label": "Foo",
                "model": "foo",
                "children": [
                  {
                    "label": "value",
                    "model": "foosValue"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }

But this one with an empty cell definitions renders:

{
    "type": "form",
    "version": "2.0",
    "cellDefinitions": {
    },
    "cells": [
      {
        "children": [
          {
            "label": "Main",
            "model": "nested",
            "children": [
              {
                "label": "Foo",
                "model": "foo",
                "children": [
                  {
                    "label": "value",
                    "model": "foosValue"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }

I have a input that is triggering a condition to show another input. The other input has a default value. The default value is not set on the triggering of the condition. So I'm able to see the field but the default value is not set.

type: 'object',
      properties: {
        description: {
          type: 'string'
        },
        continuityCheck8021ag: {
          type: 'boolean'
        },
        slmY1731: {
          type: 'boolean',
          default: true,
          conditions: [
            {
              if: [
                {
                  continuityCheck8021ag: {
                    equals: true
                  }
                }
              ]
            }
          ]
        },