Hi,
At most time when I upload stuff, I usually select more than one local file to be uploaded. It gets a little irritating to click the Upload button for each file to be uploaded. The other day, I noticed the way box.net does it and least to say, I got curious. I tried figuring out ways for Javascript / HTML combination to do this, but could not find any appropriate construct that could let me select multiple file in the "File Open" dialog box. Interestingly, not many sites supported this feature of selecting multiple files at the same time.
That is when I started reverse engineering the box.net interface, to discover the intricate synergy of Flash and Javascript doing the magic. Though the page seems to be complete Javascript, a hidden Flash movie is loaded when the upload button is clicked.
A little more experimentation with SWFMill to peek at the flash movie showed the use of the FileReference and the FileReferenceList Object. A simple FileReferenceList.browse() opens up the multi-select file open dialog. After selecting multiple files, the file names are passed to the FileReference Object as an array.
Flash then calls a JavaScript function that appends the <input type='file'> in the DOM. Now that is a pretty neat way of doing it, and I also googled for libraries that allows mix and match of this. This was an interesting library, with a lot more capabilities that I came across.
Interestingly, I looked at the Web Forms 2.0 and discovered that this feature could be easily implemented using the max and min attributes that would be supplied to the input type. However, this is still a working draft, and could take some time till it is pushed into HTML 5. Here is how Web Forms 2.0 map to the HTML versions.
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
HTML 5 Rocks !!
It is a high time HTML is given its fullest due. From a hack that supports hyper links, to a meta system that allows information organization, HTML 5 reflects the maturity of developers thinking about writing for the web. The class of changes range from synthetic changes to clean up the language, to cosmetic changes to add more structure to it.
With a stricter content model and the DOCTYPE tag and character encoding, the sense of standardization is enforced on the web writer. It also seems to reflect Opera's commitment to make Audio and Video first class citizens of the web. The newer data controls that are added [date, email, url, month...] would remove the need for non-standard javascript hacks to get certain types of input. As these controls would be native of the OS, syntax checking of the data would be simpler, making the job of Javascript developers easier. Other additions like <dialog> is the drift towards generalization of elements.
Changes in the meaning of <b>, <strong> and <i> backs the philosophy that the presentation is best achieved from CSS, and is best separated from HTML. Also, many redundant attributes for tags (like font, color) have been dropped in favor of using them in styles, backing this philosophy.
With HTML5, the <a> tag is now on a steroid, with a ping attribute that would help identifying dead links. In addition to this, attributes like autocomplete, datalist, autofocus etc. are more an impact of removing chronic annoyances with standard solutions.
Getting into the Javascript space (my favourite !!) a lot of interesting things are happening. The best is the async attribute in the script tag, that will let my page load faster, and not force me to combine *.js files, or place them as near the body> for the sake of performance. The life of JavaScript Programmers is further simplified with attributes like draggable, contextmenu and tabindex. Though I have not really explore cross document messaging, the description seems to head in the direction of making life of mash-ups easier. Things like online/offline events and persistent storage may help out of extensions like Google Gears into a standardized world. The video/audio API will make Youtube better, and apis for network will give Javascript, the power of a full-grown loosely typed language. The HTML DOM is also modified to help cross browser anomalies, typically with functions like getting selections, focus, etc. Doglous Crockford also got his much utilized getElementByClassName() function, something that will help me reduce code size significantly. I reserved the best for the last, and that, I think is the <canvas> element. So here comes a complete drawing engine into JavaScript, and I can now do everything I could do with ActionScript and Laszlo.
However, I am still trying to justify the logic of dropping elements like <frame> and <frameset>.I can technically use <iframe> and place them all over, I am not sure how well will that settle with people who have TOC on the left, and content on the right.
In summary, HTML5 is promising, specially for a JavaScript programmer like me, but again, being at the brink of another browser war, lets see how the browser developers take it. Thought it will take time to flush out old browsers from the market, I am already looking forward to a making the worst programming environment i.e. the browser, easier to deal with.
All for the best....
Check out
http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html
With a stricter content model and the DOCTYPE tag and character encoding, the sense of standardization is enforced on the web writer. It also seems to reflect Opera's commitment to make Audio and Video first class citizens of the web. The newer data controls that are added [date, email, url, month...] would remove the need for non-standard javascript hacks to get certain types of input. As these controls would be native of the OS, syntax checking of the data would be simpler, making the job of Javascript developers easier. Other additions like <dialog> is the drift towards generalization of elements.
Changes in the meaning of <b>, <strong> and <i> backs the philosophy that the presentation is best achieved from CSS, and is best separated from HTML. Also, many redundant attributes for tags (like font, color) have been dropped in favor of using them in styles, backing this philosophy.
With HTML5, the <a> tag is now on a steroid, with a ping attribute that would help identifying dead links. In addition to this, attributes like autocomplete, datalist, autofocus etc. are more an impact of removing chronic annoyances with standard solutions.
Getting into the Javascript space (my favourite !!) a lot of interesting things are happening. The best is the async attribute in the script tag, that will let my page load faster, and not force me to combine *.js files, or place them as near the body> for the sake of performance. The life of JavaScript Programmers is further simplified with attributes like draggable, contextmenu and tabindex. Though I have not really explore cross document messaging, the description seems to head in the direction of making life of mash-ups easier. Things like online/offline events and persistent storage may help out of extensions like Google Gears into a standardized world. The video/audio API will make Youtube better, and apis for network will give Javascript, the power of a full-grown loosely typed language. The HTML DOM is also modified to help cross browser anomalies, typically with functions like getting selections, focus, etc. Doglous Crockford also got his much utilized getElementByClassName() function, something that will help me reduce code size significantly. I reserved the best for the last, and that, I think is the <canvas> element. So here comes a complete drawing engine into JavaScript, and I can now do everything I could do with ActionScript and Laszlo.
However, I am still trying to justify the logic of dropping elements like <frame> and <frameset>.I can technically use <iframe> and place them all over, I am not sure how well will that settle with people who have TOC on the left, and content on the right.
In summary, HTML5 is promising, specially for a JavaScript programmer like me, but again, being at the brink of another browser war, lets see how the browser developers take it. Thought it will take time to flush out old browsers from the market, I am already looking forward to a making the worst programming environment i.e. the browser, easier to deal with.
All for the best....
Check out
http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html
GreaseMonkey Sucks !!!
Hi Sriram,
I know I don't really mean it, and I love GreaseMonkey, but at times, it does gets frustrating to write for Grease Monkey. Not because of its Wrapped Environment, but more because of the error reporting and all that. So I thought of doing a little experiment on developing GreaseMonkey Scripts. Some premises are
STEP 1 .
I have all the common utilities in the UTIL directory, and my build.xml just combines all the files to a single GM script. I am currently working on deploying the scripts to GM using ANT, but even though I am modifying config.xml, the changes are not getting picked up.
STEP 2.
Its always easier to start if the page is a part of the actual page [After all, GM was invented for teh sole purpose of adding scripts to pages] . So, I wrote a GM simulator that overrides the GM functions and has page specific implementations. Check out the HTML file in the SIGN on Manager folder. The GM Simulator saves all the values as cookies, and also adds the menu to the panel under it.
Here is the GreaseMonkey Simulator file :http://www.box.net/shared/vqfqi8cnbg
Lets see how this approach helps me out !!
-Parashu
My Experimental Workspace
I know I don't really mean it, and I love GreaseMonkey, but at times, it does gets frustrating to write for Grease Monkey. Not because of its Wrapped Environment, but more because of the error reporting and all that. So I thought of doing a little experiment on developing GreaseMonkey Scripts. Some premises are
- I hate the obscure errors that say that the error is in greasemonkey.js !!!
- There is lot of functionality that I use across scripts
- I would prefer to see logging in FireBug, rather than the JavaScript Console
- Firebug helps me better debugging, and i can do quick experiments with a page using FireBug
- Most times, I prefer to have a local version of the page to which the script will be applied, I am not on the Internet at all times
- GM_registerMenuCommand adds all the menus the TOOLS > GM > UserScript menu, and I hate navigating to that location everytime during testing, just to activate the command
- GM_setValue, puts that value in about:config, and I am not happy about reloading that about:config, and search for greasemonkey everytime some value is changed - maybe a list of values can be used
STEP 1 .
I have all the common utilities in the UTIL directory, and my build.xml just combines all the files to a single GM script. I am currently working on deploying the scripts to GM using ANT, but even though I am modifying config.xml, the changes are not getting picked up.
STEP 2.
Its always easier to start if the page is a part of the actual page [After all, GM was invented for teh sole purpose of adding scripts to pages] . So, I wrote a GM simulator that overrides the GM functions and has page specific implementations. Check out the HTML file in the SIGN on Manager folder. The GM Simulator saves all the values as cookies, and also adds the menu to the panel under it.
Here is the GreaseMonkey Simulator file :http://www.box.net/shared/vqfqi8cnbg
Lets see how this approach helps me out !!
-Parashu
My Experimental Workspace
Subscribe to:
Comments (Atom)