I am trying to create something with heavy XML editing dependencies and I have a few questions about how I would go about doing certain things.
What I know:
HTML editing
XML method editing shares most methods with HTML (which is a type of XML itself)
How to load an XML document and navigate it
My questions:
how do you save an XML document that was edited in javascript or does it do it automatically
how do you create a blank XML file with javascript
Unfortunately you may not be able to do what you want. JavaScript/ECMAScript cannot write directly to a file without any direct interaction (at least, not to a file in the typical filesystem like a "My Documents" or "Desktop" folder).
First off, you can save an XML/HTML DOM to a string like this (will only work in later versions of most browsers and IE 9+):
if(typeof window.XMLSerializer == "undefined") {
throw new Error("No modern XML serializer found.");
}
var s = new XMLSerializer();
var xmlString = s.serializeToString( xmlDomVar );
After that you only have 2 options as far as saving the data (without using some extra plugin and even those may have a number of restrictions):
Save the data to a sandboxed file that is only accessible to the application using localStorage after permission to use localStorage is given by the user (stored in a location determined by the browser, you can't define "C:\User\MyUser\Desktop\myfile.xml" as a location).
Good guide here: http://www.noupe.com/design/html5-filesystem-api-create-files-store-locally-using-javascript-webkit.html
Save as Blob data then request that the user download it. This method will not let you define where you want the user to save it, it just presents the typical "Save File As..." dialog for the user to specify where to save the data.
Good examples here: Is it possible to write data to file using only JavaScript?
For creating a "blank" xml file... you can't. It has to contain at least the opening and closing tags eitherwise the browser will return a basic-formatted HTML DOM complete with html, head, and body tags. Once again, will only work in IE9+ and most other modern browsers:
if (typeof window.DOMParser != "undefined") {
parseXml = function(xmlStr) {
return ( new window.DOMParser() ).parseFromString(xmlStr, "text/xml");
};
} else {
throw new Error("No modern XML parser found.");
}
// This will create a new XML DOM containing whatever is in the string.
var newXmlDom = parseXml( '<xml></xml>' );
// This will create a basic HTML structure if you do not provide any valid XML.
var newHtmlDom = parseXml();
Related
I am making an application that brings up a preview of PDF files. Embedding with an embed element works well for small PDF files but fails for larger PDF files because of the size limits for data urls. I'm looking for a way to use the browser's native PDF viewer to view PDF files but without using data urls.
My code currently looks something like the following:
<script>
function addToCard(input) {
if (input.files.length <= 0) return;
let fileReader = new FileReader();
fileReader.onload = async function () {
pdfCard.src = fileReader.result;
};
fileReader.readAsDataURL(input.files[0]);
}
</script>
<input type=file oninput="addToCard(this)" />
<embed id=pdfCard style="width:100%;height:100%" />
Example. The original PDF is here.
You could use URL.createObjectURL() on the PDF. It also creates a URL representing the object; however, the difference between an object URL and a data URL is that, while a data URL contains the object itself, an object URL is a reference to the object, which is stored in memory. This means that object URLs are significantly shorter than data URLs and take less time to create.
There are two drawbacks to this approach that may prevent you from using it. The first is that an object URL will only work on the page on which it was created. Attempting to use an object URL on a different page will not work. If you need to access this URL anywhere other than the page it was created on, this approach will not work.
The second is that object URLs keep the object for which they were created stored in memory. You have to revoke the object URL when you are done using it with the URL.revokeObjectURL() method, otherwise it will cause a memory leak. This means that you might have to add some extra code that revokes the object URL once the PDF is loaded. This example may be helpful.
The implementation might look something like this:
function addToCard(input) {
if (input.files.length <= 0) return;
pdfCard.src = URL.createObjectURL(input.files[0])
// gonna have to call revokeObjectURL eventually...
}
After browsing around the internet for a few hours to find a solution, I found out a few methods of getting the information from a filereader, but not quite to what I need.
function submitfile() {
var reader = new FileReader();
reader.readAsDataURL(document.getElementById("filesubmission").files[0]);
reader.onload = function (REvent) {
document.getElementById("outputcontent").innerHTML = "<iframe width='100%' id='outputdata' scrolling='yes' onload='resizeIframe(this)' src='"+REvent.target.result+"'></iframe>";
};
}
function resizeIframe(obj) {
obj.style.height = obj.contentWindow.document.body.scrollHeight + 'px';
}
That is the code that I'm using after a user selects a file, which I allow .html, .htm, .txt, or .xml. The Iframe is then resized to match the content. I have that functionality working, however I need to have a method of replacing text in the iframe with certain values that the user provides in <input> tags earlier. An example would be I need to be able to replace "[c1]" in the file the user provides with a client's name, such as "John Smith".
The way I would prefer to do this would be through the content of the file itself, rather than using a source in an iframe or data in an object. If I can get this into the original file itself where it can be edited, that would solve the problem.
I need to be able to do this without the use of jQuery or other plugins, since this is a local file that should be able to work standalone as a tool for my client.
Use the DOMParser to parse the reader's result:
var doc = (new DOMParser).parseFromString(reader.result,"text/html");
or any other mime type,
Then, update the some nodes within the doc based on the inputs you mention.
Then use the iframe's contentDocument to adopt the node using document.adoptNode. That will return the node with its ownerDocument pointing to the iframe. Lastly append it to the iframe's body.
I have a simple javascript application that lets the user generate some XML and then save it as a file. However I can't get the saving to work in IE.
Currently I am using the data-uri method as exemplified in this jsfiddle. But this does not work in IE because it does not support data-uri for application/xml. What would be another method or workaround (client-only) to let the user easily save an xml string (or dom node) as a file?
The correct answer was given by Mr Anonymous in the comment.
$("a").click(function(e){
var xml = $("textarea").text();
if(window.navigator && window.navigator.msSaveBlob){
e.preventDefault();
navigator.msSaveBlob( new Blob([xml], {type:'application/xml'}), "myfile.xml" )
} else {
$(this).attr("href", "data:application/xml," + encodeURIComponent(xml));
}
});
I need to serialize a File object from a file input, so that the object can be saved, parsed back to a file object, and then read using the FileReader object.
Does anyone know if this is possible in Google Chrome?
I think the problem lies in the protection of the file.path property. Webkit browsers hide this property, so I am guessing when you serialize it, the path is removed.
Then of course, the FileReader is unable to read it without path information.
Here is an example:
var files = uploadControl.files[0];
var dataFile = JSON.stringify(files);
var newFile = JSON.parse(dataFile);
var reader = new FileReader();
reader.onload = (function(event) {
var fileContents = event.target.result;
});
reader.readAsText(newFile);
Nothing happens. The reader is not loaded. If I pass the JSON object, it doesn't work either.
As a matter of principle, what you are asking for will not be possible. If it were possible to have some text which represented the file object, then you could construct that text from scratch, unserialize it, and thus get access to files the user did not grant permission to.
(The exception to this is if the representative text is some sort of robustly-secret bitstring (cryptographically signed, or a sparse key in a lookup table) that only the browser could have given out in the first place — but I expect if that feature existed, it would be documented and you would have found it already.)
I want to use the HTML5 FileApi to read a SWF to an OBJECT (or EMBED, if it's better to do?).
My current code crashes on Chrome/Iron (the only stable browser which also supports the xmlhttprequest v2 FormData). I got it to read image data into a on-the-fly created IMG. But the object one crashes the current tab in the browser.
else if (file.type == "application/x-shockwave-flash") {
var show = document.createElement("object");
show.type = "application/x-shockwave-flash"
show.style.width = "100%";
show.style.height = "100%";
show.id = "thumb";
document.getElementById("thumbnails").appendChild(show);
var reader = new FileReader();
reader.onload = (function (aImg) {
return function (e) { aImg.data = e.target.result; };
})(show);
reader.readAsDataURL(file);
Do I really read to the object.data part? How is it done right? Anybody know? Or is this incomplete and I have to wait for better implementation?
A few things I'd recommend trying (in order of increasing complexity):
base64 encode the data with btoa and set it using a data: URI,
instead of creating the object using createElement, construct the <object> tag with all attributes as an HTML string (including the base64 advice above), then inject it into a DOM element with innerHTML,
create a reflector web service where you POST the swf content, it gives you a URL, then pass the URL off to the object,
similar to the previous, create a reflector web service where you POST the swf content, targeting a full-screen IFRAM as the target, have the service spits back an HTML doc including an <object> pointing back to the server.
The later of these options is more intense, and requires round-trips from the server that you'd probably want to avoid - just some more options you might want to consider.
ActionScript 3 has a Loader which may be useful as well. I don't know if it supports data: URI's, but if it does, you could write a boot loader SWF which runs the contents of the local swf file directly.