Allow error summaries and submit buttons to know which form to be associated with
Closed this issue · 8 comments
This could either happen 'behind the scenes', or by allowing an argument to be passed in to specify which form should be used. A nice generic way for the submit button to work would be to allow any html attribute to be passed to it.
On the below page, we have multiple forms of the same type, which are distinguished from each other using the html form attribute and an id. The form submit button needs to have the same id so that it submits the correct form (so we are using a submit_tag instead of a GDS formbuilder button). The error summary needs to know which form the errors are associated with so that the links go to the fields of that form rather than the first fields with the correct name on the page (so we are attaching the error message to base instead of a field, in order to break the link, so that it doesn't point to the wrong form).
The form's template is app/views/publishers/organisations/_vacancy_awaiting_feedback.html.slim in https://github.com/DFE-Digital/teaching-vacancies/pull/3101/files.
I think this should be covered by the work that's going on in #251. I'll get a beta release out today or tomorrow and you can take it for a spin.
That looks promising! Thanks.
#251 works well for my purposes with the submit button. Thank you.
The error summary is not helped by that change, because I would like the <a> to change, not the <div>. The solution would probably be best as internal logic in the GDS formbuilder rather than an argument passed in by me. It would necessitate jiggery pokery that adapts inline errors (to make their ids form-specific) and the govuk error summary link(s) (to point to that specific id).
Ah, glad it worked for the submit button.
This is a really unusual approach and something the form builder just wasn't designed for. I'd be reluctant to change the way the form builder generates ids to support it.
Another option, and one that feels a little more generic, could be to provide some helpers or a utility class that, when given an object and a field, returns the generated id. Then you could implement a custom error summary component that links to multiple forms.
I'll have a look at approaches.
I wouldn't consider this more than a low priority request.
As of #311 the error summary can receive a presenter object. The presenter needs to respond to #formatted_error_messages. When a class is passed in it'll be instantiated with the list of errors, when an object is passed in it'll be used as-is.
The latter approach should allow you to build the functionality you describe above, although we might need to extend list_item a little bit so it can set a custom href (which you'd need to set up in your presenter) instead of building one using the attribute. The line where the errors are looped through should give an idea of how it fits together, but building your errors in a format like this would probably work:
# formatted_error_messages =>
[
[:name, "Enter your name", href: "some-other-form-name-field"],
[:title, "Select a job title", href: "yet-another-form-title-field"]
]As of #326 the summary message URL can be overridden using a custom presenter. This gives developers complete control over the contents and will allow you to link to anywhere. This should cover your use case.
Closing this as I believe it's now possible. Happy to revisit if there's more we can do.