The New Dojo HTML5 Multi-File Uploader

March 21st, 2011 by Mike Wilcox

Dojox UploaderThe latest Dojo download, version 1.6, has just been released. Included is a completely new, HTML5 multi-file uploader, a widget that creates a stylable file-input button, with optional multi-file selection, using only HTML elements. Non-HTML5 browsers have fallback options of Flash or an iframe.

The dojox.form.Uploader is an improvement upon, and replaces the dojox.form.FileUploader. The various problems created by Flash are avoided because it is not used in Mozilla and Webkit browsers. Support for FileUploader will cease as of 1.6, but the code will remain until 2.0 for backwards compatibility.

To handle the different scenarios that a Dojo developer will need, the actual “upload functionality” is handled with plugins. Without these plugins, the Uploader code allows the file-input to be custom styled, and handles the multi-selection in non-HTML5 browsers, using the standard trick of adding a new file-input element after each individual file selection. Pretty much all there is to it is to add a dojoType to a file-input:


<input type="file" multiple="true" dojoType="dojox.form.Uploader"
	label="Select Some Files" url="/tests/UploadFile.php" uploadOnSelect="true"/>

This will render a button using whatever Dijit style is enabled. In this case, the default Claro:

Uploader Button

Note you would also need one of the uploader plugins for the Ajax upload to work which I will show shortly.

The Uploader also may be placed in a form and will “just work”. Actually, the Uploader will block the form’s submit event and take over its duties of collecting the field values and uploading the data to the server using the form’s action attribute, or the url property given to the Uploader. Remember to set the enctype attribute in your form to multipart/form-data which is used for uploading files.


<form method="post" action="/tests/UploadFile.php" id="myForm"
	enctype="multipart/form-data" >
	<fieldset>
		<legend>Form Post Test</legend>
		<input class="browseButton" name="uploadedfile" multiple="true"
			type="file" dojoType="dojox.form.Uploader"
			label="Select Some Files" id="uploader" />
		<input type="text" name="album" value="Summer Vacation" />
		<input type="text" name="year" value="2011" />
		<input type="submit" label="Submit" dojoType="dijit.form.Button" />
	</fieldset>
</form>

Uploader Form Example

Again, without a plugin, you are on your own for the actual upload. This is something that is missing from the FileUploader — the ability to just use a styled upload button and post the entire page to the server.

Before getting to the plugins, there is a helper widget for the Uploader. In the scenario above, you could choose several files, but you wouldn’t have any visual indication of what was selected. dojox.form.uploader.FileList automatically connects to an Uploader and detects when files are added, removed, or uploaded, and displays the list. It also has a built-in progress bar that shows during an Ajax upload.

The same code as above, but with the addition of the FileList widget, which has one attribute that points to the Uploader:


<form method="post" action="UploadFile.php" id="myForm"
	enctype="multipart/form-data" >
	<fieldset>
		<legend>Form Post Test</legend>
		<input name="uploadedfile" multiple="true" type="file" id="uploader"
			dojoType="dojox.form.Uploader" label="Select Some Files" >
		<input type="text" name="album" value="Summer Vacation" />
		<input type="text" name="year" value="2011" />
		<input type="submit" label="Submit" dojoType="dijit.form.Button" />
		<div id="files" dojoType="dojox.form.uploader.FileList"
			uploaderId="uploader"></div>
	</fieldset>
</form>

Upload Form Example Files

Plugins

The Uploader has three plugins available to handle Ajax uploads. The HTML5 plugin deals with the new file-input types in Gecko and WebKit browsers. You then have two options for what to do with IE: the IFrame plugin or the Flash plugin. There’s nothing new or fancy about them; they actually share code with the older FileUploader, albeit simplified.

The IFrame and Flash plugins extend the HTML5 plugin, so you don’t need to require both. And as you may expect, the only time you use the HTML5 plugin by itself is if you have a non-IE project (lucky you!).

In the previous example, the page will change and do a form post to UploadFile.php. To Ajax-ify it, just require one of the plugins:


dojo.require("dojox.form.uploader.plugins.Flash");

If you don’t want Flash, even in IE, simply use the IFrame plugin:


dojo.require("dojox.form.uploader.plugins.IFrame");

So wait… the earlier example used no plugins and was for a straight form; and these plugins are ajaxified but for IE. Where is the HTML5 plugin?

As I said, the Flash and IFrame plugins extend the HTML5 plugin, so it’s included and works automatically. But you could, if you knew that you weren’t using IE… ever… yes, even IE9, which doesn’t include HTML5 form support… include the HTML5 plugin the same way:


dojo.require("dojox.form.uploader.plugins.HTML5");

Either way, everything is handled automatically. When the “Submit” button is pressed, the Uploader intercepts the onsubmit event and blocks it so the page doesn’t change, grabs the URL from the action attribute, collects all the data in the form fields, and sends everything to the server.

Conclusion

Thanks to a few years of experience working on the FileUploader, I was able to make the Uploader very easy to use and versatile. My previous work with the FileUploader was getting difficult to maintain because the Flash plugin just doesn’t play nicely in any browser other than IE. So while it worked adequately, there were constant and subtle bugs with it in Dijit Tabs or Djit Dialog boxes. Thankfully the HTML5 features in Firefox and WebKit have matured enough that the multi-file-inputs can be used effectively, and the fact that they are native HTML elements means they render without issue.

Tags: , , , , , ,

97 Responses to “The New Dojo HTML5 Multi-File Uploader”

  1. Mike Wilcox says:

    Thats a good question and something that has kind of plagued me. Problem is when you use dojo.xhr it doesn’t handle a server blow-up well. But Uploader doesn’t use XHR so I think it could be implemented, I’m not sure. I *thought* the swf had a timeout in it where it gives up, I’d have to look.

    If you’d like, you could make a ticket for that and I could explore it in the future. http://bugs.dojotoolkit.org

  2. Lee Davis says:

    I want to be able to “normalize” my response. With the HTML5 plugin I can neatly format my JSON response and have whatever structure I want. However with the flash plugin I don’t know how to create this same structure or markup produced by the HTML5 plugin. Flash results always seem flattened.

    Example (desired result):
    dataArray
    [{
    file:foo.txt,
    status:success,
    details: {
    foo:100,
    bar:200
    },
    baz:300
    }
    ]

    I would like to be able to do something like below as my flash response and get the output above:
    file=foo.txt,status=success,baz=300,details=foo=100,bar=200

    I’m hoping there is some type of trick with the flash type response to make this happen, as every attempt I’ve made has created a flat structure in the end.

  3. Mike Wilcox says:

    I’m afraid that’s simply not supported. I’m not saying it can’t be done, but the data sent between Flash and the server (and back) is just a string, and Flash stupidly doesn’t support JSON (until v11).

  4. Lee Davis says:

    No worries. I can work around that, I just wanted to be sure I wasn’t missing something. Thanks again for all the help!

  5. Lee Davis says:

    The focus connect in the flash plugin is creating issue for our IE7 customers, throwing the error, A runtime error has occurred…. ‘this.flashMovie’ is null or not an object”

    Removing the connect on focus in the flash plugin appears to resolve the issue, but what happens to the user experience by doing so?

    //this.connect(this.domNode,”focus”,function(){
    //this.flashMovie.focus();
    //this.flashMovie.doFocus();
    //});

  6. Mike Wilcox says:

    Thanks Lee. I created a ticket for it that includes how I plan to fix it. The code is in a freeze right now. http://bugs.dojotoolkit.org/ticket/14150

  7. Lee Davis says:

    Excellent, thanks Mike!

  8. Remi says:

    I’ve tried to control the size of the Uploader – especially height – when uploading dozens of files. Do you have a heads up on the proper way to display scrollbars for example?
    Thanks.

  9. Mike Wilcox says:

    Remi – do you mean the FileList? If so, that wasn’t intended to solve all problems. It was to be a quick and dirty widget to get people going. That said, a div inside a fixed height div set to overflow-y:scroll, and then a div above for the header….

  10. Guus says:

    Mike,

    Great article!
    I’ve tried this on several different browsers just to find out it didn’t work on all except IE9 (!)
    After switching to Dojo 1.7 it worked. There were however so many different other problems with 1.7 I’ve decided to go back to 1.6 (for now) until I’ll find the time to get a grip on the specific changes in 1.7. I suspect my use of the Zend Framework has some influence on this behaviour.

  11. mgn says:

    Hello Mike,

    It’s me again (you’ll see my comments some months back). I never got the new Uploader onsubmit working programmatically by patching 1.6.1, but now I am moving on to using the 1.7.1 and I’ve hit more problems.

    Consider the following whihc should create two upload/submit button pairs – one declaratively and one programmatically. In 1.6.1 in both firefox and IE they both are created and they both pop up dialogs. In 1.7.1 in both firefox and IE you get both pairs of buttons, but the second one doesn’t pop up a dialog when you click it.

    Unfortunately I need to create the buttons programmatically inside a dialog.

    Any help appreciated.

    Mike

    Vulnerability Risk Manager

    dojo.require(“dojox.form.Uploader”);
    dojo.require(“dojox.form.uploader.plugins.IFrame”);
    dojo.require(“dijit.form.Form”);
    dojo.require(“dijit.Dialog”);
    dojo.addOnLoad(function(){

    var form = new dijit.form.Form({
    method:”POST”,
    action:”scanner/uploadJson?id=2″,
    id:”myForm2″,
    encType:”multipart/form-data”
    });
    var uploader = new dojox.form.Uploader({
    name:”uploadedfile”,
    multiple:”true”,
    label:”Select Some more Files”
    });
    var submitter = new dijit.form.Button({
    type:”submit”,
    label:”submit more”
    });
    dojo.connect(form, “onSubmit”, uploader, function(e) {
    e.preventDefault();
    this.upload();

    })
    form.domNode.appendChild(uploader.domNode);
    form.domNode.appendChild(submitter.domNode);
    dojo.byId(“secondForm”).appendChild(form.domNode);
    })

  12. mgn says:

    It looks like it stripped a lot of html from the comment – which therefore won’t make sense !

  13. Mike Wilcox says:

    So mgn, the issue is that you are unable to create two buttons programmatically in a dialog? One works? this is after the dialog has been created? I might be able to get to this today.

  14. mgn says:

    Mike,

    You’re a good man.

    The uploader button can be clicked when it is created declaratively but not programmatically. The problem comes in at around 1.7.0b5 and it looks like it associated with a change in the button css.

    I’m still trying to call onSubmit programmatically. I have taken the uploader code from 1.7.0b1 into a 1.7.1 (I can’t use 1.7.0b1 directly because of other bugs) and it looks like the 1.7.0b1 Uploader can be clicked OK. With my patched-up release I can now call the onSubmit properly in Firefox. However I run into another very strange bug when I call the onSubmit from IE. It fires up an upload dialog in IE. I’m still investigating this one.

    I’m in Europe so it’s late, but if you make any progress please post.

    Thanks,

    Mike

  15. mgn says:

    Well, part of my wierd behaviour when I call onSubmit on a programmatically-created Uploader in IE8 is that the IFrame Uploader sends a GET not a POST. Looks like this is happening elsewhere too.

    http://stackoverflow.com/questions/7895359/dojo-io-iframe-send-file-upload-sends-get-request-in-ie8

    The Flash uploader in IE8 doesn’t seem to do anything when I set the URL parameter programmatically after creation, so I am setting it to a fixed value on creation and then setting the name parameter in programmatically after creation. It looks like I can then parse the POST on the server side to handle the fact that the POST is coming into the wrong place (obviosuly I can’t do a redirect because a POST redirects to a GET). Hopeful, but not yet got this working

  16. Glenn Stowe says:

    The documentation on the 1.7 version is pretty spotty, but it looks like it’s changed again from 1.6 in how it “degrades” to different browser support. Is it supposed to be automatic? I.e. if I require the Flash and iframe plugins, should it automatically use the appropriate plugin for the browser type? Or do I need to make some kind of checks to include the right “require” based on the browser? I’m using Firefox 3.6, which I believe should use the Flash plugin, but it does not try to pull it in unless I set force=flash. It seems to upload with a POST operation. Or maybe this is how HTML5 handles an upload and FF 3.6 does have some HTML5 support?

    In any case, if looks like the default behavior it is falling into for FF 3.6 is not really appropriate for large files. Adding a large file (500Mb) to the uploader hangs the browser for several minutes. It should probably still continue to use the Flash plugin for FF 3.6. It works well in the latest FF and Chrome.

  17. Mike Wilcox says:

    Glenn, I’m sorry the docs seem spotty. I tried, but I think the way I designed the plugins was a mistake because it confuses too many people.

    If you use the Flash plugin, it will use HTML5 is available. I am using feature testing, so I would expect your use case to work to stick with Flash, but I don’t question your findings. I did make this widget when FF was in 4.0, which was the first version to support HTML5, so I am a bit surprised. I’m afraid that I’m super busy and can’t do any changes or even testing right now, and further, 3.6 is an old-ass browser without much audience left, so that would be a lot of work for little payout.

    I’ve never tested HTML5 with super large files. The Flash version had the benefit of a paying client using very large files and very many files, so it’s very battle tested.

    It sounds like in your case you should force Flash. It makes the backend coding a little easier anyway.

  18. Glenn Stowe says:

    Hi Mike, thanks for the quick reply. Not calling you out on the docs at all, just wasn’t sure if they were current. My fault, I misread the “since 1.6″ in the reference guide to mean “version 1.6″. So the Reference guide is current for the 1.7 code?

    Yeah, I’m coming to that conclusion (force Flash). Unfortunately the flash plugin provided with 1.7 does not initialize if it is not visible when it is created due to http://trac.dojotoolkit.org/ticket/14924 (mine is in a dialog box). I thought I could work around that by creating it programmatically when the dialog is first displayed, but there seems to be another bug there. The widget initializes, (buildRendering MultipleFileUploaderButton shows up in the console), but clicking the button does not do anything. I don’t think it loads the .swf.

    Been three days at this now. At this point I’m coming to the conclusion that I should switch the whole project back to Dojo 1.5, which is the last time this all worked.

  19. Mike Wilcox says:

    Glenn, there were some headaches that I didn’t see with AMD and a programmatic Uploader. You can see the resolution here http://trac.dojotoolkit.org/ticket/14811, and you can see the workarounds in the 1.7.2 (trunk) tests. I also mention them in the docs. Basically you have to refer to the Uploader as a global, and not from the AMD argument.

  20. Glenn Stowe says:

    Doh! Face-palm.

    uploader.startup().

    Thanks Mike, you’re a rock-star!

  21. Glenn Stowe says:

    Hi Mike, another question if you have time. With the Flash upload, the onProgress event used (circa 1.5) to be fired with a fileArray object as the argument. Each member of the array had a progress indication. When uploading multiple files you could use this to tell which file you were uploading in order to update a progress indicator appropriately. It looks like this has been changed to a simpler object that just has bytesLoaded, bytesTotal, etc, but is not broken down by individual file. Is the individual file progress no longer available? I’m assuming it must be available somewhere.

  22. Mike Wilcox says:

    Glenn, I looked at the code and it does in fact work as you describe, which would be a regression. But it is coded to how HTML5 works – the alternative would be to upload one a time so they could be individually tracked, which might affect the speed, I don’t know. Please feel free to file a bug on this.

  23. Glenn Stowe says:

    Thanks Mike, although it is possible to infer the information required, I’m just doing that to replicate the old functionality right now. The fileList is available through an Uploader method, and since I’m forcing the Flash plugin, I can tap into the onFileProgress of the plugin instead of the onProgress event of the Uploader. The event object for that one contains the file name as well as the progress. So I can match up the current file from the progress object to the fileList and check the progress of each file.

  24. SureshRajamani says:

    Hai,
    I need to send some data in Upload method like “Upload(some data)”.
    In which format,i need to send the post data.Pls Give me an example.

  25. Mike Wilcox says:

    There are two methods to upload files: upload(objectData) and submit(formNode). One accepts an object and the other accepts a form that will be converted to an object.

  26. SureshRajamani says:

    Thanks Mike,
    I am trying to send data like this myUploader.upload({ uploadedBy: ‘suresh’ });
    I need to receive this data in asp.net handler.I can able to download the file that i upload,But i m not able to get post data.
    I m using flash plugin in Dojox.Form.Uploader.
    Please help me to get post data.

    Thanks,
    R.suresh

  27. Mike Wilcox says:

    I’m not an ASP coder, but I know of some who were able to get the POST data. The docs don’t have ASP examples, but should give you an idea of what the backend expects: http://livedocs.dojotoolkit.org/dojox/form/Uploader

  28. SureshRajamani says:

    Is my format of post data is correct? or do i need to send anything like comma seperated?

  29. Mike Wilcox says:

    Yes, just it’s just an object.

  30. SureshRajamani says:

    Thanks,Mike.
    But I am not able to receive that POST Data in server using C# ASP.Net Handler.
    I will google it.

  31. SureshRajamani says:

    Hai Mike,
    It is working perfectly with Firefox.I can receive the data using Firefox,but not in IE9.
    Thanks,
    R.Suresh

  32. Damon Casale says:

    >I’m afraid that’s simply not supported. I’m not saying it can’t be done, but the data sent
    >between Flash and the server (and back) is just a string, and Flash stupidly doesn’t
    >support JSON (until v11).

    Would you release the source for the Flash uploader? I’d like to try my hand at tweaking it to output JSON. I remember a PHP, JSON-outputting library from a looong time ago, and if there’s not one available for Flash (I haven’t look yet), then I’d take the plunge and convert the PHP JSON library I have, to Flash.

    I have a project I’m working on that requires a file uploader that can upload in the background, while the user is doing other things on the page, but I need it to return an array of objects. I could work around needing JSON, but it would be a total pain.

    I also have a usage question. I’m designing a multi-page wizard that uploads its data to the server whenever the user clicks on “next” or “previous”. Ideally, I’d like to include the contents of the current “page” of the wizard when uploading the file, and I’d like to show a progress bar while the upload is in progress. I haven’t seen a use case for this that didn’t use the traditional “form” element.

    I’m currently initializing an uploader by giving it a DIV’s id in Javascript, like so:

    this.u = new dojox.form.Uploader({
    label: “Select spreadsheet files”,
    name: “namelistfile”,
    multiple: false,
    uploadOnSelect: true,
    url: “/ajax/uploadNameList”,
    onUpload: function() {
    // Disable next/prev buttons, don’t want the user
    // to change the page and nerf the upload
    },
    onComplete: function(arr) {
    // Re-enable next/prev buttons
    // TODO: Do something here
    }
    }, “namelistfile”);

    How do I get a progress bar as well? Oh, and is there an onUpload function for immediately before an upload begins?

  33. Mike Wilcox says:

    @Damon, you can see a progress bar example that I use in FileList in the Uploader test.

    I’m unsure of your question, but it sounds like you will have a problem attaching files – that has to be initiated by the user due to security reasons.

    The Flash source files are open source and available: http://trac.dojotoolkit.org/browser/deft/trunk

    And there is an open source Flash JSON library released by Adobe. I didn’t implement it because it wasn’t mine, and I would have has to get permission to do so.

  34. Damon Casale says:

    I figured out how to do what I need.

    #1, in order to have an upload-upon-select file uploader that still grabs form data, I leave uploadOnSelect set to false, and do this after the widget is initialized:

    this.u.connect(this.u, “onChange”, function(data) {
    data[0].namelist = dijit.byId(“namelist”).get(“value”);
    data[0].namelistdescription = dijit.byId(“namelistdescription”).get(“value”);
    this.u.upload(data[0]);
    });

    #2, in order to disable and enable my dialog’s next/prev buttons, I use the OnBegin, onAbort, onError, and onComplete functions to toggle my controls off and on.

    I worked around needing JSON for now. Instead, I do this on the server side, in PHP:

    $arr = array(
    ‘status’ => “success”,
    ‘namelist_encryptedid’ => makeSafePackedArray(Array($namelist->getValue(“id”))),
    ‘namelist_name’ => $namelist->getValue(“namelist”),
    ‘namelist_description’ => $namelist->getValue(“namelistdescription”),
    ‘namelist_filename’ => $filename,
    ‘namelist_dateimported’ => $namelist->getValue(“dateimported”),
    ‘namelist_count’ => $count,
    ‘namelist_encoding’ => $namelist->getValue(“encoding”)
    );

    Then I output it and receive it on the client side like this:

    onComplete: function(arr) {
    var namelist = {};
    for (var field in arr[0])
    {
    if (“namelist_” == field.substring(0,9))
    namelist[field.substring(9)] = arr[0][field];
    }
    this.namelists.push(namelist);

    I don’t need to replace the whole namelists object array, which is what I was going to do before. I found a way to create the object I wanted using a prefix kludge instead.

    Finally, I checked your examples and *they both use forms*. I *cannot use a form HTML element*, since I’m doing a wizard dialog. Is there a way to attach a progress bar when programmatically creating an Uploader widget?

    E.g., my HTML is:

    Choose File:

    And I’m instantiating the upload widget in Javascript.

  35. Damon Casale says:

    Urgh. This thing nerfed my HTML. Re-entering:


    <tr class=”newlist hidden”>
    <td>Choose File:</td>
    <td><div id=”namelistfile”></div></td>
    </tr>

  36. Mike Wilcox says:

    Progress bars are pretty easy – that’s why the uploader/FileList is so simple. I didn’t want to assume what someone would need, because they could build it themselves.

    connect(this.uploader, “onProgress”, “_progress”);
    _progress: function(/* Object */ customEvent){
    this.percentTextNode.innerHTML = customEvent.percent; // includes the % sign
    domStyle.set(this.percentBarNode, “width”, customEvent.percent);
    }

    The HTML for a progress bar is simply a bar inside a div, and you set the width of the inner bar to the percentage.

  37. Glenn Stowe says:

    First, thanks for all the help so far Mike. Has anybody reported a problem using the Flash uploader in IE8? I know, it’s an old browser, but it is still the standard required by most US government departments (my clients). There is a year-old post on the dojo forum about it.

    It reports “this.flashmovie is null or not an object ”

    The odd thing is that the upload works. Sort of.

    If the Flash uploader is placed in a dialog box in IE8, the dialog spontaneously closes part way through the upload. The upload completes, but the dialog being shut down in the middle blows away my progress bar and other info the user was supposed to fill out.

  38. Glenn Stowe says:

    Is there any way to make the old Flash uploader (fileuploader) work again in 1.7? After a week of trying to get the new one to work in IE8, I’m ready to give up. I migrated my whole application to 1.7. The uploader took 90% of the time. And after all that, it still won’t work. After pulling all the tricks discussed here and in the dojo forum, including hiding the button off-page until ready to use it, I finally got it to instantiate without errors. But when you submit the upload using upload(), it just throws an unhandled exception deep in dojo somewhere. Works fine in every other browser. I’m about at the point of migrating the whole app back to 1.5. I tried using the deprecated FileBrowser but the shockwave fails to load: this.movie.PercentLoaded is not a function

  39. Mike Wilcox says:

    Glenn, IE8 is fully supported, and is the primary reason for Flash. Flash does not work well in FF and Webkit, but works (in general) very well in IE. There are no plans to port the FileUploader because it didn’t work well at all with FF and Webkit. That said, Uploader is for the most part using the same code for Flash.

    I do have plans, although unfortunately with no ETA of building better Flash embed code. What I’ve created at work handles improperly installed SWFs and checks and rebuilds them, which fixes intermittent errors.

    However, it doesn’t sound like your problem is intermittent, nor do I recall it being a bug in Trac? Is this directly related to being in the Dialog?

  40. Glenn Stowe says:

    It most likely has something to do with the dialog. It can’t be created statically in the dialog because of the requirement to be in a visible area. If I try to create it programmatically in the dialog with the first onShow event, it starts to work, but half-way through the upload, the dialog vanishes. It doesn’t seem to make a lot of sense that the plugin could drop the dialog, but that’s what happens. So I started experimenting, trying another user’s suggestion of creating it in HTML off-screen then moving it into the dialog in the onShow. That had some potential, but when I started the upload (via the upload() method, I’m not using a Form), IE throws an “Unspecified error”. A debugger points to the “return” line in this function.

    function __flash__addCallback(instance, name) {
    instance[name] = function () {
    return eval(instance.CallFunction(“” + __flash__argumentsToXML(arguments,0) + “”));
    }
    }

  41. Glenn Stowe says:

    The programmatic instantiation on first onShow of the dialog had the most potential, because the upload completes correctly. But with the dialog gone, my users cannot finish what they were doing correctly. There are no errors thrown when it vanishes.

  42. Alex says:

    Hi Mike,

    Where can we find some demos of the various dojo and dojox file uploaders on dojo website?

    Best regards
    Alex

  43. Mike Wilcox says:

    Alex, there aren’t any online demos due to a number of technical reasons. But When you download Dojo and all its tests, there are a few Uploader tests that should work and help get you started. Note that in the tests there is a PHP page to upload to – but has been renamed due to one of those technical security reasons.

  44. mschr says:

    Hi Mike

    Great work, have had problems with this x-dijit for ages though so, to be honest have gone with an applet in most situations.. HowEver :D

    The HTML5 support is intreaging – but the module is not all that modular.. I find, doing stuff in declarative markup makes for some 95% success in various situations.. Features found, inputs built etc..
    But, in my current situation i require Flash plugin, and instantiate programatically – leaving my instance with no proper inheritance it seems, like upload() == function() {}, postCreate not called, form aint connected etc.

    If i do:
    dojo.require(“dojox.form.uploader.plugins.Flash”);
    this._fileuploader = new dojox/form/Uploader({
    fieldname: ‘flashUploadFiles’,
    flashFieldName: ‘flashUploadFiles’,
    // url: ‘upload.php’,
    uploadType: ‘html5′,
    multiple: true,
    form: dojo.byId(‘assetsuploaderform’),
    iconClass: ‘dijitFolderOpened’,
    label:’Vælg filer til upload’
    }, ‘assetsuploader’);
    this._fileuploader.connectForm()
    this._fileuploader.startup()

    i get working button, select files dialog, getFileList returns selection – but .upload() is empty

    You point it out earlier; “I’m sorry the docs seem spotty. I tried, but I think the way I designed the plugins was a mistake because it confuses too many people.”

    Could u put some examples on working autodetection with a few, most basic lines of programmatic code somewhere (here)?

  45. mschr says:

    Hi Mike

    Great work, have had problems with this x-dijit for ages though so, to be honest have gone with an applet in most situations.. HowEver :D

    The HTML5 support is intreaging – but the module is not all that modular.. I find, doing stuff in declarative markup makes for some 95% success in various situations.. Features found, inputs built etc..
    But, in my current situation i require Flash plugin, and instantiate programatically – leaving my instance with no proper inheritance it seems, like upload() == function() {}, postCreate not called, form aint connected etc.

    If i do:
    dojo.require(“dojox.form.uploader.plugins.Flash”);
    this._fileuploader = new dojox/form/Uploader({
    fieldname: ‘flashUploadFiles’,
    flashFieldName: ‘flashUploadFiles’,
    // url: ‘upload.php’,
    uploadType: ‘html5′,
    multiple: true,
    form: dojo.byId(‘assetsuploaderform’),
    iconClass: ‘dijitFolderOpened’,
    label:’Vælg filer til upload’
    }, ‘assetsuploader’);
    this._fileuploader.connectForm()
    this._fileuploader.startup()

    i get working button, select files dialog, getFileList returns selection – but .upload() is empty

    You point it out earlier; “I’m sorry the docs seem spotty. I tried, but I think the way I designed the plugins was a mistake because it confuses too many people.”

    Could u put some examples on working autodetection with a few, most basic lines of programmatic code somewhere (here)?

    Thx // advance!

  46. Glenn Stowe says:

    Hi again Mike, I just came back to trying to get the Flash uploader working in a dialog in IE8 and had a little more information. For some reason, if the uploader is in a dialog, it sends a hide” event to the dialog when the onComplete upload event fires. I’ve been able to verify this by connecting to the same event with debugging statements. Is this by design?

  47. mschr says:

    I figured it out after some troubles with the plugin-extending.. Problem was, i instantiate using the local variable sent in from require().

    Another thing i noticed though was, 1.7.2 (CDN) has some form of recursive class-requirement when we load-in FileList, probably related to one of the private classes, mby _RollingListPane – as they are required across file-scopes.

    Thanks again for a nice x-addition :)