Now we have a file-object, we need to split it in small chunks to upload this chunks one by one. JavaScript have the ability to work with files. It can’t access the filesystem directly, but the open- and save-dialogs will do every thing we need. To save data for more than one session you can use the indexeddb. But here we need only open,save and drag and drop.
function createChunksOfFile(file,chunkSize){
var chunks=new Array();
var filesize=file.size;
var counter=0;
while(filesize>counter){
var chunk=file.slice(counter,(counter+chunkSize));
counter=counter+chunkSize;
chunks[chunks.length]=chunk;
}
return chunks;
}
The method is very simple. The loop runs as long as the copied size is smaller as the size of the file. With slice(from,to) you have to set the start- and the endpoint, that is read (in bytes). If the endpoint behind the real end of the file no execption is thrown and only the existing part will be copied. That makes it very easy to us. With every run of the loop we add 250000 to the copied-size till our copied-size is greater than the file-size. In ervery run of the loop we copy/slice the bytes from copied-size to copied-size + 250000 and add this slice-chunk to the output array.
Finally we get an array with alle the sliced chunks of the file in correct order.
Yes.. you can calculate the needed count of chunks and than use a for-loop and calculate the start and end for every part. Works great too… but i did it the other way.
var chunks=createChunksOfFile(file,250000);
So we have all chunks each ~250KB. 1MB should have ~4 Parts. Yes.. it’s 1024Bytes per 1KB.. but we keep it simple :-)
A simple file-upload is easy to implement. A input-tag of the "file"-type. Set "method" to "post" and let the action attribute point to the target-page. Don’t forget enctype="multipart/form-data" and every thing is finished.
This implementation is very limited and in modern Web-Apps you want to do more than simply upload files. You want to scale, rotate and process the image. You want to see the progress of the upload and upload more than one file at once in the upload-queue. A few years earlier you had to use flash.. but flash is dead. Today we use HTML5 + JavaScript. With ist you can do what ever you want to do. The File-API helps you to load local files per input or drag and drop. A web-notification informs you when the upload is finished… very helpful if it is a very large file.
This file-upload that is created in this posts is not perfect, but it works in many of my projects and scripts. The target-script can be implemented very easy in PHP or as a servlet.
For a simple test you can use this PHP-script:
PHP:
<?php
//see $_REQUEST["lastChunk"] to know if it is the last chunk-part or not
if(isset($_FILES["upfile"])){
file_put_contents($_REQUEST["filename"],file_get_contents($_FILES["upfile"]["tmp_name"]),FILE_APPEND);
}
?>
for Java you can use this (FileIOToolKit is a class of my own, it simply adds a byte[] to the end of a file or creates the file, if it doesn’t exist):
String filename = request.getParameter("filename");
for (Part part : request.getParts()) {
if (part.getName().equals("upfile")) {
byte[] out = new byte[part.getInputStream().available()];
part.getInputStream().read(out);
As you see, the files aren’t uploaded at once, but in multiple parts. So ist is very easy to track the progress of the upload.
To load a file in HTML5 is very easy. Drag and drop or the OnChange-Action of a file-input element delivers you a event, that contains a list of files.
Here is simple example to get the files from the event. The two events from the input and the one from the drag and drop are different.
var files = null; // FileList object
if(!nodragndrop){
files=evt.dataTransfer.files; //input
}
else{
files=evt.target.files; //drag and drop
}
But we don’t care about this part of loading and starts where we have the file-object. You also can create a binary-blob from an data-URL (from a canvas for example).
A few month ago, i wrote a post about the situation between JavaFX and HTML5 and their positions in the fight for the next leading GUI-technology in the Java world. I said, JavaFX is only interessting to improve existing Swing application but not the right thing for the developing new applications.
I can fully agree to this point of view. There are greater problems than the technological difficults and the few bugs and problems with the implementation of some JavaFX parts. The greatest problem is the missing support by Oracle. JavaFX for mobile devices is only supported through 3rd party solutions like RoboVM. Scene Builder is not very stable or bugfree. With only simple changes in a FXML, you can cause troubles that Scene Builder is not able to ... it crashes or only shows an empty screen.
You have to wait month for new versions or simple bugfixes.
Oracles own applications use Swing or are webbased. The change from Swing to JavaFX was often proclaimed, but never came to the surface or was visible in any other way. Swing has an extensive repository of mature and feature-rich components. It isn't easy to replace them in a short time range. A simple migration isn't that simple and would took a lot of work. You know that you can open JavaFX scenes in a SWT application. I used it, but it isn'T realy a good integration. It is only a canvas, where the JavaFX scenes is drawn on. No real interactions between the two worlds. It like the WebView in JavaFX. Yes you could write an application in HTML and JavaScript an use JavaFX as an wrapper.. but.. why? An IE11 should be a better solution than this.
The usage of Swing disappeares slowly, but there no new JavaFX applications to repalce them. There are a few JavaFX fans, but i think they only exist, because Swing is deceasing. Since i begin to programm in Java i wrote a few Swing applications and the first contact with JavaFX was more than disillusioning. Netbeans + Swing working great and every thing works very well. Scaling of the GUI works good. In JavaFX you can implement it too, but it isn't as intuitive as with Netbeans. The CSS-implementation in JavaFX is not comparable with the CSS we know from HTML.
Why JavaFX 2 wasn't accepted well? In my oppion, the reputation was bad, the support was insecure in version 1.0.
When version 2.0 arrives, most developers found a other or better solution with better support and more promising future. So the support from the developer-side was missing and without this every thing only works on a minimal level to save the resources for more promising projects.
JSF 1.x wasn'T that good, but there was no doubt, that it will be supported an new version will be developed. I think that Apache supported JSF, was a big advantage. And the newest versions are great. Maybe JavaFX can go the same way with more support.
So i support the conclusion: If oracle will invest more resources in JavaFX more developers show interest and so it could be a future with JavaFX.
I can't understand the fear that without JavaFX the JEE market could be damaged or it can lose it's impact in the developer-environment. Node.js could be a threat, more than php, but in the last years the JEE-market grow with microservices, middleware-services for android-apps, reactive-development and frameworks like node.js. REST-services, web-portale-solutions, small containers, websockets und push-services in the Tomcat servlet-container. Very nice and the movement doesn't stop till now. The big Topics of the last years.. Desktop-GUIs wasn't a topic. And with the great Java webframeworks, HTML5 and AngularJS the client-side won't be losed. JEE and Web-Clints work great together.
The lose of a few desktop application won't hurt, when you get new shiny web-application based on Java technology.
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?