DojoX FileUploader Upgrade to Support Flash 10

By on December 1, 2008 2:00 pm

I’ve just completed the upgrade of the DojoX FileUploader to make it compatible with Flash Player 10. The FileUploader widget allows for the uploading of more than one file at a time, which is surprisingly still not supported natively by any web browser on the market today.

In Flash versions 8 and 9, a file upload Browse Dialog could be launched using JavaScript code. Users could click an HTML button, which would call a JavaScript function behind the scenes, communicate with a Flash (SWF) file, which would then trigger the browse() method in the SWF. The latest Flash Player has a security feature where the user must click within a Flash-based portion of the user interface to launch the Browse Dialog. This change is to prevent malicious code from continually opening the dialog without user interaction. Working toward this upgrade was a major undertaking that involved a significant rewrite of FileUploader. The results are a success, and in addition to working with the tightened security policies, it was a great opportunity to add many new features:

  • Degradable
  • CDN Support (see below for cross-domain restriction details)
  • POST Data Support
  • Custom Field Name Support
  • Full Event Support
  • Exposed CSS Positioning
  • Dialog Container Detection

Degradable

As it worked before, the FileUploader detects if the browser has the Flash plugin version 9.0 or greater installed, and if so, initializes the Flash FileUploader. If not, a conventional fileInput is used. You can always set the force parameter to either “flash” or “html” to require a particular version of the FileUploader and override the detection. By default, force is an empty string, triggering the detection.

CDN Support

Dojo’s CDN is very important system for the Open Web, but occasionally there are issues since the JavaScript is being served from a different domain than the page launching the code. This is compounded by security restrictions within Flash. The FileUploader embed code now contains the proper parameters to enable communication and execution between the FileUploader SWF and JavaScript belonging to different domains:

allownetworking="all"
allowscriptaccess ="always"

However, there are still limitations to what can be done over the CDN. The SWF must be from the same domain as the HTML page – it will currently not work with the SWF on the CDN server. We’re still investigating possible solutions for serving the FileUploader SWF from the CDN. In the meantime, the swfPath parameter has been exposed so that you may link to a local SWF, which of course could be the same SWF downloaded from the dojox/form/resource folder.

POST Data Support

You can now pass in POST data that will be posted to the server along with the Flash uploaded files. Previously, this could be done by appending variables to the URL, but that was unreliable. I’ve tapped into the Flash feature that appends the data for you:

//ActionScript
request = new URLRequest(uploadUrl);
request.method = URLRequestMethod.POST;
request.data = getPostData();

Additionally, if the HTML FileUploader is used, the postData object will be converted into hidden fields and posted to the server.

Custom Field Name Support

You can now specify the field name that the server expects to find the files. Flash defaults to using the Filedata field name for the files, which is fine if you are customizing the server or building it from scratch. But naturally, some systems are already in place and such a change may not be desirable. Simply set the flashFieldName parameter, and that’s what will be sent. The htmlFieldName is used for the HTML version of the FileUploader.

Full Event Support

I went to great lengths to expose as many events as possible. All the mouse actions have event methods that can be connected to, since they are already used for emulating the hover state of the ‘fake’ button — the styled button that acts as the stand-in for the actual upload button. The canceling of the dialog window is captured in Flash, and passed to a method in the FileUploader. In order to mirror that functionality with the HTML FileUploader, I noticed that the onMouseOut() event of the fileInput does not fire until the dialog is closed. By checking that a file was not selected, I can create a pseudo cancel event and pass that to the onCancel() method.

Exposed CSS Positioning

Now that the Flash FileUploader has to use the same CSS hacks as the HTML FileUploader, it was more important than ever to get the positioning right. It’s been tweaked and massaged, and I have it working for several different use cases. However, because of the nature of this “hack”—floating a zero-opacity fileInput or a transparent SWF over a “fake” button—this won’t work in all circumstances. For instance, the uploaders won’t work properly in a scrolling div. CSS rules can unexpectedly cause placement issues. Placing the FileUploader near the bottom of a complex document can throw off the positioning. The positioning methods have been exposed for overriding in these cases. The setPosition() method can be called whenever there has been a screen redraw that may upset the placement. For certain cases not covered, it’s just a matter of replacing the setFlashPosition() and/or the setHtmlPostion() and using your own code.

Dialog Container Detection

In my experience, a very common use case for the FileUploader is within a Dijit Dialog. I’ve written a script that walks up the DOM tree and checks if the ‘fake’ button is a child of a Dialog. If so, the show() and hide() methods of the Dialog are connected to—since we don’t want an invisible Upload button floating around our document. The dragging of the Dialog box also triggers the setPosition() to keep it in place.

Summary

File uploads are common on the web, but browsers still provide a poor user experience for multiple-file uploads. The SitePen and Dojo teams are striving to make it as easy as possible to implement a great experience for your users. The new DojoX FileUploader will be available in the forthcoming Dojo 1.3 release, any Dojo nightly build, or from Dojo’s Subversion repository. Please send us your feedback and feature requests, or if you need assistance implementing this within your application, check out our support and development services.

Comments

  • Pete

    Mike, is it possible to use flash.html.HtmlControl to render the “fake” button, the host page could pass it in? Would it avoid some of the layout problems?

  • That’s an intriguing idea and would be quite a morph of the two technologies (which I’m interested in). But in this case it wouldn’t help, as we still have to rely upon the browser to tell us what the x/y coordinate is of the button, or the placement of the object rendered in this case.

  • Franz

    Uh oh, I’ve just run into a major problem in my use of FileUploader: Flash doesn’t seem to be sending cookies, so I can’t authenticate the upload request! I’m using a Java servlet, and I need the jsessionid cookie to identify the logged-in user. Is there a switch you can set to make it send cookies?

  • Franz

    Oops, another problem, though much less serious: the Flash uploader silently ignores zero-length files. I was baffled as to why some files weren’t uploading until I noticed their sizes. This is likely to confuse users, too.

  • ben

    hey, i was just in the middle of coding the same thing – so glad to see you’ve already done it.

    was also just running into the session ID issue today. haven’t implemented yet, but am planning to output the session ID as a param sent to flash – and then have flash send the ID back to server as a POST var. then will have to do a slight mod on the server to have it tell php that that var is the session id.

    here’s a relevant post:
    http://bytes.com/groups/php/525560-flash-php-session

  • The uploader not sending cookies is a Flash bug:
    http://bugs.adobe.com/jira/browse/FP-201

    Headers can be sent in an UrlRequest Header, but I don’t know if it would work around your problem, as it is very restricted. The way I had done it in the past is to get the user and session IDs and pass those as vars along with the upload. That’s why I implemented the postVars in the latest version.

    Zero-length is also a Flash issue:
    http://bugs.adobe.com/jira/browse/FP-510
    You could possibly catch that one as you select the file in the onChange handler.

  • Franz

    It looks like the new FileUploader isn’t part of Dojo 1.2.3, since I’m getting errors with Flash 10, and I can’t find any mention of postVars in the source. Is it scheduled for Dojo 1.3?

  • Sorry, I don’t think I mentioned that. Yes, it’s checked in and scheduled for Dojo 1.3. It’s currently available in the nightlies and svn.

  • Baycik

    Great work! But there is some work to do. onComplete handler does not fires. It is important for me because i cant handle server response. Strange thing, when i hit button second time error occurs

    “invalid property id”

    try { __flash__toXML(dojo.publish(“uploader_0/filesUploaded”,[[({modificationDate:new Date (1231956659687),height:NaN,type:”.xls”,name:”14.01.2009_DataFrom_prod_prices.xls”,width:NaN,creator:null,{“type”:”success”:undefined,creationDate:new Date (12319566

    Thanks in advance.

  • hasan24

    Hi,
    I have a question about the UploadImage functionality provided via the dojox.editor.plugin.UploadImage (theoratically creates and icon in the editor through which an image can be uploaded). When it browses for the image through the file system, does it invoke the client’s file system or the server’s. And is there a working example of uploading an image using dojo (without going to the server since the application under investigation does not support a POST method).

    Thanks

  • coldfire22x

    I have been using 1.3.0b1 as well as the nightly builds but continue to have problems where the fileMask is not effective on the first load. On subsequent loads the fileMask is evident but disappears after clearing the cache and reloading the page.

    http://bugs.dojotoolkit.org/ticket/8667

  • @coldfire22x: Thanks for the report. ExternalInterface in Firefox seems to fail occasionally, even when the SWF is loaded and communicating with the JavaScript. If to-SWF comm fails, I rebuild the SWF. That seems to work.

  • Stefan

    Same problem as many – onComplete does not fire. Furthermore, none of the “demos” that people put up seem to work, upload is stopped at 43%, 64% or whatever, or not started at all. On my system, I can get the fileuploaded ok, up to 100% and the files arrives, but without onComplete it is a bit of a gamble.

  • @Stefan, I can’t recreate your problems. onProgress and onComplete are firing for me. Perhaps it’s the *type* of file you are uploading? I haven’t tested all file types. I’ve uploaded a test file here (same from dojox) that has debugging turned on, and I log the progress and completion in the fields:
    http://mwilcox.dojotoolkit.org/dtk/dojox/form/tests/test_FileUploader.html

    And this demo works:
    http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html

    @hasan24: Sorry for the long reply wait. The uploader looks at the file system of the client, not the server. There isn’t currently an uploader that works without using a server. I know Flash has support for that in v10, but it has not been implemented.

    @Baycik: I’m sorry I’m not able to recreate your problem either. I tred several different file types thinking that was the problem.

    What “demos” are not working?

  • Stefan

    @mwilcox, I tried both links you postd and none of them works, unless the file(s) is tiny tiny.
    Typical it stops like this:
    (17%) DSC_0206.jpg
    (12%) DSC_0116.jpg

    (files around 500kb each)

    I have only tested on FF3 (don’t know Flash version) but the whole thing looks a bit shaky. I made two different implementations and they both behave different. In one I can only select one file at the time, but send many (and that one does not send the post data). Code and parameters for both are the same.

    Sorry about not being very specific, but it is confusing. The server sees this on one:

    FIELDNAMES: UPLOADEDFILE0,UPLOADEDFILE1,UPLOADEDFILE2
    UPLOADEDFILE0: C:\ColdFusion8\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\neotmp32995.tmp
    UPLOADEDFILE1: C:\ColdFusion8\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\neotmp32996.tmp
    UPLOADEDFILE2: [empty string]

    The other one is sending them one at the time:
    FIELDNAMES: FILENAME,POSTDATA,FLASHUPLOADFILES,UPLOAD
    FILENAME: DSC_0196.jpg
    FLASHUPLOADFILES: C:\ColdFusion8\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\neotmp32940.tmp
    POSTDATA: Add Post Data Here
    UPLOAD: Submit Query

    I use selectMultipleFiles:true on both

  • @Stefan: Read my blog on State of Uploaders. I wouldn’t say the whole thing is shaky, but it is a workaround for something that the browsers should have given us years ago. I uploaded a large file and it worked. I suspect there was a server hiccup of some sort (dtk is very maxed out at the moment). But the demo isn’t about the server side, nor do I claim to be writing top notch server-side code.

    It looks like your first case is using the HTML uploader, and the second is using Flash. There have been a lot of options added to the uploader in a very short time. I’ve done my best to comment the code to make it as clear as possible.

    If you need more help, email me at mwilcox AT sitepen DOT com.

  • Stefan

    Hi again. I tried to mail you at the at the address above, and I also had some of my editors testing the demo, and it works for none of them. Maybe it the the Flash version, maybe it is something else, but it simply does not work. In IE7 it fails completely and the page crashes (for all 4 that has tested) and on FF (three tests) it happens as I described above (onComplete fails).

    I have made a Flash uploader a while ago but it was only single files (huge files that needed a progress bar not to confuse the editors) and will see if I can make it into a multifile.

  • @Stefan: Sorry I didn’t email you back. I thought you said you were going to try something on Monday. You are in fact right about IE – some fixes I applied for FF made IE worse. I did more changes and then did extensive testing on all browsers, and things seem to be working.

    Glad to hear your going to build your own uploader! Please let me know what we can do here to improve the DojoX uploader. In email. I’ll reply.

  • Macs

    I think someone is using dojo included in Zend Framework that does not have this library in the package:
    require(“../../dojo/tests/resources/JSON.php”);

    I’ve downloaded it and now it works something..
    I’ve problems with flash player 10.0.12.36 and multi file
    upload.. the swf seems too loop.
    On the page test_FileUploader.html I get this log loop:
    this.movie.load FAILED – rebuilding….
    pergent loaded 0%
    this.movie.load FAILED – rebuilding….
    pergent loaded 0%
    this.movie.load FAILED – rebuilding….
    pergent loaded 0%
    ecc…

  • @Macs: Have you downloaded the latest from the SVN? I just fixed that problem. It will be in the 1.3 release.

    The JSON.php should affect what you are referring to. That file is to assit the UploadFile.php server page.

  • Macs

    I’m running the test at page:
    http://archive.dojotoolkit.org/nightly/dojotoolkit/demos/uploader/demo.html
    so I think it’s the last available, but the problem persist.
    I’m usign firefox 3.0.6 and flash player 10.0.12.36

  • @Macs: Sorry for the problems. I am struggling with this particular bug right now. However, it still looks fixed to me. What you are seeing only happens once for me, and then the SWF rebuild is successful. Rebuilding is being forced because the ExternalInterface failed to initialize properly.

    I’m not sure the demo works properly in the archive. I know it’s missing a folder for some reason.

    Try the demo here:
    http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html

  • All:
    I found the problem. There needs to be a small amount or time between the creation of the dom node and the creation of the embed object that gets inserted into that node. In FF the SWF was created twice for some reason, causing the intermittent EI confusion. In IE it would just blow up. dojox.embed.Flash has a fix in it, using a timeout and addressing this problem. I removed all of the “rebuilding code”, and ran a bunch of tests with a 100% success rate. Things should be good to go.

    I’m hoping this might also address the onComplete problem that some people are having (that I’m afraid I still can’t recreate)

  • Macs

    Don’t worry and thank you for your efforts. ;)
    When the test’s page is available again, I’ll test the new solution.

    In the mean time I’ve found a problem trying to include dojox.form.FileUpload in my application. If I don’t include dojox/form/resources/FileInput.css, nothing shows if I click on the select file button. I don’t know if this is the correct behavior, or it was clear that there is this dependency, but I hope this message will save time to others.(or someone will point me what I’m doing wrong)

  • Phil Bowles

    Mike I NEED this onComplete problem solved…and I read that you can’t reproduce it – which makes it kinda hard for you! So I hacked some 1.2.3 code and put in some console.log/warn stuff and did some of my own digging. I’m pretty new to both dojo and javascript,..so probaly 99% of this will be teaching you to suck eggs, if so apologies in advance.

    I took your demo code, and pointed the uploadURL at my own upload PHP handler (which works fine) and I set debug:true

    Here’s the trace in IE7:

    EXPERIMENTAL: dojox.form.FileUploader — APIs subject to change without notice.
    EXPERIMENTAL: dojox.form.FileInputOverlay — APIs subject to change without notice.
    DEBUGGING VERSION
    Flash version detected: 9
    Relative loc: http://tta2/ abs loc: http://tta2//code/v6/uploadhandler.php?pic=dummy_l
    . Uploader Starting
    . name: root1
    . selectMultipleFiles: false
    . selectHandler: name=New Text Document.jpg URL=http://tta2//code/v6/uploadhandler.php?pic=dummy_l
    . listSelectHandler [Event type=”filesSelected” bubbles=false cancelable=false eventPhase=2]
    onChange.data: [[object Object]]
    Add Post Data Here
    upload pre flash movie 666
    . tell upload…
    upload post flash movie 666
    test.onProgress [[object Object]]
    . listCompleteHandler

    I have some of my own observations:
    1. the uploadURL won’t work if it has ?a=b&c=d type GET data attached. I see that this is due to the way you have to patch it into the embed code for the swf, but it would be nice for the future. (I’m guessing thats what the “postdata” stuff is about – I can’t get that to work tho – probably me being dumb, will report later)

    2. after the above trace, IE7 shows an error message (in its usual crappy and unhelpful fashion…but for what its worth, im using the 1.2.3 src build and the error is: L:ine: 1 Char: 296 Error: Expected Identifier, String or Number Code:0)

    FF shows no errors at all, so there may be some cross-browser issues. Timing-wisethe IE erro occurs a second or two AFTER the last debug message re listcompletehandler.

    3. I see you use publish / subscribe to manage the progress / complete events etc. I’m guessing that the swf somehow “fires” these, but I know FA about swf…i tried a decompiler and got as far as deft.form.uploader etc but got lost after that…what I CAN say is that with the other traces I have put in…that onComplete publish event just ain’t gettin fired. My 2c says there is something amiss in the swf / deft / dojox eent management interface side of things.

    4. another 2c says its a timing issue – several reasons: 4.1 if a man of your calibre (and the author of the code) can’t find it afetr the amount of chat about it here…then it’s pretty well hidden! 4.2 you mentioned a timing issue in the embed phase which you already fixed 4.3 I think there are some other unresolved timing issues as I SOMETIMES get ‘PercentLoaded() is not a function’ in FF (after which, nothing else works) and…sometimes I don’t, whereupon it all does, (except the missing onComplete eent of course!)

    5. A Quick’n’dirty fix…why not “force” the “onComplete” aftre an onProgress with 100%…aftre all the complete code already calls onProgress…just add “if(percent==100) this._complete” (or whatever)

    hope some of this helps….I’m still digging

    Phil

  • Phil Bowles

    Here’s the weird thing…FF seems to detect flash 6…and with debug:true won’t load the swf at all:
    ……
    DEBUGGING VERSION
    Flash version detected: 6
    Relative loc: http://tta2/ abs loc: http://tta2//code/v6/uploadhandler.php?pic=dummy_l
    this.movie.PercentLoaded is not a function
    [Break on this error] if(this.movie.PercentLoaded() == 1…0 || this._pollCount++ > this._pollMax){
    /code/do…/Flash.js (line 258)
    this.flashMovie is null
    [Break on this error] if(this.movie.PercentLoaded() == 1…0 || this._pollCount++ > this._pollMax){
    /code/do…/Flash.js (line 258)
    this.movie.PercentLoaded is not a function
    [Break on this error] (666 out of range 456)

  • Hi Phil, I’ll do my best to work this out.
    Are you using the latest version? The Dojox FileUploader from SVN has all of the latest bug fixes. I log the data received from the upload script. From what I can tell by others who have reported the problem, the error is because Flash is parsing a string int an object. If the string doesn’t create a parse-able object it’s not going to transfer into the JavaScript environment properly.

    This message should be showing before you see “. listCompleteHandler”:

    . File-uploadCompleteDataHandler: event=[DataEvent type=”uploadCompleteData” bubbles=false cancelable=false eventPhase=2 data=”Filename=MikeHalo.png,postdata=Add Post Data Here,Upload=Submit Query,file=../resources/MikeHalo.png,name=MikeHalo.png,width=167,height=125,type=png”]

    Everything in data=”” is what gets parsed into an object. If it doesn’t form an object, it will cause an error in the Flash EI, and that error is not always shown (FF) or is cryptic (IE).

    I do see a potential upgrade, that if the text doesn’t parse into an object I can pass the text instead.

    I’m not sure why you are seeing Flash 6 as a version. Where is that coming from? And are you sure it’s not Flash 6? (Sorry, I know it’s a silly question).

    BTW, Dojo is open source, you don’t need to pull the SWF apart! You can see the SWF code here:
    http://bugs.dojotoolkit.org/browser/deft/trunk/deft/form

  • Macs

    Ok I’ve sorted out all the problems,
    hope this will help everybody with the “onComplete” event.

    The event is not fired because the “onComplete” get an error when execute this line:
    dataArray[i].name = dataArray[i].file.split(“/”)[dataArray[i].file.split(“/”).length-1];

    the error in my case is due the fact that dataArray does not contain my data but an exception raised by dojo.io.iframe.send() used in method upload(). So on dataArray[i].file you get an error because element .file does not exist in this case.

    I think that everybody get that because dojo.io.iframe.send() require that you have to wrap your json response in a textarea.
    Don’t ask me why, I can only think that it’s a poor implementation or a that if you have this requirement you have to write it in BIG letters.

    So I wrote my response like this:
    $j = Zend_Json::encode($ar);
    $response = $this->getResponse();
    $response->setBody(“”.$j.””);
    and finally works.
    No more errors and onComplete fired.

    One last thing, this line:

    dataArray[i].name = dataArray[i].file.split(“/”)[dataArray[i].file.split(“/”).length-1];

    is to obtain the name of the file without the path. But this will not work if you are on a windows system and you use a path with “\”. It will not get an error but you’ll get the file name with all the path.

    good luck ;)

  • Macs

    I forgot to mention that the above line is in dojox/form/FileUploader.js and it’s in the HTML file uploader not the flash one.

    I think that the onComplete needs some exception handlyng code to prevent future similar problems.

  • @Macs:
    Thank you for the information. I went through the code and you’re right – I’m not emphasizing the need for a textarea on return. I’ve put it on my TODO list to update comments and documentation.

  • Macs

    the line :

    $response->setBody(””.$j.””);
    was:
    $response->setBody(””.$j.””);
    the blog eat it. :D

    And I was wrong about the textarea issue with dojo.io.iframe.send. It’s required because html response is required to handle document loaded event as stated in this page:
    http://docs.dojocampus.org/dojo/io/iframe

  • Macs

    again
    “[open tag]textarea[closetag]”.$j.”[open tag]/textarea[closetag]”

  • Ken Petri

    I realize dojox is pushing the envelope, but having a button that can be focused but not triggered via the keyboard alone (in browsers other than IE, that is) seems problematic, especially in a toolkit such as dojo, where accessibility is high on the list of requirements.

    I also realize ExternalInterface security changed in v.10 of Flash and that has necessitated work-arounds.

    But is there any chance of making this keyboard accessible? Should I look elsewhere for other solutions? (like to the PHP 5 pecl upload progress extension? We’re developing in PHP, so it’s okay for us to use this, but we would rather have a solution that is not tied to a particular PHP extension….)

  • @Ken Petri: It’s an excellent idea to make the uploader a11y. It shouldn’t take long to implement, but I’m afraid I’m quite slammed at work at the moment. I created a ticket and will get to it as soon as possible:
    http://bugs.dojotoolkit.org/ticket/8908

  • Stefan

    Mike, I am getting a bit confused here :)
    Only way I find to make the events working is to have the file uploader return ‘true’ after successful upload. But what if the server needed to rename the file? Is there any way to get the server response back? If I have my server to return the new filename, I see that it is given to the SWF and is understood, but then the events (all of them) is crashing.
    I managed to get an error message like:
    try { __flash__toXML(dojo.publish(“uploa…arsandtone5.jpg:undefined,size:14254})],
    Looks like it expects a struct, but if I return a struct it becomes even more unhappy…

  • Hey Stefan.

    I’m confused! There are several parts to this that could be the “file uploader”. But it sounds like you are talking about the return from the server?

    The server can return anything (I don’t know f it can send ‘nothing’ however). My early tests I renamed the uploaded files all to the same thing, like UPLOADED.JPG. So that shouldn’t matter. The only thing it may affect is knowing which files were selected compared to which were downloaded.

    The crash indicates that the return is not formatted properly. Flash expects a string of comma delineated key-value pairs. If that doesn’t parse because of characters it doesn’t expect, it will choke the Flash to JS interpreter.

    Are you using the latest version fro the trunk or 1.3? I’m trying to catch errors like in the SWF and report them.

  • Stefan

    Mike, thanks!
    That was it, a string of comma delineated key-value pairs. I tried to return JSON, normal string and booleans. The only thing that works was booleans. But key value pairs works perfectly. Sorryif I missed that in the documentation somewhere. I made some changes in the fileUploader.js also, will send then to you.

  • Hi,

    I’ve experienced some problem under FireFox 3 if the button is inside a SplitContainer (into the right pane in my case). The button doesn’t highlight and the mouse click does absolutely nothing.
    For information, when I rigth-click, the flash contextual menu is opened at then wrong place into the page… Maybe this is related to my problem.

    How can I solve it, please ?

  • Igor

    Hi
    i have one problem with multiple files attach.Code is same as in example, button btn0 is attached to fileUploader f0. When I select more the one file and click on upload it is send only the last one. Probably i am missing something here. Can you help me with this? What can be the problem?

  • @Igor:

    Are you referring to HTML mode? It sounds like instead of adding fileInputs to the form it is overwriting the last one. Otherwise I can’t quite figure out what may be wrong based on this information. Try double checking your settings with the docs on DojoCampus which I updated recently.

    http://docs.dojocampus.org/dojox/form/FileUploader

  • ofr

    Great work, but two questions:

    Could you please mention somewhere that the CSS files have to be included manually? First, I forgot, and the result was very… strange! Even clicking the button doesn’t work then (of course).

    Second: I need to upload files to a server platform that doesn’t support multiple uploads at the same time, as something needs to be locked during every single upload. Using flash, all files get uploaded simultaneously, resulting in upload errors. Would it be possible to upload files one after another, using a switch or something?

  • @ofr:

    No excuse for not documenting the need for the CSS. I’ve updated the Campus Docs with a Dependency section:
    http://docs.dojocampus.org/dojox/form/FileUploader

    I wish I could accommodate you on the second one. But that’s very custom, would require some work, and could introduce the possibility of more bugs. And it kind of goes against the whole point of the Multi-Uploader if they don’t all upload at once.

    I know it’s not a great solution, but I would recommend a single-file upload, one at a time. Or, you could utilize the HTML uploader which would be easier to make custom modifications.

    Note the files don’t technically get uploaded at the same time; actually the HTML uploader does this, Flash does not. Flash throws them all at the server in separate uploads, and they upload simultaneously depending on the browser and number of uploads (you probably know this). I point this out because perhaps if you have control on the server side, you can block the uploads and allow them to finish incrementally. This would hold each process open – you couldn’t cancel or defer them since the Flash is expecting a return (an echo or print of data).

  • ofr

    Thanks for your reply. Considering simultaneous uploads, I can understand your point of view, even though IMO uploading the files sequentially is not against the nature of a multi uploader at all. The user may want to select some dozens of large files and then upload and leave, have a coffee. This doesn’t imply that the browser has to torture the server with dozens of requests at the same time, does it?
    This server process blocking that you propose is an interesting idea, but a bit too much work in our context. Besides, I think it’s the wrong side to solve the problem. Forcing the client to wait is better, because a paused request on the server leads to an open connection. Most servers limit the maximum amount of open connections, and in fact, these paused connections are pretty useless…

    Unfortunately, I also found out that multi upload doesn’t work as I expected it to do. Looking at you demo at http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html?multiMode (I hope that’s a recent one), I can see the following (both FF3 and IE8) phenomena:

    1. HTML mode, multi-file: I can select multiple files one after another, and they show up on the first list box. When I click upload, I get progress callbacks for all, but only the last selected one is actually transmitted. LiveHTTPHeaders tells me the same…

    2. Same thing with Flash: Here, I can select multiple files at once, but only the ones selected last (those from the last time opening the browse dialog) are really uploaded.

    Is that behaviour intentionally?

    Thanks,
    Oliver

  • @ofr:

    I checked the demo and HTML does in fact look broken, and only uploads the last file. Flash seems to work correctly.

    Oh. For Flash I think I know of what you are referring. A subsequent opening of the Flash browser dialog wipes out the previously selected files. I’m in the process of a major upgrade to the FileUploader that I’ve been doing on weekends, and this is one of the bugs that I’ve fixed. I hope to have it done in the next 1-2 weeks. I’ll definitely have the HTML uploader up to snuff, as well as other bugs.

    I made a note to investigate the difficulty of your request, but I can’t make any promises since it is a custom request, although I’ll think it over on whether this is maybe something of use to others. If I can implement an iterator without too much difficulty I’ll throw it in there.

  • Igor

    mwilcox
    thanks for reply. It works now fine, i set uploadOnChange to true and it is ok. But :) i have other problem, when i do remove files, somehow fileUploder remembers files i deleted. Is there way to clean fileList?
    Thanks

  • @Igor:

    Good to hear!

    Removing of selected files from the upload list is coming in the next version which should drop in the next week or two.

  • Igor

    @mwilcox
    is there any other solution for now? When i put fileUploder.fileList to null then i have strange behaviour for file upload.

  • @Igor:
    fileList is (and should be marked as) private. It’s tracking what is going on inside the swf. Modifying that array will just break stuff.

    Fortunately someone requested this already, so the code is underway.

    I guess a workaround would be to destroy and recreate the swf.

  • Igor

    me again :)
    if i put fileUploder to force: “html” then on the page it is shown input text and upload button but somewhere on the page. How can i control this that button i already assigned works also for html as for flash type of fileUploder? If it is possible to point me or if ther eis some explanation on web about it?
    Thanks once more :)

  • @Igor

    If I understand correctly, the HTML input is not placed correctly? There is a setPosition you can override or connect to.

    However, if you can wait a few more days, the new 1.4 version will be in the trunk this weekend. You’ll be able to remove files as you requested, and it fixes dozens of bugs. The positioning works much, much better.

  • Igor

    @mwilcox
    Thanks for fast response. It is just that when force: “html” is set I have extra big button and input text on bottom of the screen and button to which fileUploder is connected it doesn’t work but that new html one works.

  • Igor

    oh yes and in example which is on this url http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html when i choose html mode i can not see that big button and input text. How is possible to do that?

  • @Igor, it sounds like you’ve got a problem in your code. We can’t do debugging in blog comments. If you need help send an email to the Dojo mailing list or email me directly. mwilcox(AT)sitepen(dot)com

  • Brahose

    @mwilcox
    I was able to view the demo of the flash multiupload a few weeks ago @ http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html . Everything worked great, but now when I visit the site, the flash will not load. I tried in both FF3 & IE7. Thanks.

  • Brahose

    I am also curious if you the upload control has any functionality for pausing/resuming the upload. Is there a way to break the stream into different segments so that partial uploads can be implemented?

  • ofr

    @Igor, I had the same problem when I forgot to include the CSS…

  • Brahose

    Do you have the .fla file for the swf? or is there some way to compile the as files into the swf without having to create a new flash project?

    Thanks in advance.

  • ofr

    @mwilcox

    I noticed your commits over the weekend. Great stuff… You even implemented that deferredUpload feature for Flash! Thanks a lot! That means we’ll be able to use the Flash uploader with Dojo 1.4 :-)

  • ofr

    @mwilcox

    I have identified a bug in IE8, HTML mode. It creates one input too much and transfers it to the server. Of course, without any contents….

  • Thanks ofr.

    I knew that bug was there, but I thought it was a server-side bug and was catching empty “files”. But with your comment, I realized that on submit, there is an extra fileInput created, waiting for the user to select another file. This empty input was being submitted.

    I destroy that input before submit now, and it’s been committed. Go ahead and update.

  • ofr

    Updated, IE8 works in HTML mode now. These are the good news…

    Unfortunately, I can’t get Flash in IE8 to work! The flash movie simply never gets initialized. In Firefox, everything is fine. Strange enough, your demo works well with the same IE8.

    Is there any kind of Flash logging that one can turn on to see what happens?! I tried the Dojo isDebug mode, but the console just says “start flash…”, nothing else.

  • Yes, pass in isDebug:true as a parameter of FileUploader. You could also tie it to the djConfig with isDebug:dojo.config.isDebug.

    There used to be a devMode switch as well, but that’s deprecated and doesn’t do much with this version.

    Also look at the FileUploader method “createFlashUploader”, and uncomment the logs at the end of it for onReady and onLoad.

  • ofr

    Er…
    I only included parts of DojoX to avoid bloating up our source code repository, and, well, I simply forgot the “dojox.embed.IE” folder on my way.

    Have I already mentioned that I love IE and all its specialities? ;-)

  • ofr

    Me again… Today, with a question about fileMask.

    I noticed that it doesn’t get applied in HTML mode, even though could take an “accept” parameter AFAIK. Unfortunately, it expects mime types instead of extensions, but that could be solved by a more lenghty fileMask definition.

    Have you experienced problems with “accept”, or are there other reasons not to set it?

  • Last I looked, HTML fileMasks aren’t supported in any browsers, or it’s shoddy at best. I think there are a few cases of some support that doesn’t actually work IIRC.

    I know WebKit will have something in 4.0, and FF probably in 4.0 as well. Opera has support, but because of the small market share I didn’t work it in.

    If you have some new information, please post it!

  • Ljacquin

    Hi Mike,
    First of all, I would like to thank you for the dojox.widget.FileUploader widget. That’s a good work !

    But I am facing an issue that I can reproduce on your demo site today (2009-06-24 11:43:00 (GMT+01:00)) :
    http://mwilcox.dojotoolkit.org/dtk/demos/uploader/demo.html

    1. Select a list of image files (-> file names are added to the list, no problem)
    2. Click on “upload” button (-> files are sent to the server and then displayed in browser, no problem)
    3. Again, select another list of files (-> file names are added to the list, no problem)
    4. Click on “upload” button : only the first file in the list is sent to the server and then is displayed in brower … :(

    In thelast case, it seems that the filesuploaded topic is fired after the first file upload instead of being sent after the last one … I am not sure about it.

    About, the file list, it seems that the user can still delete a file from the list, after the upload has started … pretty dangerous in my opinion.
    Moreover, couldn’t we add the classnames “uploading” / “uploaded” to the file items to show that the file is being uploaded or has been uploaded.
    I did a change in that way for my personal developments, I could provide it, if needed.

    Thank you in advance for your help.

    Regards,
    Laurent

  • Corsairr

    Hi, that is great work !

    I am currently having a problem with Tab container, and I have not seen anywhere something explaining it. Here is the code :

    Select Files

    some text

    If you change the order of tabs (make the one containing fileuploader, not being the first), you get a this.movie.percentageload() failed. I have to set focus on the uploder tab if I want it to initialise properly.

  • Corsairr

    Sorry for double posting, I forgot to escape the html code.

    Hi, that is great work !

    I am currently having a problem with Tab container, and I have not seen anywhere something explaining it. Here is the code :
    <div class=”formContainer”
    dojoType=”dijit.layout.TabContainer”>
    <div dojoType=”dijit.layout.ContentPane”
    title=”Main Information”>
    some text
    </div>
    <div dojoType=”dijit.layout.ContentPane”
    title=”Upload Images”>
    <div dojoType=”dojox.form.FileUploader”
    class=”btnNormal”
    hoverClass=”btnHover”
    activeClass=”btnActive”
    disabledClass=”btnDisabled”
    uploadUrl=”../serverpage.php”>
    Select Files
    </div>
    </div>
    </div>

    If you change the order of tabs (make the one containing fileuploader, not being the first), you get a this.movie.percentageload() failed. I have to set focus on the uploder tab if I want it to initialise properly.

    Regards

  • Hi Corsairr,

    Unfortunately this is known problem with no simple solution. I’ve created a bug ticket for it where you’ll find different workarounds. Hopefully one will suit you.

    http://bugs.dojotoolkit.org/ticket/9793

  • Corsairr

    Ok.
    Thank you for the information.

  • Konrad

    Hello, first of all thanks for the great job!

    I have a question regarding the newest release of the uploader (1.3.2 at the time of writing). I use in my project version 1.3 and slightly modified FileUploader.swf file. I have the sources for the swf from the deft project. I want to migrate to the 1.3.2 version, but I still need to modify this swf (inject different variables to the POST data of each file from upload list). Are the sources of this new Fileuplaoder.swf available online (the deft project is a little outdated :) ?

    Regards,
    Konrad

  • @Konrad

    Thanks for keeping me honest :) Files commited. Let me know if any are missing.

  • Konrad

    It appears that everything is ok, thanks for the quick reply :)