Web Development Forum (continued)

Hello!

I'm trying to write [JavaScript] code to upload [binary] files from user's machine to a server (PHP page) using XmlHttpRequest object.

The very first question is how to attach a file to XmlHttpRequest? As I understand I need to create something called a "stream" to do it. Is it possible to do it in Mozilla and IE using JavaScript and possible XML?

--
Vladimir Kelman
www.vkelman.com
vlad@vkelman.com

(1) ADODB.Stream is included with Microsoft Data Access Components (MDAC) 2.6 or above. This should be available on machines running Windows 2000 or above and I think it's part of the latest service pack for NT. However, I'm not very sure about anything below Windows 2000. You can get it as a download. The problem is that in order to utilize this component, you must either have "Initialize and script ActiveX controls not marked as safe" set to Prompt or Enable in IE's security. MSXML2.XMLHTTP is only available in XML 2.6 or above. This is a safe object so you can script it in IE without any problems. There is another XMLHTTP object you can script for older versions of XML: Microsoft.XMLHTTP. The later version is available to IE 5.5 SP2 browsers and above. The earlier version is available to IE 5.0 browsers. In order to overcome either situation try this:
var xmlhttp = null;
function window_onload() {
try {
xmlhttp = new ActiveXObject("MSXML2.XMLHTTP");
} catch(e) {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} finally {
alert("This functionality is limited to IE 5.0 and above.");

(2) I tested it on a 91MB file and it failed. I think there is an inherent POST size limitation with IIS, but I'm not sure. I read somewhere that there isn't one, but that doesn't explain why it doesn't work. I can try to find out more if you like.

(3) You can scan the virus once it's been uploaded. As long as there isn't any kind of automatic execution of a file, it should be safe but I'm not promising anything.

(4) I don't know if there is any way to put a progress bar on this, but I haven't tried.

The best advice that I have for you is to develop an internet component, implement the IObjectSafety interface (allows for scripting without prompt or disable), and digitally sign it so it can be installed on the user's system. You would then use either the MS Internet Transfer Control or the MS Winsock control to send the file data to the remote server. That way, you can provide a progress bar as well. If you need more information on this, just let me know: phil_perkins_1@yahoo.com

Phillip Perkins

Having been burnt in one development by inconsistent support for CSS, I have come to the conclusion that Keeping It Simple (Stupid) is the key to wide support development.

I recently used this principle to create an online irdering system that went into production with virtually no major issues. So I applaud the approach outlined in this article and look forward to Part 2

I have an attraction to building sophisticated client side DHTML. On my last project, I danced to close to the fire and got burned. We were using the WebService.htc to grab XML from the server, and then bound to it on the client side. Boy, did we get burned! First, the webservice.htc would lock up the browser anytime a connection failed, which made it very difficult to troubleshoot.

Lesson Learned: Keep It Simple Stupid.
The less code you send to the browser, the more reliable your application is going to be.

Remember, Yahoo! is the longest running big site on the net, and they are always KISS. If Yahoo! doesn't need this fancy stuff, then why does your app?

Base64 takes binary data, broken up into 8-bit bytes, and transmits the data is 6-bit segments encoded as 64 ascii characters. If there is an "@" is the data, it ought to be encoded quite easily, just like any other character. The output will not contain a "@". The only valid characters are letters, (a-z,A-Z), numbers, (0-9), "+" and "/" ... and "=" for filler.

Remember that Base64 encoding is used to encode the body of messages and file uploads, not headers, like e-mail addresses.

I just tried to get this to work in Mozilla 1.2.1 (after heavy changes) and there are too many quirks in Mozilla to get this to work properly. For example, when you finally get to a point where you can capture the onscroll event to sync up the separate DIVs, it doesn't always sync up. So if you're scrolling fast you may be off when you stop scrolling. Also, you cannot set the overflow style property to hidden and set the scrollLeft or scrollTop properties (you have to have the overflow set to scroll). I used this example in an intranet application, so I have complete control over the browser. If you're going to try this in another browser, I suggest you learn Java and create an applet to handle this. It's interesting when things that don't work in MS applications, people call it a bug. When something doesn't work in another application, people call it proprietary. I think this is a bug in Mozilla. :)

Many of us actually have customers who demand such things as a design for a specific browser. And what browser is that? Certainly not Netscape. Although Navigator has come a long way towards becoming once more a competitive browser, it still has little acceptannce in much of the business world. Nor are Opera or others yet of interest, despite having their own strengths and high points.

I find articles such as this very useful, as they are directly applicable to work in which I am involved. Although I appreciate the fact that cross-browser coding is necesssary for broad-based applications, many of us do have a more focused audience.

You can create two tables: one with the headers and one with the data. Set the column widths using and set the style of the table to "table-layout:fixed;". This should solve your problem. I did this in my example. Also, make sure that the border widths on your cells and column headers match.

To update the recordstatus elements for nodes that are changed, add onchange event handlers to the input elements. Set the onchange event handlers to call a JavaScript routine that accesses the XML data island to make the necessary changes. Therefore, when the value of an input element is changed, the JavaScript routine will go ahead and only update the recordstatus element for the data bound to that particular input element. I would suggest adding id attributes to your XML data island elements to make them more easily accessible with the JavaScript routine. Hope this helps.

Yes, I agree too. It would be one thing if an occasional digression into IE-specific applications was featured here, but it seems to be the rule rather than the exception and that is quite disappointing. Those of us who develop real world applications cannot afford this myopic view of our users and thus find these articles little more than mental masturbation -- ultimately unfulfilling.