I have come across a situation where form_with is not being processed in the default manner as TURBO_STREAM, but as HTML, in other words, the header request.accept is not being injected with text/vnd.turbo-stream.html.
In a first instance of this erroneous processing, an attribute's name was the same as the name of a class (a different one) ; initially a has_many relationship had not been spcified in the class. Once the relationship was specified the form handling the attirbute would not process via TURBO_STREAM but revert to HTML. After changing the attribute name, processing reverted back to its expected default format. Thus a form of naming conflict impeded processing via turbo stream.
However, a second case has not been worked out as of yet (the above naming problem is apparently not in play).
The closest one could get is with form_with url: ops_g_tables_path(format: 'turbo_stream')
will render an HTML tag with action="/ops/g_tables.turbo_stream"
and the launching of the form will be logged as Processing by OpsController#g_tables as TURBO_STREAM
but that's a hack, as the browser header is still set to
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
and the result is a simple text rendering of the file in the view folder.
Clearly the application is doing something that is tripping up the request header setting process... the proof is in the first case.
What other controls are effected before the text/vnd... injection occurs, so we can track this down?
I have come across a situation where form_with is not being processed in the default manner as TURBO_STREAM, but as HTML, in other words, the header request.accept is not being injected with
text/vnd.turbo-stream.html.In a first instance of this erroneous processing, an attribute's name was the same as the name of a class (a different one) ; initially a has_many relationship had not been spcified in the class. Once the relationship was specified the form handling the attirbute would not process via TURBO_STREAM but revert to HTML. After changing the attribute name, processing reverted back to its expected default format. Thus a form of naming conflict impeded processing via turbo stream.
However, a second case has not been worked out as of yet (the above naming problem is apparently not in play). The closest one could get is with
form_with url: ops_g_tables_path(format: 'turbo_stream')will render an HTML tag with
action="/ops/g_tables.turbo_stream"and the launching of the form will be logged as
Processing by OpsController#g_tables as TURBO_STREAMbut that's a hack, as the browser header is still set toAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8and the result is a simple text rendering of the file in the view folder.
Clearly the application is doing something that is tripping up the request header setting process... the proof is in the first case.
What other controls are effected before the
text/vnd...injection occurs, so we can track this down?