-
Notifications
You must be signed in to change notification settings - Fork 653
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
Schema changes aren't handled correctly #395
Comments
They aren't watched deeply, you need to issue a |
@davidlgj It didn't help. Actually I change schema object, not just its properties, so it should work without issuing |
I think I found the issue, If you supply a form definition with form objects those objects are then reused internally, for instance setting the So as a workaround do an I think we'll need to add one internally as well. Both to form and schema since we modify them both when needed. Shouldn't be that much of a performance issue I hope :) |
ok, I'll try the workaround later. thanks |
Please re-open if you do not feel the question has been answered sufficiently. |
I have 2 schemes and 1 form definition:
Schema 1:
Schema 2:
Form:
Schema 1 is default, so default field type is text.
When I switch to Schema 2 the field aren't changed to select, it remains the same input[type=text].
I've made some research and found out, that
schemaForm
and its value has 2 propertiesform
andschema
schema
's value corresponds to selected schema 2. That is OK.form
's value contains info about the field, and this field's info contains info about the schema. But this schema info doesn't corresponds to current Schema 2, it corresponds to previous Schema 1. This is NOT OK.The text was updated successfully, but these errors were encountered: