I need an easy way to allow users to upload multiple files at once (ie I need to allow a user to upload a folder). I do not wish to put the burden of zipping on the user.
I would prefer to avoid Flash or variants if possible. I'm looking for a straight javascript / HTML solution if it is possible. Please note, this rules out the answers at: What is the best client side browser library to upload multiple files over http?.
You won't be able to do it with just HTML and Javascript. I'd recommend trying Fancy Upload, a MooTools plugin for multiple file uploads. It uses a mixture of JavaScript and Flash, but degrades gracefully. It works with all major browsers including IE6 and there is also a Flash 10 compatible release available for download (though the demo hasn't been updated yet).
Update (2012-11-26):
Multiple file uploads are possible with valums or blueimp file uploaders.
For recursive directory uploads, your best solution is using Chrome 11's new folder upload API. It also seems to work on Firefox if you use a vendor prefix.
With Firefox 42 and Edge having implemented the new directory upload proposal we'll finally able to do cross-browser directory uploads. The APIs are nasty enough that you may want to check out my wrapper, uppie.
If you're avoiding Flash (and presumably Java?) the JS/HTML-only solution still requires single-file inputs, but essentially you attach an onchange event to your input, adding a new input to the DOM whenever a file is selected.
Multiple file uploads are possible with valums or blueimp file uploaders.
For recursive directory uploads, your options are more limited:
Your best solution is using Chrome 11's new folder upload API. It also seems to work on Firefox if you use a vendor prefix.
This is also possible cross-browser with a Java applet. However the % of folks with a JRE installed has gotten pretty low these days (< 70%)
This isn't a pure js/html solution. As EndangeredMassa has pointed out, it's not possible. In fact, this idea is an IE/Windows only solution. I don't recommend it, but it can work.
So, all disclaimers aside ...
Many years and several employers ago, we used to do some client side stuff that instantiated the FileSystemObject. It would iterate through each of the files and pass them through to the server one at a time. Can't remember the details of how we did that :o(
Anyway, this usually meant that the client box would need to have to add the site to the list of trusted sites and give trusted sites a bunch of permissions that are turned off (for very good reasons). Stuff like the ability to Initialize and script ActiveX controls not marked as safe. That kind of thing.
I know that this isn't a perfect answer, but it could point you in the right direction.
FTP? And if necs, wrap in Java Applet, ActiveX or whatever you want.
If not, although you don't want flash, SWFUpload is quite cool, you may want to reconsider it as a decent option.
Here is pure JS solution using ExtJS library
Related
I know that JavaScript is not allowed by browsers to do much directly with the computer, and that is not my question. My question is: How to, with JavaScript, create a file on the web and then ask, perhaps with a popup window, to download the folder and any files within. This folder would need to allow access for JavaScript to place files within, like image files. This folder might originally be just another JavaScript value (like an object) or a URL.
I have done research, but much of what I found was asking whether JavaScript could create a folder directly to the computer, while my question is asking about creating the folder, and then asking to download it. There must be some way, because when in Google Drive, drive has a way to place multiple files in a .zip folder for download, and this works not just with Chrome but with Firefox and Internet Explorer. Some sites like http://stuk.github.io/jszip/ provide their own way to create .zip files, but I would prefer not to use a JavaScript library, if possible.
This would be useful for generating multiple image files, but only asking the user once for downloading them, instead of for each file.
I would prefer to create the zips client-side.
So this is an interesting question and I shall do my best to answer it. The simple solution is to not do this at all. Use javascript to asynchronously request the server to create the required .zip and then give the user a link/prompt to download. But I digress, you want it all in-house!
JSzip Option
You'll not be able to write a solid library that can .zip files client-side. JSzip is the best option out there, and it's not as solid as it could be. If you have the time you could go through the source and make improvements where required.
Cheeky Option
Your best option - baring the actual best one (server side) which you have discounted - is explained here. That is - create an iframe for each file.
Unfortunately you'll not find any better than those options if you're insisting on client-side work. Browsers weren't made to be zipping files.
I have a text file i want to read in my html page,both are in the same directory and i am not running a server. I intend that my users use the script offline(basically text manipulation based on expressions and preserving new line characters) .
I tried ajax call but mostly cross domain origin problem occured and i know most of the users will have this security tighened up in many browsers , so its not of use to circumvent this in only in my browser.
I want to support many browsers including old browsers as in IE7,8 etc which do not support HTML5 filereader.for the same reason reading using filesystemobject or activex is not good.
Reading the file after user select it as input , is this possible?Otherwise i would have no option then using other technologies like php,java etc which may expect my user to setup these.
Please excuse me if i am repeating this but i am a beginner web developer. I know that reading local files via javascript is not possible but is there any other way?
If you can't support FileReader, then the answer is pretty much no (at least, if you want to support a large range of browsers rather than rely on convenient feature x of browser y). Unless : you indeed increase the requirements for running the application and get some sort of local server going (for instance node.js, Apache, TomCat, etc. but like you said this will greatly increase the requirements and become cumbersome for users).
You could also rethink what it is you're trying to achieve. What are the contents of the file you want to read ? Can't these contents be part of the HTML file you're serving to your users (i.e. a large JSON Object inside a script-tag ?)
On possibility of using node.js:
Node.js is quite easy to install and assuming you are requiring from your users to install it, you can use it as a local server, which is a nodejs script of about two lines in size :). Running it locally would also omit the need to upload anything anywhere as you can directly read from the file system using the fs-object (see sitepoint.com/accessing-the-file-system-in-node-js).
STILL: from both a design and ease-of-use-point of view you might want to resort to using either another technology, or include the text file content inside the HMTL file
So I have web app with multiple JS files (jQuery, jQuery, my own JS code and more). Say I have a page named index.html. What would be the best practice to include / preload my js files? I was thinking about creating a separate JS file that will do the preloading (include all the other scripts and call jQuery.noConflict()). What do you guys suggest? Is this possible? How would you implement it?
Thanks!
In general, combine your script files into one file (and minify or compress them, or even compile them, but note that this last item is not zero-impact, there are pain points). See notes here and here. Basically, one of the first guidelines you'll see for a good fast page load is "minimize HTTP requests." So you don't want six separate script tags where you could have one.
For popular scripts, though, you may benefit from using them from Google's CDN. Google is kind enough to host most popular JavaScript libraries on their CDN for free. The advantage here being not only that the CDN will be fairly fast, but that the target user's browser may well have a cached version of the script you want to use even though they've never been to your site before.
Check out RequireJS, a smart and robust script loader for JavaScript. It's designed to work well with jQuery and comes with an optimization tool to combine all of your scripts into one.
The best way is to minimize all the js files and combine them into one script. This will cause less work for the browser, as it doesn't have to make multiple requests to the server.
If you are going to load everything up at the same time, you could put it all into a single compressed file
This one should be easy, and I think I know the right answer, but here goes.
For compatibility reasons, should I leave the filename of jQuery as "jquery-1.3.2.min.js" or just rename it to jquery.js?
My guess is leave it as is to avoid conflicts in case another app uses a different version of jQuery. If they've renamed it to "jquery.js" and I do the same, I see potential version conflicts.
Am I wrong or way off base?
Jeff
It's a very good idea to have version-numbered JS (and CSS) files, because that lets you configure your web server to use a far-future Expires header on such files without running into caching problems. When the file gets updated, it gets a new version number, so the browser always fetches the new version, not the old cached one.
You should do this on your other JS and CSS files, too. You want this to be automated, not something you manage by hand. Your development work happens on unversioned files, and your versioning system creates versioned copies and works out the details of updating the references to the CSS and JS files in the HTML files to point to the versioned copies. This can be a bit of work, but well worth it when it comes to speeding up your site. It took me about a day to set my system up. The improvement wasn't subtle.
I would go with jquery-1.3.2.min.js because it's more specific and you can immediately tell if you're reviewing this site in months to come, as well as avoiding any filename confliction in the future.
You shouldn't have any issues with updating, if you're relying on something like an include/template file for the javascript.
In my opinion, its just a personal preference. If you have version in your file name, It helps you easily identify which one you are using with out actually opening the file. It also provides an indirect way of clients downloading the new version file (as it is never cached). If you don't use the ext, upgrading to newer version is easy in coding perspective, but takes the pain of force downloading the new file by all users.
Recommended way to use jQuery in app is using the google's hosting..
google.load("jquery", "1.3.2");
google.setOnLoadCallback(function() {
// Place init code here instead of $(document).ready()
});
Why and how to use jQuery hosted on google
I prefer to leave the version in the file name because there are times when you are changing versions and this is very helpful. At a glance I can see which version I am using on any given webpage.
I was trying to do something like this: http://www.element-it.com/Examples/MultiPowUpload/AdvancedHTMLinterface.html
But in my search for information I found that is not possible to perform multiple file selection with simple HTML and JavaScript (and JSP in the server side). There is a way to do this without using Flash? A third party component you could recommend?
Thanks.
Actually according to the specification, normal HTML file upload fields are supposed to be multiple-file-upload fields. Opera supported it for a bit, allowing you to ctrl-click to select multiple files from a file picker. But it almost always broke the webapp since many web frameworks didn't know about it and would fall over.
In the meantime, it usually suffices to use JavaScript to add an extra file upload field to the form when the previous one has been filled in. This can be made gracefully-degrading for non-JS UAs, whilst sprucing up the management of multiple files with script and pretty icons.
If you go with a Flash uploader, it's a good idea to back it up with a simple HTML file upload field for compatibility there too.
It is still works via flash, but the YUI Uploader component allows you to add multiple file selection with minimal knowledge of flash - the API to interact with it is purely javascript.
HTML 5 will support multiple file upload, but that is not currently well supported in a large number of browsers