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

Allow form layout definitions to modify default form, rather than all or nothing #50

Closed
builtbybrayne opened this issue May 7, 2013 · 4 comments

Comments

@builtbybrayne
Copy link

For very large forms, or auto-generated schemas it is impractical to control the layout using the form section of the configuration (a la https://github.com/joshfire/jsonform/wiki#controlling-the-layout-of-the-form).

The use-case I struggled with was trying to use the 'checkboxes' form layout. I have found no way to specify that an array should be treated as a checkbox array without also being forced to then specify the entire form layout. This is an unworkable solution for me as I have many hundreds of fairly deeply nested auto-generated fields in the schema which I couldn't possibly justify defining the layout for using the 'form' parameter as it's too variable. But I would benefit hugely from the option of specifying that this, and only this, field needs to have layout information - while all other fields can be created using the default form layout.

This feature request is therefore to allow users to specify the default "*" behaviour along with the option to specify override behaviour for specific fields only. This is in contract to the current situation where one either uses the default for the whole form, or specifies the whole form manually.

If I've missed something or got this wrong, then I'd suggest that this ticket turns from a new feature request into a request to improve the documentation to better reflect the solution that already exists.

@denseflux
Copy link

I have exactly the same need. Simply to turn some text fields into text areas in a long form. An override solution, or ability to add these fields into additional json schema properties directly would be a great help.

@Coridyn
Copy link
Contributor

Coridyn commented Oct 14, 2013

You can add an onBeforeRender callback to the jsonForm initialiser object.

You can use this callback to set the template to use for any element without having to use the form section of the configuration.

    $('form').jsonForm({
        schema: {
            // ... schema data goes here.
        },
        onBeforeRender: function (data, node) {
            // Set the template to be rendered for this node.
            node.template = '<%= template_string %>...';
        }
    });

The callback receives data about the node and the current formNode instance itself.

    ...
    onBeforeRender: function (data, node) {
        /*
        The `data` property has the following structure:
        {
            id: formNode.id,
            keydash: formNode.keydash,
            elt: formNode.formElement,
            schema: formNode.schemaElement,
            node: formNode,
            value: isSet(formNode.value) ? formNode.value : '',
            escape: function escapeHTML
        }
        */


        data.elt.key;   // A string representing the full data path for this element: 'item.list[].listItem'
        node.arrayPath; // The index for each array in `data.elt.key`.
        node.name; // The interpolated key/arrayPath. e.g.: 'item.pricing[0].listItem'

        // Get information on parent nodes through `node.parentNode`.
        node.parentNode.schemaElement.type;

        // Set `fieldtempalte` to false to avoid wrapping 
        // this element in boilerplate markup.
        node.fieldtemplate = false;
    }
    ...

I hope that helps :)

@ulion
Copy link
Contributor

ulion commented Nov 10, 2014

Implemented customFormItems property for the jsonform option to custom form layout for selected schema key in above mentioned commit of my branch.

@stale
Copy link

stale bot commented Feb 28, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale label Feb 28, 2020
@stale stale bot closed this as completed Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants