media type relating to results from a 'replace=all' submission

[Chris H.]

Hello xsltforms-support, good morning


Question:
Initially before I go into this matter deeper, please can Alain, or any one
else, briefly explain what happens in xsltforms for a submission where the
attribute replace="all" is present?

I am particularly interested in how content-type/media-type is handled and
where in the .js this happens.

Background:
As background to this, I have an xform returned from a GET to a xquery in
eXist-db. This is displayed correctly, however the content type showing in
latest FF using the tools/pageinfo menu option, is text/html, where as
'LiveHeaders' addon shows application/xhtml+xml was, as coded, sent for the
traced Response part.

When I submit from this form using a 'POST' method with 'replace' set as
'all', the xquery called, returns correctly formed xml as
application/xml. Unfortunately, it is only seen as text/html and doesnt
display as an XML tree as would be expected. It just displays as text.

If I just call the xquery directly (without using xsltforms), then all
works correctly and the xml returned is shown as application/xml and
displays as an xml tree.

This is why Im interested in clarification on content-type handling and
what happens during a submission, particularly with a replace="all"
attribute.

Thank you for your insight.
Habs

[Alain Couthures]

Hello,

Submission with replace=all is a problem for XSLTForms because
XmlHttpRequest() has to be used. All the current page is to be replaced
by the response: you can have a look at
XsltForms_submission.prototype.submit() method, you will see 'if
(subm.replace === "all") {' and how it is performed in Javascript.

I have not been able to find a way to force the browser to consider a
Javascript string as if it received it as a new page. But, it is
possible for you to write your own XML tree renderer (with HTML tags and
styles) in Javascript!

If you want the browser to render an XML tree by itself, you might use a
specific method named "xml-urlencoded-post" which I added as an
extension to XSLTForms: instead of using XmlHttpRequest() to post the
XML data, an HTML form is added with a unique field named "postdata" in
which the submitted XML is serialized. With this method, the server has
to extract the XML data from the postdata field but the browser will
effectively have a new location and render the returned data according
to the content-type.

What do you think?

--Alain

Post by Chris H.
Hello xsltforms-support, good morning
Initially before I go into this matter deeper, please can Alain, or
any one else, briefly explain what happens in xsltforms for a
submission where the attribute replace="all" is present?
I am particularly interested in how content-type/media-type is handled
and where in the .js this happens.
As background to this, I have an xform returned from a GET to a xquery
in eXist-db. This is displayed correctly, however the content type
showing in latest FF using the tools/pageinfo menu option, is
text/html, where as 'LiveHeaders' addon shows application/xhtml+xml
was, as coded, sent for the traced Response part.
When I submit from this form using a 'POST' method with 'replace' set
as 'all', the xquery called, returns correctly formed xml as
application/xml. Unfortunately, it is only seen as text/html and
doesnt display as an XML tree as would be expected. It just displays
as text.
If I just call the xquery directly (without using xsltforms), then all
works correctly and the xml returned is shown as application/xml and
displays as an xml tree.
This is why Im interested in clarification on content-type handling
and what happens during a submission, particularly with a
replace="all" attribute.
Thank you for your insight.
Habs