Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

two-step binding form for providing binding parameters #389

Merged
merged 2 commits into from
Jul 10, 2018

Conversation

prydonius
Copy link
Contributor

@prydonius prydonius commented Jul 6, 2018

refs #363

Copy link
Contributor

@andresmgot andresmgot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm but as far as I understood the change to split the form in two steps is not related with the fix of adding the parameters input?

Cancel
</button>
{displayNameForm ? (
<SchemaForm schema={this.nameSchema()} onSubmit={this.handleNameChange}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use just Form here instead of SchemaForm it's a bit confusing that you are using the SchemaForm just to retrieve a name.

Copy link
Contributor Author

@prydonius prydonius Jul 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see what you mean but my actual secret plan is to move all forms in Kubeapps over to using the SchemaForm eventually. The main reasoning is that it gives us one place to define how all forms look inside Kubeapps, and avoids boilerplating out <form>s everywhere. That way, the components only need to worry about the schema/fields that go into a form and not the rendering of the form itself. WDYT? If you think that's not a useful thing to have though, we can consider putting this back to a regular form.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mm, I am not sure if that is something doable? I may be missing something but forms like DeploymentForm are more complex and define methods like componentWillReceiveProps and have nested elements like DeploymentBinding. Anyway, I understood schema like something specific to service bindings but if it's not I am fine reusing it every time is possible.

@@ -205,7 +210,7 @@ export class InstanceView extends React.Component<IInstanceViewProps> {
</CardGrid>
<h2>Bindings</h2>
<AddBindingButton
bindingName={instance.metadata.name + "-binding"}
bindingSchema={svcPlan && svcPlan.spec.serviceBindingCreateParameterSchema}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if this change is related to the issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps you're misunderstanding the issue in #363, @arapulido wasn't able to create the bindings for the GCP PubSub service because there were required parameters and previously this form didn't support specifying parameters for creating bindings (we only supported them for provisioning instances). So this PR is to add support for the schema provided by the broker to render a form for entering binding parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see now, I didn't realized how pieces are tied together

@prydonius
Copy link
Contributor Author

@andresmgot the fix for #363 is to add parameters input, the change to the two-step form is just the correct way to handle adding the parameters input, since we need to rely on the upstream schema.

@andresmgot
Copy link
Contributor

👍 I guess you want to implement the TODO in this PR? In other case it LGTM

@prydonius
Copy link
Contributor Author

Thanks! Actually I'll do it in a separate PR.

@prydonius prydonius merged commit 86f1253 into vmware-tanzu:master Jul 10, 2018
@prydonius prydonius deleted the 363-generic-binding-output branch July 10, 2018 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants