You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 6, 2021. It is now read-only.
We can reduce the boilerplate by making input filters and CSRF protection baked-in to each form.
If we have to change how a form element is displayed, we only have to make the change in one place.
It should become much easier for users to add/extend forms to their Cabins and Gadgets
Less redundant code means less to audit, and likely a significantly reduced attack surface
I'm not quite ready to commit to having this ready for version 2.0.0, but it's an idea I'd like to think about. The actual implementation details (how to handle conditional form requirements) and edge cases (file uploading, element-bound JavaScript) need to be hammered out.
The text was updated successfully, but these errors were encountered:
There are a ton of benefits (especially for making the new motif configuration system easier to develop for), but I'll need to do research and design a system that makes this as simple as possible.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'd like the reduce the code footprint (and therefore liability) by creating a generic form framework in a future version of Airship.
Ideally, we would turn templates like this one into something like:
And then on the template:
{{ render_form(object_passed_from_php) }}
This will afford us several advantages:
I'm not quite ready to commit to having this ready for version 2.0.0, but it's an idea I'd like to think about. The actual implementation details (how to handle conditional form requirements) and edge cases (file uploading, element-bound JavaScript) need to be hammered out.
The text was updated successfully, but these errors were encountered: