As far as I can tell, it is impossible to access the content of files on the user's computer in a web application without first uploading to the server, then re-downloading to user, unless some sort of plug-in is used. (Flash, etc.) Ideally, the user would upload the file directly to localstorage and then scripts would have a chance to process/display/validate/filter without the user having to wait on an upload.
Are there any features in upcoming web standards such as html5 that will allow this? If not, why has there been no effort to make this possible, and how can I work around it without getting stuck with plugins?
EDIT: DO NOT assume that I want to let JavaScript access arbitrary files on the hard drive without any user intervention. We already have the ability to prompt the user for a file and upload it, I only want the ability to prompt the user for a file to be loaded into the browser's memory. I was only hoping HTML5 would have support for something you can already do with both Flash and Java applets.
Doesn't the File API ( http://www.w3.org/TR/FileAPI/ ) do that ?
It's implemented in Firefox 3.6 (see https://developer.mozilla.org/en/DOM/FileReader and https://developer.mozilla.org/en/Using_files_from_web_applications )
According to http://code.google.com/events/io/2010/sessions/html5-status-chrome.html it is supported in chrome.
What you can do in HTML 5 (or 6, 7, ...) depends on what a diverse group of vendors with competing agendas think the new HTML version should or should not do... it is designed by committee.
Giving a web page that you create permission to access resources (e.g. files) on your computer creates a very large security hole (would you like my web page to read your emails and home banking files?)
It's very unlikely that a committee will agree to standardize on a feature that creates a security risk, given that only one browser on one device/platform needs to poorly implement that standard to open Pandora's Box to hackers.
Individual vendors (the people that make plugins) don't have to get a bunch of other companies to agree on a feature. They just implement it, and users get to decide if they trust it enough to install it. Microsoft's first attempt at this was a major security disaster.
Like Raul and Eric pointed out, there is a significant trust issue involved, and requiring people to give code they don't know access to their hard drives will not make your site popular.
You are probably stuck with choosing between plugins or browser specific features/addons for a long time.
That said, you can do cool things by just making the best of this situation. One approach I've used several times is to have an invisible plugin (Applet in my case) present on a web page, but control it entirely via JavaScript, giving the web app a very "natural" look and feel.
Another approach is progressive enhancement of some sort - providing an enhanced experience for users who have the required plugin installed and opt to use it. I've experimented with this on sites such as http://www.pdfcombine.com - users who don't have the Java plugin installed get to merge PDF files by uploading them to a server and downloading the merged file, whereas users with the Java plugin are given the option to do it all locally with the Applet.
Related
I'm building a browser application in web2py (Python based CMS). One requirement this application has is to enable is the user to browse to a folder within the local network or local drive. The user selects a folder, that selection becomes a string that I record in the application's database. File selection is entirely off the table. I don't care at all about file selection. I only need to select one and only one folder. And get the one folder's fullpath/UNC as a string, collection is strings, object, or whatever that I can then assemble the fullpath as a string.
How can I develop a browser user interface screen object of some sort that enables the user to browser to and select a folder ( c:\folder\folder -or- \\server\share\folder ...) Then capture that string in a variable I can write to a databases?
I'm finding there are a lot of impediments to just such use of a browser application (didn't used to be that way). I get the security concerns but I also can't believe all similar enterprise uses of a browser are being torn down and made impossible (again, because it didn't used to be that way).
I don't want to dictate implementation. So spitball ideas if you like. Get out of the box of this tech stack if you like. But browser based is HIGHLY compelling (if I were to do this as a desktop app or something else I wouldn't even need to post this question).
The current tech stack of the application is: browser (open to suggestions but Chrome is the preference), JavaScript, jQuery, JQWidgets, Python, MSSQL (server hosted, not CE/local). But none of these elements are hard limitations. Except IE/Edge. We'll never use that.
If you can point me to fiddle, GitHub, ... examples that would be greatly appreciated.
Is there a particular JavaScript library, browser addin, Python import, ... I should research?
Would .Net be better suited to champion this challenge?
Is there a better forum you know of where I should post this question?
Thanks
I had to resort to this.
The application's user interface is posting to methods back on the site's controllers.
Then code executing on the site's server (Python) is providing the user's interface lists of folders and files on the file server's shares.
With some effort I will be able to provide the user with a rich and comprehensive UX that will effectively be the same originally desired. Or at least enough so.
What I will not be able to provide is a folder-file lists of the user's local hard drive. And any drives mapped between the user's workstation and the file server will not be represented from the web server to the file server. Meaning the user will have to learn to live without the mapped drive letters which they have become accustomed to.
I'd sum this up as looking for an offline client solution that is 100% standalone and uses no external files/libraries or other machine resources to tabulate data from a user-chosen TSV file (the result is simply rendered in a plain HTML table - nothing fancy, just data).
I am not a web programmer, but have volunteered to do this project. I have been asked to code this as a browser-based solution because the party deems it the most user-friendly for their needs.
Again, this is not an html file that is served; it is emailed to a client that copies it into a folder of their choosing and run (by selecting a local file to render).
Every time I attempt some solution (e.g., FileReader, etc.), I can only get it to only work in a certain manner with specific browsers (including having to use it differently in the same code depending upon the browser - is this simply my lack of knowledge?).
My question is: Is there one single way to code this for most browsers (including older browsers like IE8)?
If not, I would most appreciate suggestions - both general and specific.
An example would be helpful if possible.
Thank you in advance.
If you're looking for client/browser specific, you won't have access to the file system. That's a security breach that isn't implemented into the browsers. You're going to need to implement some sort of server-side technology to take a crack at the file being handed over, or you will need to strictly specify which browsers are supported (things like FileReader are only IE10 or better).
I've never tried using the INPUT FILE to see if it will load a file before pushing it to the server (in say a FORM POST or a XHR/AJAX push)- but maybe look here:
https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications
Let's see -- what else. If the file has a specific name, your HTML could reference it in an IFRAME and see if you can't communicate back and forth between the IFRAME and the parent window.
You're really limiting yourself without having a server being able to process it, and the browser range you need. Your best bet might be the File API and restrict the lower limit of browser compatibility?
http://www.html5rocks.com/en/tutorials/file/dndfiles/
AFAIK, there is no way to do this for all browsers. Especially for IE8. If you need a standalone application, the best way is to use C++/Java/C# or any language that allows to create desctop applications.
When page-load speed is the priority, is it better to use a minimal, lightweight javascript library (hosted on a CDN), or is it better to use something like jQuery, hosted on Google's CDN that the browser more than likely already has loaded?
Edit: What my question really boils down to is whether the cross-site caching effect of using jQuery hosted on Google's CDN outweighs the benefits of using an ultra-light library, also on a CDN.
jQuery is not heavy as compared to any other javascript library at present looking at the amount of features and browsers it supports.
You can consider this factor while selecting the plugins to be used on the page because they are written by various users and some may right it intelligently considering this factor or some may just right it for the sake.
Yes, if you use CDN like Google for jQuery it is most likely that the library must be cached by the browser and also Google has number of servers based on location so you don't have to worry about it.
Decreased Latency
A CDN distributes your static content across servers in various, diverse physical locations. When a user’s browser resolves the URL for these files, their download will automatically target the closest available server in the network.
In the case of Google’s AJAX Libraries CDN, what this means is that any users not physically near your server will be able to download jQuery faster than if you force them to download it from your arbitrarily located server.
There are a handful of CDN services comparable to Google’s, but it’s hard to beat the price of free! This benefit alone could decide the issue, but there’s even more.
Increased parallelism
To avoid needlessly overloading servers, browsers limit the number of connections that can be made simultaneously. Depending on which browser, this limit may be as low as two connections per hostname.
Using the Google AJAX Libraries CDN eliminates one request to your site, allowing more of your local content to downloaded in parallel. It doesn’t make a gigantic difference for users with a six concurrent connection browser, but for those still running a browser that only allows two, the difference is noticeable.
Better caching
Potentially the greatest benefit of using the Google AJAX Libraries CDN is that your users may not need to download jQuery at all.
No matter how well optimized your site is, if you’re hosting jQuery locally then your users must download it at least once. Each of your users probably already has dozens of identical copies of jQuery in their browser’s cache, but those copies of jQuery are ignored when they visit your site.
However, when a browser sees references to CDN-hosted copies of jQuery, it understands that all of those references do refer to the exact same file. With all of these CDN references point to exactly the same URLs, the browser can trust that those files truly are identical and won't waste time re-requesting the file if it's already cached. Thus, the browser is able to use a single copy that's cached on-disk, regardless of which site the CDN references appear on.
This creates a potent "cross-site caching" effect which all sites using the CDN benefit from. Since Google's CDN serves the file with headers that attempt to cache the file for up to one year, this effect truly has amazing potential. With many thousands of the most trafficked sites on the Internet already using the Google CDN to serve jQuery, it's quite possible that many of your users will never make a single HTTP request for jQuery when they visit sites using the CDN.
Even if someone visits hundreds of sites using the same Google hosted version of jQuery, they will only need download it once!
It's better to use the library that best suits the needs of your application and your development team. A super-lightweight library might save you a few hundred milliseconds of load time, but may end up costing you in development hours if your team has significantly more experience with jQuery/MooTools/Dojo etc.
If new feature implementation and bug fixing is hindered by using a second-rate tool solely to improve load times, your users are ultimately going to suffer.
I have an idea a Web Application and I would need to list all files of a directory that exists on the client machine (For example C:\Temp).
I searched a lot on the Internet and as well on Stack Overflow. I couldn't find an answer on any questions that soved my problems.
I want to be able to list all files and subdirectories of a directory and if possible get the file type.
I know that this isn't able to do only with native Javascript. If there is something restricted to a browser like Firefox, like XPCOM I wouldn't mind using.
I just wanted to know what is the best approach to do this on a WEB Application. (Windows apps are not acceptable, and also don't want to rely on ActiveX since we're no planning on IE support).
We have a preference for Javascript based solutions. We really don't want to rely on Server-Side to do this. But we are opened to Server-Side suggestions.
For any server-side suggestion, we are using ASP .NET MVC.
We area looking for something similar to jscript - getting list of files in directory but I don't want to rely on ActiveX at all. As said before a Firefox-only solution would be OK.
In short:You can't get the control to list the files resides on local system(client machine) from browser.
Java applets, if signed and set up properly, can get access to the local filesystem if the user clicks allow on the popup dialog box.
Flash and Silverlight, being built by intelligent beings, do not allow you access to the local filesystem -- and if they did, they would also have a dialog pop up asking if the user trusts the web app. Otherwise people could use it to collect all sorts of potentially dangerous information about your system.
Besides the obvious benefit of placing the custom javascript files (or any other resource files) in a document library, such as:
versioning, history, tracking
easy to change/edit
Is there any other benefits?
Performance? Page Load time?
Are there any cons?
PS. This is not meant as a question on number of files / resources has a general HTTP performance, but rather this specific SharePoint issue on the file location.
http://site/_layouts/myjavascript.js
vs.
http://site/DocumentLibrary/myjavascript.js
If you are storing the javascript in a library then it is stored in the database.
It means that:
It has version control
It is slower then the filesystem (unless you are using blob cache)
It will be included in any backups you do of your sharepoint install (stsadm for example)
It will be accessible (changeable) by anyone with access to the document library (easier to maintain, less secure)
Client side caching will behave differently (you'll need to configure it, it's a bit complicated for MOSS content vs filesystem content)
We decided to store it in the 12 hive as it feels better in regards to code vs. data separation. If you consider this file to be data then store it in MOSS, if you consider it to be "code" then store it in the filesystem.
have you considered using google to host javascript files (such as jquery)
this benefits from using their bandwidth for downloading the files
faster page loading times
higher availability
chances are high that your javascript file is already cached on the user's machine
Document Library
Pros - Automatic delivery to all web front ends, easy, versioning, history, ease of editing
Cons - Slower (it's in the database),Security issues brought about by accidentally securing the item's site, login prompts if you are referencing the js via absolute URL your users may get repeated login prompts
Plasing the js file in the 12 hive
Pros- faster, no issues with the aformentioned security prompts
Cons - Not automagically delivered to all of your web front ends, possible AAM issues, technically you are not supposed to modify files in the 12 hive