File upload not working in IE8

[marcusocasey]

I have written a file upload implementation that works just fine on Firefox, but is failing on IE8. I have followed several posts regarding creating this upload that involves an iframe, UploadItem, HiddenItem with callback name, and Javascript implementation of the callback.

When I submit my form, the javascript error I get on IE8 is "Object doesn't support this property or method" from ISC_Forms.js Line: 492, Char: 63. The line referenced is below.

var _1=this.getForm();if(!_1)return;if(_1.action!=this.action)_1.action=this.action;try{return _1.submit()}catch(e){this.logWarn("Form submission was unsuccessful. In some browsers this can occur when "+"an upload item is present and has an invalid value.");this.formSubmitFailed()}}

Is this a known issue? Is there a particular object I cannot use on IE8? Will an upgrade fix this (we are on SmartGWT 2.0)?

[Isomorphic]

The upgrade that work fix this is to move to Pro, where the functionality is built in and works even on the other browsers you haven't tested yet - it generally does not make sense for a professional developer to be reinventing the wheel.

[marcusocasey]

I'm confused by your response. I think you are saying that I need to license the enterprise version in order to be able to upload files in all browsers. Am I correct?

The method I have followed to develop this follows guidelines on the SmartClient help pages and several threads in this forum. Apparently many people on here have reinvented the wheel, so if anyone is aware of a particular object or part of this process that doesn't work on IE, can you please pass that info along?

[Isomorphic]

We don't know what's causing your cross-browser issue is, but we can say definitively that it is not a SmartGWT problem since others have succeeded.

The bigger picture is that you are spending time trying to make your own private version of a feature that already exists in Pro. When you sum together:

1. time spent developing your own upload feature
2. time spent debugging this and the next 5 head-scratcher issues you might hit
3. time spent dealing with issues after deployment that wouldn't have come up if you had used Pro
4. time spent maintaining the code over time
5. time spent building other, related features that would have been automatically there if you'd just used Pro (like download icons, inline previews, multi-file upload, html5 upload (future) and progress dialogs (future))

.. then the cost of Pro is negligible considering just this one feature out of the hundreds that Pro provides.

There are, of course, valid reasons to go with the LGPL version (eg shipping an all-OSS product), but cost is not generally one of them if you are a professionally employed developer. Just something to consider.

[marcusocasey]

I can agree with you all day long, but I don't control the purse strings at my (massive) company. :)

[Isomorphic]

We sympathize, however, you will often find that there is a per-employee budget set aside for tools & training and the like and that all it takes to tap into it is a well articulated argument about overall cost savings, beginning with the point that your day so far has been dedicated to unnecessary work.

Some organizations are, of course, very dysfunctional, but you won't know until you try :)

[gvangass]

How about a PHP Pro solution.
At this stage I only have a PHP backend option, no Java containers(Tomcat, Jetty ...).
Reading the above reasons, I'll be willing to pay for such a solution(I'am sure that I am not the only one).