This is called web viewer scrubbing. Add object name to your web viewer and use
GetLayoutObjectAttribute( yourObjectname; "content")
This should return the xml and you can check for an error
I don't think Web Viewer shows errors like a browser shows errors (when you view source). There is usually a default XSLT that parses the XML to be "pretty" with indents in browsers - making it easier to see the nodes. Do you get that in Web Viewer?
Do you get that in Web Viewer?
I just tried to load xml in a web-viewer.
On a Mac, it just renders the text without node names, the same as in Safari. May be it works on Windows as ie has a default stylesheet for xml?
On the bright side, web-viewer does display errors the same way as the browser.
Safari and FireFox (mac browsers) both show me "pretty-print" with collapsible elements. If you view source, you see the default "styles" applied to make it so, even if the nodes are not indented in the RAW xml.
I believe IE browser(s) have pretty-print default styles as well.
When pushing raw xml to the Web viewer, the may be important!
"data:text/xml," & field_with_xml
If I use text/xml then I get the text nodes of the XML
If I use text/html then I get just the text nodes of the XML (but no CDATA)
If I use text/plain then I get the raw XML
If I don't use data URI and just reference the raw xml from a field, it seems to load and then stalls.
(all of the above tested on Mac, FM14)
Good to know it shows the error. What media type was used to show that? I only see the error in Web Viewer with the media type of text/xml.
No, I just pointed the web viewer to a random xml file on my desktop. I am surprised I am not getting pretty xml in Safari or web viewer. Tried to google it and most of the advice is to install a plugin/extension.
Is this because you have developer mode enabled in Safari? Mine does not have View Source option either.
Safari 9.0.3 on OSX 10.11.3
I've enabled the Develop menu in Safari and it rendered xml as pretty.
Yes, sorry. Develop Menu enabled in Safari.
back to the OP's question...
If the correct media is being used (presumably) for the data URI in Web viewer (or the XML document is an URL to it's location on the desktop - or other reachable location):
* does the GLOA with the "content" parameter return that there is an error?
* does the GLOA with the "content" parameter return the raw XML only (such as "source" parameter should)?
* because the 'browser-in-web-viewer' may or may not be using default styles to "pretty-print", how will "content" be returned so that we know there is an error?
Perhaps this needs further testing?!
I ran some tests. You can see the error displayed in a web viewer, but when you GLOA with "content" it shows the original xml ( incorrect one ). As you mentioned it is probably using something to render the output. This is probably what the OP was about - scrubbing won't work. I am out of ideas how to do it in a simple way staying within FileMaker.
BTW, enabling Develop menu in Safari does not seem to be make any difference for web-viewer displaying xml
Did not mentioned that I tried with data url and external xml file, with Develop option in Safari on and off.
Many thanks Nicolai and Beverly for looking into this. It is a Mac and 10.11 but I this will not do what am after.
I don't think you can use a calculation to validate xml syntax inside FileMaker web-viewer natively. I do not see a Custom Function anywhere which does a full xml syntax check. If anyone knows, please let me know. You can write one yourself, but this is going to be a big complicated job.
You can try to use a plugin, e.g. BaseElements has some xml functions. MBS is another one and I am sure, there are others.
You can try to validate with a script. xmllint integration will need a bit of work and not everyone likes to mess around with bash. I would try to export xml with xslt from FIleMaker and import it back and see if there are any errors.
This is quite an interesting problem. I've seen xml assembled in FileMaker quite a few times before. The problem is that FileMaker does not have xml as a data type yet. This does not allow to check or validate xml natively, as big guns RDBS systems do. XML export/import with XSLT does a trick, in a way, but usually needs a bit of work.