json-forms
json-forms copied to clipboard
brutusin
Support for readonly field
It would be useful when ID field has to be shown. Currently user can change the field and it saves a new object to database.
id: {
"type": "string",
"readonly": true
},
Disabled form fields wont be returned, just adding disabled wont work I guess :(
Hi, @akotulu I'am afraid I can't understand your problem.
Readonly properties can no be entered by the user, but its value its the same as set in the initial data passed to the form, so calling getValue() properly returns its unmodifiable value.
Example: http://brutusin.org/json-forms/#12
Ow, hmm. Well my bad, my model had no id field defined in initial data. It seems renderer doesn't like it and creates input without disabled attribute. Is it intentional?
Yes, it's the expected behaviour. Maybe if you give me more information about your use case I can help you
My use case is following, I have a Id field which user has to be able to copy, but unable to modify. Currently when empty form is displayed this field is shown as editable, miss leading user. Why I stumbled on this is following, my default Backbone model had no Id field defined so when new entry was forwarded to server, it had no id and thus json-schema validation passed. After adding Id value to default model, it was forwarded to backend and didn't pass the validation, cause Id=null, but schema type is string. I made a workaround removing the Id field before request.
if (this.model.get('id') == '') {
this.model.unset('id');
}
In my opinion it would be slick if default behaviour would be disabled input when it isn't present. I would even go so far as making passing initialized model optional.
It would make library more accessible, just throw in schema, user fills the form, getdata and your done. Bit less code is always better.
Hi again, I think I understand, correct me if I'am wrong: you are using the library to create a form to be used in a UI and according to your business needs, you want this form to show some readonly information, but not to send it back to the server.
Despite being legit, this is not the original purpose of the library, that is letting the user create object instances according to a given schema, more than a being a tool for creating forms according to the business needs.
So I can see here different approaches: the one you did, that is, decorating the obtained object, or decorating the generated form once rendered, or showing the user information out of the form.
I think the solution for this case (and others) would be to have a way to add html tag attribute to the input field via our schema, this way it wouldn't break the purpose of the library, but it would be more customizable.
I was looking for library that could draw a form based on my schema which I use to validate my API request. I have a complicated schema which is inserted to database. Using same schema for validation and form generation is the way to go. I had no problem inserting a empty input data to generate the form but as It is a extra move, cause schema has all the info to make a empty form.
Im sure others are looking for same functionality, give a schema and get the from with correct validations without giving any initial values.
It would make the library more accessible and easier to use, nothing more. Currently I can't understand why its useful to draw a input as editable when its missing from initial data and marked as readonly. getData returns initial value anyway.
@idelvall I tried something here, but I don't have the time until next weekend to really experiment the code with more quality.
@akotulu Do you think that don't generating the input is really the best idea? I think that showing the input with an attribute disabled, like <input type="text" disabled /> (html5) or <input type="text" disabled="disabled" /> (xhtml, I think). You can style this elements with the :disabled pseudo-class in CSS.
My proposal is a more broad feature that would allow the schema to set html attributes for each input, not just the disabled attribute.
I have two main arguments for this approach:
- not showing the input by default is specific to some UX ideas, but not to others
- it's more generic and could cover other use cases
It would be awesome if I can remove some properties using a keyword.
The ability to have some fields as hidden, and also some fields completely skipped from rendering is very helpful.
Optional fields should be optional to render too.
This is a great suggestion @pateketrueke , i will have it in mind for the v2 branch I am currently working on. I will come back to you when the v2 is ready. Thanks