Dojo Toolkit

A few of the startups building browser Add-Ons have organized the first ever Add-On Con, to take place in Mountain View on Dec 11, 2008.  We thought it was such a cool idea that we decided to co-sponsor the event (Mozilla is the other sponsor).  We ... [More] will be giving some sessions about extending Internet Explorer, and Mozilla and Google will be presenting about their respective web browsers.  Many companies with successful Add-Ons will be sharing their stories and experiences, so it’s a great education and networking event.  Matt Crowley, Program Manager for Extensibility, will cover all of the extensibility options available in IE8.  I will be discussing the lessons learned porting Firefox extensions to IE.   Come say hi to us if you’re attending! If you can’t make it to Mountain View, or even if you can, be sure to check out Christian’s blog post, the IE developer center, and the IE forums for other great info about building add-ons. Joshua Allen Technical Evangelist [Less]

Spam on the Web is one of the biggest threats to a modern Web developer. The "bad guys" become more and more sophisticated every year in how to vandalize and proliferate ads over any Web 2.0 page they can grasp. To ... [More] make matters worse, spam is increasingly used to distribute malware. The arms race is on, and Web developers need to know what basic tools are available to battle spam on their Web sites. This two-part installment provides a thorough guide to anti-spam techniques. This first article explains how to assess whether a visitor is a spammer and how to organize site workflow to discourage spam. [Less]

In this issue… Add-on-Con: Dec 11, Mountain View, CA Firefox: Tree logistics, migrations and checkin rules Add-ons: time to start updating for Firefox 3.1 Beta 2 Mozilla Manifesto now available in over a dozen languages Firefox market share up in ... [More] November Bugzilla 3.2 released Performance dashboard (v2) 38 languages are part of Thunderbird beta 1 Mitchell Baker profiled in Investors Business Daily Developer calendar Subscribe to the email newsletter Add-on-Con: Dec 11, Mountain View, CA Mozilla is taking part in the upcoming Add-on-Con that’s being held at the Computer History Museum in Mountain View on December 11. “Google, Microsoft and Mozilla will come together to discuss the future of the browser platform. Learn from industry leaders about the technology and business of browser add-ons. Network with your peers.” Mozilla’s VP of Engineering, Mike Shaver, will be giving the closing keynote, and Mark Finkle will also be presenting at the conference. Check out the Add-on-Con website for more information. Firefox: Tree logistics, migrations and checkin rules Mike Beltzner recently posted about the Firefox 3.1 / Gecko 1.9.1 code repository changes, wherein development activities for these will be moving from mozilla-central to the mozilla-1.9.1 repository. After the trees re-opened, new check-in rules came into play which can be reviewed on the Tree status wiki page. Further information, including related Bugzilla and Tinderbox changes, is available in Beltzner’s blog post at the Mozilla Developer News site. Add-ons: time to start updating for Firefox 3.1 Beta 2 Paul Roguet writes, “Firefox 3.1 Beta 2 will likely be released the first week of December. With Beta 2 we’re making the promise that we won’t be changing interfaces that break add-ons, so now is the time to start updating.” The Firefox team has also added a third beta to the schedule, where they’ll start aggressively pushing Firefox out to users. This means that it’s very important that a significant number of add-ons are updated for Firefox 3.1 before Beta 3 so as many users will update as possible. For more information, including links to documentation, see Paul’s full post at the Mozilla Add-ons weblog. Mozilla Manifesto now available in over a dozen languages The Mozilla Manifesto is now available in over a dozen different languages. The Mozilla.org site was updated recently to provide links to various translations of the text that were already available and the localization community has been very active providing new versions to add. You can now read the Manifesto in Chinese (Simplified), Chinese (Traditional), Dutch, English, French, Frisian, Galician, Greek, Italian, Korean, Polish, Portuguese (Brazilian), Romanian and Vietnamese. Thank you to everyone who has contributed their time and effort to help with this. Firefox market share up in November Asa Dotzler has posted about the NetApplications monthly Browser Market Share report, which shows Firefox hitting 20.72% of the global market in November. “This is a pretty solid jump over October, but also fairly consistent with the kind of growth Firefox has seen in the third quarter of previous years.” For more information and some pretty graphs, check out Asa’s blog post. Bugzilla 3.2 released Bugzilla 3.2 has been released, having been under development for roughly a year and a half. There are a tremendous number of changes in this new release, and while it is a major release it isn’t called “4.0″, the reasoning for which is explained in the latest Bugzilla Status Update. For more information about this release and all that has gone into it, see Max Kanat-Alexander’s weblog post. Performance dashboard (v2) About a year ago, Johnathan Nightingale built a dashboard for getting at-a-glance views of Firefox performance metrics, making it easier to spot regressions and assess the state of the tree. He has now released a new version of that dashboard. “It’s in its infancy right now. It only pulls data for the 1.9.1/Firefox 3 branch, and it only pulls a couple of tests thus far, but those are easy to add.” Johnathan has made the code available thorugh a public hg repository if you’re interested in adding features. Further details are available in Johnathan’s blog post. 38 languages are part of Thunderbird beta 1 Simon Paquet writes, “A little over three weeks ago, when I announced the string freeze planning for beta1, I said that I hoped that we could increase our number of supported locales for this release to 30 or maybe even (in my most optimistic case) to 35 locales. Well, as of now 38 locales (including en-US) have opted in for the Thunderbird 3 beta 1 release, thereby totally blowing away my expectations. This is notable, because already with beta1 we’re just one locale short of what we had achieved with the Thunderbird 2 final release. So thanks a lot to everyone in the l10n community. You guys rock!” Mitchell Baker profiled in Investors Business Daily Investor’s Business Daily has written an interesting profile piece about Mozilla’s Mitchell Baker. “Baker had been put in charge of the newly created Mozilla Organization, a unit of Internet pioneer Netscape Communications. Amid the tech collapse of 2001, Baker got the ax yet refused to leave. ‘Executives were stunned a week later when they learned she was still working on the project and making phone calls,’ said Brendan Eich, Mozilla’s chief technology officer. ‘She could do that because Mozilla had become a community project. It was no longer a Netscape creature.’” Mitchell has always played a critical role in the Mozilla Project, and the IBD profile demonstrates how valuable her persistence, vision, and dedication have been through the years. It’s a great read, particularly if you’re interested in some of the project’s history. Developer calendar For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page. Subscribe to the email newsletter If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox. [Less]

When working with FAT client web 2.0 application, it is normally quite slow whenever you need to reload your application because you are developing against unbuilt code (the source files are changed frequently, so you don’t want to build your ... [More] frontend code every time a modification happens). As a frontend developer, you are using Firefox Firebug, with console/script tabs enabled (sometimes net tab in firebug as well), which makes the loading time of a page with lots of javascript files even more slower. While we are used to ajax ways of updating part of a page without reloading the entire webpage, no one seems to apply the same methodology to reloading javascript source files. Dojo has the powerful dojo.require mechanism which can pull in javascript source files on the fly, and it is smart enough to cache any source files which are already downloaded. However, it does not provide any way to force reloading of a js file. After digging into dojo.require, I came up with a simple function to overcome this very issue: basically, it will unset any memory dojo has about that downloaded source file (or module, as called in dojo.require), and dojo.require that module again. Here is the source code for this function, which is called dojo.reload for now: dojo.reload=function(d){ //remove the module namespace from its parent namespace var sym=d.split('.'); if(sym.length>1){ var pname=sym.slice(0,-1).join('.'); var prop=sym[sym.length-1]; var parent=dojo.getObject(pname,false); if(parent){ console.log('delete property',prop,'on object',pname,':',delete parent[prop]); } }   //remove _loadedModules entry so that dojo.require will re-load it delete dojo._loadedModules[d];   //tidy up _loadedUrls so that dojo._getText will reload it sym=dojo._getModuleSymbols(d); var relpath = sym.join("/") '.js'; //copied from dojo._loadUri var uri = ((relpath.charAt(0) == '/' || relpath.match(/^\w :/)) ? "" : dojo.baseUrl) relpath;   delete dojo._loadedUrls[uri]; dojo._loadedUrls.splice(dojo.indexOf(dojo._loadedUrls,uri),1);   //set cacheBust to make sure we load latest file dojo.config.cacheBust= new Date;   dojo._loadreloaded=d; if(!dojo._reloadhotkey){ dojo._reloadhotkey=dojo.connect(document.documentElement,'onkeydown',function(e){ if(e.keyCode===dojo.keys.F6){ dojo.reload(dojo._loadreloaded); dojo.stopEvent(e); } }); } console.log('reloading module',d); dojo.require(d); }; Just copy and paste this function somewhere to your frontend code base, and when you want to reload a particular module, just type dojo.reload('mymodule.myfile') in Firebug console, and the latest version of your module will be downloaded and ready to be used/tested on immediately. In order to make sure the browser does not use one from its cache, cacheBust will be set to current timestamp to make sure it is loading from server directly. Another fine touch in the dojo.reload function is that, if you just want to reload the module you last reloaded, simply hit F6 which saves you some type. WARNING: this is only meant for development, don’t put this in your deployed code base. This is only tested in firefox 3, but it should work in other browsers as well. I think this will only work with the default loader and it will fail if you want to use it in xdomain case. At last, the famous phrase: use at your own risk. Edit: fixed mangled greater than symbol (thanks slackorama). changed all this->dojo so that no matter what this function is called, it can always correctly unset any “dojo memory”. - December 2, 2008 at 7:51 am [Less]

I should clarify what I said in the last post... We aren't getting rid of the desktop paradigm. I think a well polished desktop is important. However, the goal is not to make a perfect copy of a "real" desktop. It's actually to take the desktop ... [More] paradigm, and adapt it for the web. I'll also elaborate on what I mean by the "good parts of the web". The web is a great platform for applications. It's central nature allows for ease of communication. It also makes it easy to share things because it is publicly accessible. Lastly, the web is great because it's accessible from everywhere, including mobile phones. That said, current desktops such as gnome, windows, etc. lack the ability to do incorporate this in their design. What I want to do in Lucid is incorporate these aspects of the web into the desktop. An example would be the phone interface that we will be working on in 1.1. It will provide an alternate interface that allows javascript-enabled devices with limited screen real estate to run the full-blown desktop applications. Because the web is accessible from phones, we can actually pull this off. The current solutions, however, can't because of their decentralized nature. Another example is the public frontend that we wanted. Each user of the desktop would have a public website. Applications would be able to publish things to the personal website. For example, I could have a photos application that would allow me to publish a photo album that I could send to my friends. Current desktops can't do this; you need to upload them to something like Flickr. Because Lucid is on the web though, we can. That said, I'm not against syncing with Flickr, it's just that I feel a seamless integration with the web leads to a more usable interface. So, hopefully that cleared up the last post. I do think that having things like an office suite are important, but I'm not going to limit us to making a carbon-copy of a desktop environment. I want to expand upon that, and make it a desktop for the web, and not just a web-based desktop. [Less]

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 ... [More] 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. [Less]

Today is the day we branch our repositories - as previously announced, we’ll be moving development activities for Firefox 3.1 / Gecko 1.9.1 from mozilla-central to the mozilla-1.9.1 repository. Once we’re done: mozilla-central will be used for code ... [More] intended for the next Gecko release (currently versioned as Gecko 1.9.2 but that number may change) and will be open to a more lax set of check-in rules, mozilla-1.9.1 will be used for Firefox 3.1 builds, and will require that patches either fix blockers or have explicit approval, and have first been checked in and “baked” on the mozilla-central repository. Please read on for details of how this may affect your daily Mozilla-related activities! What’s Happening on the Tree Today In addition to the merge, the release engineering team will be migrating the BuildBot master server to a machine with faster disks. All trees (mozilla-central, mozilla-1.9.1 and the Firefox3.0 tree) will be closed until these tasks are complete, as BuildBot will be down. The team expects to be done by 1:00pm PST (21:00 UTC) if not earlier. When done, they will announce in dev.planning that the downtime is complete and will tell #developers to re-open the trees. Check-in rules when the tree re-opens Once the trees re-open, the mozilla-central repository will be less restricted than it has been for the past months, and the mozilla-1.9.1 tree will stay fairly restricted until we release. The check-in rules for any tree are always kept at the Tree Status wiki page. /mozilla-central checkins require proper reviews and should come with tests for any new or modified function; before checking in, make sure that automated unit tests, mochitests and leak tests pass (you can check this locally); after checking in, the committer *must* watch for regressions and be ready to back out if they appear; checkins must adhere to standard tree rules. /releases/mozilla-1.9.1 checkins only allowed if they fix a blocker, have explicit approval, or are not part of the build (NPOTB); before landing on mozilla-1.9.1, patches must first land on mozilla-central and “bake” there to watch for performance regressions; any string change must be marked with the late-l10n keyword and have explicit approval; any add-on compatibility change must be marked with the late-compat keyword and have explicit approval; Bugzilla, Tinderbox & Tools Some Bugzilla behaviour will change after the branch. Bugs should be marked RESOLVED FIXED once they have landed on mozilla-central. After landing on mozilla-1.9.1, the fixed-1.9.1 keyword should be added to the bug. Tinderbox and Talos have been set up for the new mozilla-1.9.1 branch; you can see the build waterfall Tinderbox page that we have been running builds for a while now. Johnathan Nightingale has also put up a new version of his performance monitoring dashboard (default view is 1.9.1) which can be used to keep an eye out for performance regressions. [Less]

After several weeks there is a new release of Dojango and this release introduces the compatibility to Google’s AppEngine. AppEngine delivers helpers so that Django applications can run on Google’s server farm and now this release of dojango allows ... [More] the deployment of Dojo powered web applications to it. At the moment AppEngine just supports version 0.96 (see Google AppEngine Helper for Django) of Django and dojango is now able to run with this old version. Since dojo’s variety of modules easily excesses the limitation of Google’s AppEngine of 1000 files, dojango now can solve this problem with an extreme mini build that just keeps the basic dojo files and all image files. I have to mention that this build removes all js-files that could be preloaded on a page using dojo.require. This means, that a dojo.require on Dojo modules that weren’t included in the Dojo build profile would not work anymore. So, when using the extreme mini build, you have to add all Dojo modules, that are used within the deployed application, to your Dojo build profile. I’ll show the deployment to AppEngine of a dojango application and the building of a Dojo release with the extreme mini build in another blog entry. Dojango 0.3.1 also had some other changes, like the addition of Dojo 1.2 as the new default Dojo version for dojango and Google is now used as the default CDN instead of AOL. Also two new decorator functions found their way into dojango. One is the json_iframe_response decorator that makes it easier to return json data when dojo.io.iframe is used. dojo.io.iframe is utilized e.g., if you want to submit multipart/form-data forms with file fields in the background. Here is a simple example, how to use that decorator: The Django side: 1 2 3 4 5 6 7 8 9 from dojango.decorators import json_iframe_response   @json_iframe_response def my_view(request): # do your file handling here # and just return simple python objects like booleans, # Strings, integers, dictionaries, lists, ... # the decorator does the rest for you return {'success': True} The Dojo side: 1 2 3 4 5 6 7 8 9 dojo.require("dojo.io.iframe"); dojo.io.iframe.send( { url:"/my-view/", form: dojo.byId("my_file_upload_form"), handleAs: "json", load: function(response){console.log(response);} } ); The other decorator jsonp_response can enable django views to deliver json data to foreign web applications using JSONP. You need that, if you want to make several django views available as your external API. Here is a short usage example: The Django side: 1 2 3 4 5 6 from dojango.decorators import jsonp_response   @jsonp_response def my_view(request): # prepare and return your data return {'success': True} The Dojo side: 1 2 3 4 5 6 7 8 9 10 11 12 dojo.require("dojo.io.script"); dojo.io.script.get( { url:"/my-view/", data: {doIt: true}, handleAs: "json", load: function(response){console.log(response);}, // the returned json data is wrapped into that function! // always add that parameter callbackParamName: "jsonp_callback" } ); For the next release we planned to take JSON-RPC, SMD (Simple Method Description) and maybe CometD into account. If you are interested in other features please don’t hesitate to contact us. [Less]

We from uxebu have organized the second dojo.beer and are happy to have won Mayflower to jump in sponsoring the location here in Munich, Germany. On friday the 5th december we will warm up with some dinner and some beer in some place here in Munich. The real thing will be on the 6th at [...]

I have read a lot of people's thoughts about the web desktop, and I completely agree with them. The web desktop is a failed attempt to recreate a desktop experience in a browser. That's really what it boils down to. From the start, I've always ... [More] thought that web desktops were a great idea, but nobody seemed to be doing them a justice. All we have are copies of the existing desktop environment, except much, much worse. We understand this point of view completely, and we want to change that. Instead of giving you a web-based desktop, we want to give you a desktop for the web. Rather then giving you a carbon-copy of everything that's been done before, we want to actually make the web desktop useful, and bring the good parts of the web into the desktop experience. We also want it to integrate with your existing desktop, and make the two seamless. Lastly, we want to give you total access from your mobile devices, and allow you to run the same applications you would from your desktop on your phone. The other web desktops don't seem to get this point of view. All they seem to do is copy what's been done before (I'm not aiming at any specific project, just in general). YouOS understood this point of view completely though; they wanted to make the web desktop a completely social environment. In a way we feel that PD is a continuation of where YouOS left off, and we felt really bad that things didn't work out so well for them. So, we don't want to reproduce what's already been done. If anything, we want to make something that questions the very nature of the existing web desktops. Our 1.0 release will appear like a carbon-copy of the other projects, but don't let this fool you. Starting at 1.1, we have a whole bunch of innovative things that we want to do. Keep in mind that we are a very small team of developers, and we need more help if we ever want to reach this goal. If you agree with us, and want to help us out, please don't hesitate to let us know. [Less]