From ef256c958066c19bb10cbe9745bdf96b6514762d Mon Sep 17 00:00:00 2001
From: Derrell Lipman qooxdoo reader
");
+ header.setCssClassName("header");
+ header.setHeight(50);
+ dockLayout.addTop(header);
+
+ // define commands
+ var reload_cmd = new qx.client.Command("Control+R");
+ reload_cmd.addEventListener("execute", function(e) {
+ this.fetchFeeds();
+ this.debug(this.tr("reloading ...").toString());
+ }, this);
+
+ var about_cmd = new qx.client.Command("F1");
+ about_cmd.addEventListener("execute", function(e) {
+ alert(this.tr("qooxdoo feed reader."));
+ }, this);
+
+ // create toolbar
+ var toolBar = new qx.ui.toolbar.ToolBar();
+ toolBar.add(new qx.ui.toolbar.Button(this.trn("Add feed", "Add feeds", 2), "icon/16/actions/dialog-ok.png"));
+ toolBar.add(new qx.ui.toolbar.Button(this.tr("Remove feed"), "icon/16/actions/dialog-cancel.png"));
+ toolBar.add(new qx.ui.toolbar.Separator());
+
+ var reload_btn = new qx.ui.toolbar.Button(this.tr("Reload"), "icon/16/actions/view-refresh.png");
+ reload_btn.setCommand(reload_cmd);
+ reload_btn.setToolTip(new qx.ui.popup.ToolTip(this.tr("(%1) Reload the feeds.", reload_cmd.toString())));
+ toolBar.add(reload_btn);
+
+ toolBar.add(new qx.ui.basic.HorizontalSpacer());
+
+ // poulate languages menu and add it to the toolbar
+ var locales = {
+ en: this.tr("English"),
+ de: this.tr("German"),
+ en: this.tr("English"),
+ tr: this.tr("Turkish"),
+ it: this.tr("Italian"),
+ es: this.tr("Spanish"),
+ sv: this.tr("Swedish"),
+ ru: this.tr("Russian")
+ }
+ var availableLocales = qx.locale.Manager.getInstance().getAvailableLocales();
+ var locale = qx.locale.Manager.getInstance().getLocale();
+ var lang_menu = new qx.ui.menu.Menu();
+ var radioManager = new qx.manager.selection.RadioManager("lang");
+ for (var lang in locales) {
+ if (availableLocales.indexOf(lang) == -1) {
+ continue;
+ }
+ var menuButton = new qx.ui.menu.RadioButton(locales[lang], null, locale == lang);
+ menuButton.setUserData("locale", lang);
+ lang_menu.add(menuButton);
+ radioManager.add(menuButton);
+ }
+ radioManager.addEventListener("changeSelected", function(e) {
+ var lang = e.getData().getUserData("locale");
+ this.debug("lang:" + lang);
+ qx.locale.Manager.getInstance().setLocale(lang);
+ });
+ lang_menu.addToDocument();
+ toolBar.add(new qx.ui.toolbar.MenuButton("", lang_menu, "feedreader/images/locale.png"));
+
+ var about_btn = new qx.ui.toolbar.Button(this.tr("Help"), "icon/16/actions/help-about.png");
+ about_btn.setCommand(about_cmd);
+ about_btn.setToolTip(new qx.ui.popup.ToolTip("(" + about_cmd.toString() + ")"));
+ toolBar.add(about_btn);
+
+ dockLayout.addTop(toolBar);
+
+ // add tree
+ var tree = new qx.ui.tree.Tree(this.tr("News feeds"));
+ tree.set({height:"100%", width:"100%"});
+ tree.setOverflow("auto");
+ tree.setBorder(qx.renderer.border.BorderPresets.getInstance().inset);
+ tree.setBackgroundColor("#EEEEEE");
+
+ var feedDesc = feedreader.Application._feedDesc;
+ for (var i=0; i");
+ html.add(item.title);
+ html.add("
");
+
+ html.add("
We know that many of you are managing your tasks with Remember The Milk and your events with Google Calendar, and we thought it would be very cool if we could bring the two together. This new feature adds a small task icon to the top of each day in Google Calendar — click on the icon to:
+This is really interesting. An outside group was able to add an important feature that we can not all use in a Google app itself.
+ + +]]> +Jack's YAHOO.ext.Resizable component does what it says on the tin, and he shows you:
+Currently the tabbed widget shows documentation for the core Moo.js, extensions of JavaScript objects and helpers, Addon libraries, and plugins.
+It behaves a little weird for me with FF2 + Firebug 1.beta, but I can get to the meat of the matter.
+ + +]]>Nothing ground-breaking, but it is interesting to hear about their thoughts on Ajax:
+++Browser compatibility issues - like the early graphic Web
+Next was a question about browser compatibility issues and how that affects D&S - and indeed the future of rich web applications. Sam responded that "it is definitely an issue [...] these apps are all cutting edge - it kind of reminds me of the early days of the graphical web, when you couldn't count on the browsers to render tables correctly [...]".
+But he thinks it's "just growing pains" and it'll take about a year to sort those issues out.
+Also on the question of whether Ajax is better than Flash and Laszlo etc, Sam thinks that Ajax is currently more web native.
+It's about being Web native, not cloning desktop apps
+Later in the interview, Jen stresses that they're "not trying to clone desktop apps". They want to be familiar to people, "but we're trying to do something that's actually more native to the Internet, more usable on the Internet."
+Sam says they've had a lot of feedback that people like the fact they're not trying to copy desktop apps. He said "copying the existing stuff just feels irrelevant to us - we're not trying to copy, we're trying to re-invent."
+Both Jen and Sam re-affirmed that collaboration and sharing is their main focus with D&S, as well as being web native - rather than trying to compete on features with desktop apps. +
If you were asked "why is Ajax a better fit for some apps than Flash?" what would you say? Do you agree? Does the open web matter? What if Adobe fully opened up their format? +
+ +]]>This is a review of Pro Ajax and Java Frameworks by Nathaniel T. Schutta and Ryan Asleson. This book seeks to give the experienced developer of Java web applications the knowledge necessary to add Ajax to their webapps. This is another Ajax book that goes broad rather than deep. Instead of investigating one or two frameworks, it delves into more than a half dozen, both Javascript and Java.
+Quick summary: Chapters 2, 3 and 5 are the strongest in the book with useful information on tools, Javascript libraries and enhancing Struts applications with Ajax. The other chapters are not as strong and spend too much time covering old ground.
+The book is divided into two parts. Part 1 is an introduction to a variety of Javascript and Java Ajax libraries and frameworks. Part 2 shows how to integrate those libraries and frameworks into existing Java web frameworks such as Struts and JSF. One place that this book differs from other Ajax books is that it doesn't have a chapter introducing the reader to the browser technologies that comprise Ajax. It doesn't dwell on the basics of Javascript, DOM and CSS. It expects you to have already read the Apress books on those topics. Instead, chapter 1 covers what I would call best practices and patterns -- autocomplete, partial page update, draggable DOM.
+Read more of the review here.
+ +]]>He first came out with MinusR which takes of your rjs files and lets you code in JS, but still call out to the ruby style. For example:
+++MinusR gives you the js helper that calls to_json on any value passed to it so you can drop nicely escaped and formatted data into your script as before. Everyone’s a winner. Well, not quite, I could be going out on a limb here but I really think this is the better way. Go on, give it a go. A bit of javaScript won’t hurt you…. +
Then a bunch of people wanted this to be doable, but in a separate file, so Dan created MinusMOR, which let's you do the same thing in .ejs files.
+It is great to be able to choice your poison, even on a case by case basis, and decide whether JS or Ruby is the ruler. +
+ +]]>Evolution of the web in real-time. I hope you are having a good weekend (a Thanksgiving one for the US folk). +
+ +]]>p.setURL('another.url.com');
+p.getHost() == 'another.url.com';
+p.getProtocol() == '';
p.setURL('dsdsad'); // throws an exception
+
This smells like a Java group writing JavaScript to me with the camelCase and thus p.getUsername() instead of p.username.
+You can check out the implementation and the test suite (zip). +
+ +]]>The work comes with a test page for http and https, and is documented in this function:
+// private scope variable
+var IEStringToWrite = // this is IE dedicated string
+ "<script defer src='//:' onreadystatechange='
+ (function(element){
+
+ // if readystate is complete
+ if(element.readyState === "complete")
// call the global variable
+ window.__onContent__();
+ })(this);
+ '></script>";
// the above string is necessary to use onreadystatechange property
+ // with an undefined page. In this way IE tell us the readyState
+ // of the current document
// to call callback function IE need a global scope variable
+ // this variable could call one or more callback
+ // then if it's already created we need to call the old callback
+ // then this new callback
+ window.__onContent__ = (function(oldCallback){
+
+ // returns a function that will delete __onContent__
+ // to remove multiple callbacks with different
+ // events and different ways for each browser
return function(){
+ // clear __onContent__ as generic function
+ window.__onContent__ = function(){};
+
+
+ // checks if oldCallback isn't null or undefined
+ if(oldCallback)
+ oldCallback(); // call them to preserve the right order
callback(); // call this scope callback function
+ // (sent calling onContent)
+ }
+
+ })(window.__onContent__); // undefined if is the first time we use __onContent__
// __onContent__ is my function to use as callback
+// I need to add this function as event
+ // Opera 9 and FireFox both support DOMContentLoaded as well as
+ // addEventListener document method
+ if(document.addEventListener)
+ document.addEventListener("DOMContentLoaded", __onContent__, false);
// if some browser supports addEventListener but doesn't support DOMContentLoaded
+ // event I don't need to care about that because this event will never be fired
// at the same time if Safari or KDE one day will support DOMContentLoaded
+ // I prefere use this dedicated in-core
+ // event instead of next trick that's quite horrible but works with Safari,
+ // KDE as Opera 8.5 and lower too
// that's why I don't use an else if but an if ... because the first time
+ // event will be fired __onContent__
+ // became an empty function ... then calling them twice is not a problem
if(
+ // Safari and KDE
+ /WebKit|Khtml/i.test(navigator.userAgent) ||
// Opera less than 9
+ (window.opera && parseInt(window.opera.version())<9)
+ )
+ // runtime anonymous function
+ (function(){
// checks if document.readyState is loaded or complete
+ /loaded|complete/.test(document.readyState) ?
// then call __onContent__ , stopping internal loop
+ window.__onContent__() :
// or loops itself with the faster timeout
+ setTimeout(arguments.callee, 1);
+ })();
// at this point I've setted the DOMContentLoaded event for every browser
+ // but not for Inernet Explorer.
+ else if (/MSIE/i.test(navigator.userAgent))
// I can write dedicated string
+ document.write(IEStringToWrite);
+};
+
On November 30, the Eclipse foundation will be hosting a 1 hour webinar titled Using the Eclipse Ajax Toolkit Framework (ATF).
+Eclipse ATF provides exemplary tools for creating and debugging Ajax applications. These tools include enhanced JavaScript editing features such as edit-time syntax checking, an embedded DOM browser, CSS Tools, JavaScript debugger, a JavaScript console, and an embedded Mozilla web browser. This webinar will demonstrate how to use ATF to create, debug, and deploy an Ajax application on both Apache and J2EE servers.
+Register by emailing webinar-atf@eclipse.org
+ +]]>Hedger Wang has a new hack that uses window.createPopup instead of an iframe to for IE to fix some issues.
+If you take a view source to see what is in there, you get the gem:
+ fs = (fs + '').split('/==/')[1];
+ window.createPopup().document.body.innerHTML = '<img src="null" onerror="' + fs + '" />';
+
+})();
var Array2 = function(){};
+ Array2.prototype = new Array;
+ Array2.prototype.bar = function(){
+ alert("this.bar() --> This.Length=" + this.length );
+ }
+
The application is ad free, and survives on user donations. They do a good job at letting you use it pre-signup, and giving good info via tooltips.
+ + +]]>This means that you can add spell checking to your applications, but as the latest browsers have added inline spell check, is there use to it?
+ + +]]>With the CSS Tab Designer, you can:
+The User interface allows interactive drawing by using your standard browser.
+No additional software; no third party plug ins. Just run it and use it.
Open-jACOB Draw2D is the graph component of the Open-jACOB online
+Workflow editor. The purpose of this experiment is to see if a Visio-type workflow
+editor tool could be developed in a web browser - It is possible.
Check out an interactive demo.
+ + +]]>Google Pages just released a few features, and one of them is an improved process for working with images.
+Firstly, the way you get photos up is simple and clean, but when when you have an image, you can click on it and you are shown a bunch of tools that allow you to manipulate the image inline, right there on the page.
+ + +]]>++As mentioned above and already announced in our developer blog, qooxdoo now includes support for WebKit. We expect to fully support the next major version Safari 3.0 which will be based on the current development of WebKit. There is only limited support for Safari in its current version 2.0.4, though. Reason is, that Safari 2.0 still has many bugs that can hardly be worked around. Luckily, many of those bugs are already fixed in the nightly builds of WebKit. Besides the various bugs, Safari 2.0's JavaScript engine and its execution speed is not competitive with respect to the latest versions of the other major browsers (Firefox 2.0, IE7, Opera 9). Good news is, that the current builds of WebKit are tremendeously faster than Safari 2.0, approximately by a factor of 7-8 for a typical qooxdoo demo. +
Check out the release notes for full details on changes in this release.
+Some of them are:
+As Steve the author put it:
+++We attended the first Ajax Experience conference in San Francisco and we got super excited about the potential for building Ajax applications. Since we have a Microsoft .NET background, we planned to start building Ajax applications using Microsoft’s Atlas framework. However, we quickly encountered several serious issues with Atlas. Doing simple things in Atlas, such as database access and form validation, turned out to be really difficult. We were also disappointed to discover that Microsoft has no plans to support its client-side Atlas framework in the immediate future.
+We built the Lollygag framework in order to build true Ajax applications in the .NET environment. We wanted to build single page Web applications that never perform postbacks. All updates are performed through Ajax calls to the web server. +
Features
+Hello World
+Resources
+How does it compare to Atlas? Read their thoughts on the matter.
+ + + +]]>+++
+- Zoom in on text and images. Here's a cool full-page sketch of a ship from an 1898 book on steam navigation. Looking for something less dated? Perhaps this colorful page of a room from a book on interior design. Want a better look? You can now zoom in and out — just click on the
+ +and
buttons. Play with it until you find a size you like.
- One book, one web page. No more reloads! In one-page mode (just click the
+ +button), pages appear one below the other, like a scroll of paper. For full-view books, there's also a two-page mode (
) in which pages appear side by side, just like in a physical book (perfect for two-page images). In both modes, you'll be able to use
and
to turn pages.
- Scroll, scroll, scroll your book… using the scrollbar or your mouse wheel, or by dragging (in most browsers, you'll see a
+ +). You can also use the keyboard (try the spacebar, page up, page down, and the arrow keys). Or you can click on a link in the table of contents or your search results to jump right to that page (like this photo from the 1906 book Geronimo's Story of His Life).
- This page was made for reading. We've tried to tidy up the clutter to leave as much room as possible for what's important — the book. We've put all the information about the book in a scrollable side menu. Still not enough room? You can put the screen in fullscreen mode with
+, so you can use the whole window for browsing. Try it with a nice illustrated book of Celtic fairy tales or, for some lighter reading, electromagnetic wave theory.
There are keystrokes here too, such as hitting space to scroll down (moving down smoothly). It is nice to see more and more unification to Google apps these days. When you use Reader it feels like Mail, etc.
+One question is, where are the GWT apps? :)
+ + +]]>For the next qooxdoo release we plan to fully support WebKit, which hopefully builds the basis for the next major release of Safari shipped with the upcoming OS X 10.5. We decided to target WebKit because of its improved standard support and its dramatically faster JavaScript engine. Some qooxdoo examples are up to seven times faster using WebKit compared to Safari 2. Even if we would fully support Safari 2, it will never be a good platform for big JavaScript applications.
+ +]]>I have just found some more interesting stuff regarding our Tamarin post today:
++
+ +]]>Good news, everyone!
+Recently we have been puzzled by some statements of Brendan Eich, the creator of the JavaScript programming language.
+In Brendan's blog he wrote "For Mozilla 2, we will have a JIT-oriented JavaScript VM (details soon) that supports the forthcoming ECMAScript Edition 4 ("JS2") language" (October 13, 2006). Well, could hardly wait for any details. Another statement that made us curious was at The Ajax Experience this fall. In his slides about JavaScript 2.0 he mentioned "Open source optimizing VMs coming soon. Look for an announcement in a few weeks" (October 25, 2006). Interestingly, this mysterious announcement was in a section he called "JavaScript Fun Facts".
+Well done Brendan, you are our Master of Suspense! Finally, as a revelation today came the announcement that is going to boost JavaScript. Congratulations to Adobe for their decision of contributing the ActionScript Virtual Machine (AVM) as open source to the Mozilla project. And a warm open-source welcome to all the developers of the AVM! The code has just been committed into the Mozilla repository.
+This is great news for qooxdoo being a client-side JavaScript framework. Performance has always been one of our major concerns, and we think we have pushed the limit for JavaScript based web applications, e.g. for qooxdoo's powerful browser-independent layout engine. Can't wait to tweak the last bit of performance out of any new Mozilla browser backed by the new JavaScript VM. This is going to change the future of browser-based applications. Cheers!
++
+ +]]>In my opinion there was never a reason why JavaScript should be slower than other typical script languages e.g. Python, Perl, Ruby, … With the newest committment from Abobe to Mozilla we could reach a new level of performance in web applications.
+As news.com reports "Adobe will provide the same software, called the ActionScript Virtual Machine, which it uses to run script code in the Adobe Flash Player 9. This virtual machine is expected to be built into future versions of the Firefox browser by the first half of 2008, said Frank Hecker, the executive director of the Mozilla Foundation."
+Via news.com
++
+ +]]>A few hours ago I've committed a change which adds a variable name optimizer into the qooxdoo trunk. This optimizer replaces the names of local variables with shorter ones. The result is a size reduction of the compiled JavaScript file by 10%. This new behavior is enabled per default for all the included Makefiles. So after an SVN update you can build your (again) better optimized version of qooxdoo.
+This can also been seen as a next step in bringing support for obfuscation another step forward. I have also updated the online demos and the API viewer to use this new feature. I would like to invite you to give me feedback as soon as possible. Maybe you also find some bugs. If so, please report them immediately. Thank you.
++
+ +]]>The guys at ajaxian.com have reported about a current survey regarding the popularity of common AJAX frameworks. It is quite clear why prototype is the winner. It's well-known, small and easily embedable into existing pages. However I think it is interesting that Mochikit is less widely used, because the targets of these libraries are comparable in my opinion. And Mochikit does not depends on extensions of native objects (especially Object.prototype) which makes it the better choice.
+I should mention that in my opinion the whole survey is quite problematic because of their comparison of different levels of so named "AJAX frameworks". For a next survey I would suggest to divide the list into these groups:
+AJAX wrappers & DOM utilities:
+Framework & Toolkits:
+I've grouped together Scriptaclous and Rico because they both depend on Prototype which means they are more or less an extension of this library and not a real separate solution.
+What do you think?
++
+ +]]>Really good news. My vocabulary may to be too limited to tell you how great the latest changes in IE7 RC1 are. Microsoft announced that they have "recently made some great fixes to our engine to improve the garbage collection routine and to reduce unbounded memory growth." and that one "should see noticeable improvements on AJAX sites in the Release Candidate we shipped last week". Yes indeed, we do see tremendeous improvements.
In fact many demos of qooxdoo run much faster now in IE7 compared to IE6. And they are even faster than in Firefox 1.5 in many cases. This is a huge jump in performance. Microsoft did not tell about their exact modifications, of course. Anyway, they have fixed the major problem of large JavaScript-based web applications. This problem, despite having a catchy name, was mentioned many times before like here, here and there: If you have many objects created, which are simply accessible in the current scope, all methods and features of JavaScript slow down dramatically. Yeah, right, the entire execution speed drops significantly. No other browser besides IE shows such a strange behavior. It is quite interesting that IE6 really gets slower the larger the total number of (accessible) objects. Sure, it is logical that more instanciated objects need more memory, but it is not logical that at the same time this will dramatically reduce the performance of any code (that is not even accessing this data).
+With the release candidate RC1 of their new browser version IE7, it seems that they have finally fixed this issue. You can test it yourself in this test case, which has been available in qooxdoo for several months to analyze and measure the IE performance problems. Please look at status bar of your browser (maybe you need to enable the status bar in the IE7 security settings). It will display the execution time of each loop while a large number of objects exists. On my machine the IE6 needs ~1400ms, while IE7 needs ~30ms, which is roughly the time Firefox 1.5 needs. Definitely incredible! Bright future for modern web applications.
+
+ +]]>Despite of the minor change in version number, this release is again a major step in strengthening qooxdoo's position of being one of the most comprehensive and innovative AJAX frameworks. It now even includes support for WebKit and future versions of Safari!
+It came as quite a surprise how many fixes, changes and additions we were actually able to include in this fine little package. During the eight weeks after release 0.6.1, many people have made contributions. Thanks to all qooxdoo users, contributors, patch monsters and supporters for helping to make the framework more mature and feature-complete!
+Targeted as a maintenance release it includes many bugfixes and only minor changes in functionality or API. We recommend to upgrade any applications based on qooxdoo 0.6.1. Of course, there is migration support available, even if it is hardly needed this time.
+As mentioned above and already announced in our developer blog, qooxdoo now includes support for WebKit. We expect to fully support the next major version Safari 3.0 which will be based on the current development of WebKit. There is only limited support for Safari in its current version 2.0.4, though. Reason is, that Safari 2.0 still has many bugs that can hardly be worked around. Luckily, many of those bugs are already fixed in the nightly builds of WebKit. Besides the various bugs, Safari 2.0's JavaScript engine and its execution speed is not competitive with respect to the latest versions of the other major browsers (Firefox 2.0, IE7, Opera 9). Good news is, that the current builds of WebKit are tremendeously faster than Safari 2.0, approximately by a factor of 7-8 for a typical qooxdoo demo.
+We think it is worth to either use WebKit for now or wait for Safari 3.0 due in early 2007. There is probably not much sense in devoting more time and effort for Safari 2.0 specific problems. There are still some known issues concerning WebKit support (particularly for widgets that use scrollbars). It would be great if Mac users could give qooxdoo 0.6.2 a try and report any problem in bugzilla. Please use the most recent nightly build of WebKit and include its version information in any bug report.
+For more detailed information about qooxdoo 0.6.2 please consult the corresponding release notes.
+Enjoy!
+ + +]]>Good news to every developer of modern web applications. After more than 5 years (IE6 was released in August 2001) we all hope to see IE7 fix some of the most severe problems and bugs of IE6. All qooxdoo-based applications are expected to benefit from IE7, particularly due to the dramatic JavaScript performance improvements that we reported earlier.
+qooxdoo fully supports IE7. It would be great if qooxdoo users and developers could continue to test and double-check their applications for IE7 compatibility. Please report any IE7 issues in bugzilla as soon as possible.
+Enjoy … and good luck!
++
+ +]]>After only two weeks since the ground-breaking release of qooxdoo 0.6 quite a lot of progress has been made. We have received many contributions and bugfixes from the community. These patches as well as our own modifications have been integrated into the code base in the ongoing effort to raise qooxdoo's stability.
+As has been previously announced, we try to release often, now that some of the most challenging reconstructions like namespaces have been mastered. While API changes for this minor release are negligible, migration scripts are available to upgrade existing applications, of course.
+Preliminary browser support for Safari has been introduced. It would be great if Safari users could help in identifying, analyzing and fixing the various layout problems. It is still not recommended to use qooxdoo applications in Safari-based production environments.
+Besides bugfixes and stability improvements there are some interesting additions as well. Tabs may optionally include close buttons, the tree widget TreeFullControl now supports multiple root nodes. Iframes containing external documents now have built-in blocking support to not interrupt user actions like drag & drop.
+Application development is even faster than before: the easy-to-use make shell commands that generate optimized and tailor-made custom applications run much faster. Users get a jump-start for their application development by using the skeletons included in the qooxdoo SDK.
+We would like to thank all people involved in qooxdoo development for their help and contribution. Every user's feedback is important to continuously improve qooxdoo as one of the most amazing JavaScript frameworks around. Enjoy!
+ ++
+ +]]>Here comes the most advanced qooxdoo version ever! qooxdoo 0.6 introduces namespaces as the most noticeable change. This step has been combined with a long thought-out and at the end well-structured directory layout.
+Integrated is one of the most advanced build systems. This new system allows you to generate tailor-made user applications linked against the qooxdoo framework. You can even include your own project classes and optimize them along with qooxdoo. Using this new build system you can generate blazingly fast and highly optimized qooxdoo builds.
+A new ground-breaking qooxdoo-based API viewer was added to make software development with qooxdoo easier than ever before. Supposed to become every qooxdoo users' number one resource, it shows all available packages, classes, properties and methods. All related information is connected by hyperlinks which gives you a highly convenient way to access the relevant information.
+Of course there are also new widgets. A new advanced table widget has been introduced which is a virtual list view component that allows to handle many thousands of entries. Its features also make it possible to dynamically load the data from a remote server (using RPC for example). A splitpane - one of the long-awaited widgets - is now included. Full-blown logging capabilities featuring various appenders are available as well.
+There are a lot more changes and enhancements. For details please take a look at the release notes. Migration support simplifies the switch from the last qooxdoo release 0.5.3. qooxdoo 0.6 is the perfect framework to build highly-interactive web applications. Why don't you start now? Just download qooxdoo today!
++
+ +]]>Another step forward to highly optimized applications based on qooxdoo: I would like to introduce the tree "compiler". The tree compiler is able to "compile" a syntax tree (generated by treegenerator.py which uses the tokenizer.py) back to optimized JavaScript code. Its feature set is comparable to the old compiler, which was directly based on the result of the tokenizer.py script. It completely removes comments, whitespaces and other optional stuff from the original JavaScript code.
+This tree compiler is an important step, because it will allow us to do the following awesome things in the future:
+etc.
+Now the interesting part: The tree compiler is the default from now on. It is already available in SVN and will be in the final release of qooxdoo 0.6. The tree compiler was tested against qooxdoo and another big internal project so we think it's quite stable already. It may not be free of bugs however, but I'm happy to fix bugs as fast as you can report them
If you have problems with this new compiler, you can use the old one using the "–use-token-compiler" argument (generator.py). Each Makefile which is included in qooxdoo, has a new variable (OLDCOMPILER) in the first lines of the file which lets you select the compiler (simply set it to "true").
+I hope you enjoy this new era of JavaScript optimization. Kudos to Til - without the treegenerator.py developed by him, qooxdoo would maybe not have seen such a tree-based optimizer.
+You can immediately test the new compiler. Its results can also been seen online in the online demos and the API viewer.
+For all SDK/source version users: Please make sure to delete the directory ".cache". A simple "make distclean" will do this for you.
++
+ +]]>Many aspects of qooxdoo have been improved to make it an even more professional and complete JavaScript framework.
+A lot of issues, that have been brought up and discussed on the mailing list before, have been addressed. Some of the most noticable additions include a qooxdoo-based viewer for the auto-generated API documentation, a more powerful virtual list view and a smart build process that makes optimizing, compressing, linking and deployment of custom applications a snap.
+A Release Candidate 1 is now available for easy download. That way people can immediately start to get themselves familiar with the most important improvements.
+We would like to thank all users, contributors and fellow developers for their ongoing help and support. Keep up the good work!
+ + ++
+ +]]>IMPORTANT: Until recently the major development work towards the next release 0.6 has been done in a development branch named "namespaces". This branch is now discontinued. Its content has been transfered into the SVN trunk.
+Future development of qooxdoo will concentrate on changes made in the trunk. Anyone interested in an up-to-date version of the framework should simply checkout the latest revision of the SVN trunk . Clearly, these snapshots are not expected to be stable enough for production use. They are not even supposed to be functional at all. It may happen that the trunk is broken for not only hours (delibaretely) but even days (rather by accident). Think of the trunk as a permanent work-in-progress that after potentially unstable phases finally leads to the next official release.
+The content of the previous SVN trunk has been moved to a branch named "legacy_0_5_x". This branch may see some changes, particularly bugfixes and backports of modifications made in the trunk. Please do not expect many substantial improvements in this 0.5 line of qooxdoo, though. There may be a release 0.5.4 sometime, but this clearly depends on user contribution for this now "old" line of qooxdoo.
+Please note, that the existing documentation has still to be updated to reflect the switch from the "namespaces" branch to the trunk. Information formerly specific to the "namespaces" branch should now be valid for the trunk.
+We are getting closer to qooxdoo 0.6
+
+ +]]>There is an extended update of an older post with respect to new features and modifications that are currently being implemented.
+All interested qooxdoo users are welcome to bring themselves up-to-date and are invited to get involved in qooxdoo development. It takes not more than checking-out qooxdoo from a subversion repository and doing a "make" on your shell afterwards.
+A couple of significant differences that are being addressed are:
++
+ +]]>You can register yourself to always stay up-to-date with the further development of qooxdoo. +
+ +]]>Please join me in congratulating Rob. +
+]]>Please join me in congratulating Sam.
+]]>Another tip you might find handy as a web developer is the “Show Page Load Test Window” option in the Safari Debug menu. You can turn on the Debug menu by typing defaults write com.apple.Safari IncludeDebugMenu YES
at a shell prompt, and then restarting Safari. This menu includes a number of rough debugging tools that we created mainly for browser testing, but you may find some of them handy for web development. The page load test in particular is interesting because it measures page load time in a more precise way than either onload timing or just using a stopwatch. If you change the “Suite” pop-up menu to “URL”, you can type the URL of your choice and get a fairly precise time for loading it. If you empty the cache first, you can get an uncached time.
I recommend trying this a couple of times as you test your site. We’ve found that it’s a lot easier to improve performance when you have a precise way to measure it.
+]]>Even more exciting, Adobe has announced that Apollo will use WebKit as its HTML layout engine. Welcome to the world of WebKit, Adobe.
+]]>First of all, if you correct unprofiled images to sRGB, you have to correct all drawing to sRGB. This includes everything drawn by CSS (borders, backgrounds, text). This is not difficult to do under the hood, although it is difficult to do it with no performance regression in our benchmarks at all. In fact we even tried this during the Tiger development cycle (just correcting everything drawn to sRGB), but it slowed us down.
+The big hurdle that we ran into, though, was with the drawing we did not control, namely the Flash plug-in. The problem is that designers specify colors in Flash and colors in CSS in the Web page, and they expect those colors to match. Because Flash’s drawing isn’t correcting to sRGB, if we did it in Safari, there would be color mismatches all over the place. These mismatches look far worse than if we just don’t correct at all.
+(This mismatch with plug-ins is presumably the reason that this feature was not enabled by default in Mac IE.)
+]]>Major new features of 4.5 include complex password enforcement, identities, personal distro lists's, server performance improvements, backup/restore in the admin console, a search builder in the admin console, user-set default fonts for HTML compose, an upgrade to use MySQL 5.0, and a Lotus Domino migration wizard. More details can be found in the beta release notes.
]]> + +
+
... speaking of AOL (I don't mean to pick on AOL, even the newly warm and fuzzy
+AOL, but they make it really easy), one of their minions gave a keynote during
+which he screened a movie where they went up to people on the street or in the
+grocery store and asked them what they thought "Ajax" was. And OH MY GAWD (the
+voice here should be Dr Cox from Scrubs), they thought it was a cleanser! What a
+bunch of losers!
Crikey.
+ +... really regret my get-out-of-Dodge trip planning, which made me miss Brendan
+Eich's closing keynote on Javascript 2.
... "stack" is the new "solution".
+ +... Selenium, a product for doing functional client
+testing in an Ajax environment, got a lot of buzz. Our QA team is looking into it. They've had to
+pound on Mercury's QTP pretty hard to get it to work with our client, and I'm hoping
+Selenium will be way more straightforward.
... the booths from some of the sponsors such as Google, Sun, and Ask were more
+focused on recruiting than on demos, always a sign of a technology on its way up.
... after the experts' panel on Monday night, I headed to the hotel bar and met
+up with the Netflix crew. As a longtime Netflix member, I couldn't resist rattling on
+about what I liked and disliked about their site and service. Not only did they
+listen - brave souls - they bought me beer. The more beer I had in me, the more
+clever and insightful I became, and I think they caught on to that.
The Netflix UI makes for a great case study in how going from HTML to Ajax
+can improve the user experience.
... there is a bewildering array of Ajax toolkits out there, and at least two of
+the presentations were overviews of frameworks. The space has exploded, and
+sooner rather than later, it will contract. Documentation, often overlooked,
+will be key to adoption. It's hard to bet against
+Dojo, with its breadth, careful design, and technical impressiveness.
+I heard good things about jQuery, and YUI looks clean. For all-Java shops there's
+GWT, and possibly DWR.
... My ad hoc plan of attack, and reviews, in order of attendance:
+ +Leveraging Ajax for Enterprise Application Development - mostly good
+content, somewhat awkwardly delivered. Best part was practical tips for shops
+coming up to speed on Ajax.
Javascript Exposed: There's a Real Programming Language in There (Pt 1), by
+Glenn Vanderburg - had intended to go to Mahemoff's talk on design patterns, but
+he didn't make it to the conference. Glenn's an engaging presenter, which eased
+the fact that it was mostly a tutorial of what you'd find in the O'Reilly book.
+Glenn did a good job of focusing on important bits of the language that are
+often glossed, and I really liked his lists of what he believes the language
+designers got right and wrong.
Ruining the User Experience, by Aaron Gustafson - the scope of this presentation
+was smaller than I had hoped. From the summary, I thought it would cover UI
+idioms that have been made possible by Ajax but which don't improve the user
+experience, but it was almost all about what to do when Javascript is
+disabled.
Frameworks Guide, by Nathaniel Schutta - came to this one as a refugee from a
+TIBCO-centric talk on building desktop-like apps in Ajax. It was good to get an
+overview, delivered capably and neutrally, since having developed our own
+toolkit I'm not familiar with others.
Intro to Dojo / Dojo in Depth, by Alex Russell - Dojo looks pretty awesome, and
+Alex is super-smart. Dojo obviously goes beyond Ajax, and even within Ajax it
+offers much more than widgets and neat effects. Their event system, the new
+SVG/VML support, and XhrIframeRequest were highlights. I'll be looking soon into
+using its package system to leverage deferred loading of ZCS components.
IE7: From Ajax to RSS and More: How to Take Full Advantage, by Chris Wilson -
+acutally: quite: interesting. IE7 will make app developers very happy, and app
+maintainers very unhappy. It's really frightening to think of the untold numbers
+of websites out there that rely on the many ways in which IE6 is broken (insert
+truism about reaping what you sow). As much grief as they deservedly get, MS
+appears to be committing to standards as far as its browser goes (thank you,
+market forces). Best news for me is that they fixed the garbage collector, so
+memory no longer leaks at the drop of a hat. They also fixed the SELECT
+element's behavior with regard to z-index, the gzip caching problem, and untold
+CSS bugs.
JSON: The X in Ajax, by Douglas Crockford - the case for JSON is a strong one,
+as XML is often overkill for shuttling data around. I love its simplicity and
+compactness. Of particular interest: JSONRequest and a proposed MODULE tag to
+address cross-domain security issues. Near the end there was an odd moment when
+John Resig (jQuery) posed a reasonable-sounding question about whether JSON
+performance scales well across large datasets when compared with XML, and the
+immediate response was "Next question." Not sure what to conclude from that.
Designing for Ajax, by Bill Scott - bailed on a performance talk that turned out
+to be Gomez-centric and came here. Great presentation. Bill used Yahoo as well
+as other sites to point out good and bad Ajax-enabled interaction patterns.
+Makes me want to check out the Yahoo design patterns library.
Case Study: Building Great UI, the Netflix Way, by Sean Kane - everyone loves
+Hypnotoad, I mean Netflix. What was interesting here (aside from the obvious
+fascination with the service) was how extensively they test in UI labs with
+regular folks before rolling out changes, often trying out several possible
+versions of a UI feature. It would be nice if we could eventually get real-world
+data like that.
So now that Firefox 2 has been officially released, how does if fare against IE 7?
+ +We ran each browser over a common set of Zimbra Web Client (ZWC) operations such as logging in, viewing messages, navigating around various folders, changing options, viewing contacts, and performing various calendar operations. As the graph below shows, Firefox 2 beat out IE 7 in just about every operation - sometimes by significant margins.
+ + + +We also tested Firefox 2 vs Firefox 1.5. As seen below, Firefox 2 has not made substantial performance improvements over Firefox 1.5, and has certainly not shown the same order of gain as IE 7 has over IE6.
+ + + +I think the net result is that for highly JavaScript intensive AJAX applications such as the ZWC, Firefox is still the winner by quite a wide margin. Of course your mileage will vary depending on the type and footprint of your client.
+ +I would like to end by saying that we are able to present this data thanks to lots of hard work by Raja Rao of the Zimbra QA department who has spent many long hours building our AJAX client testing framework, and executing the performance tests against the various browsers.
]]> +"From a Web 2.0 application developers perspective (developers who use a lot of JavaScript and DOM manipulation), IE 6 is plagued by a number of well known problems such as its ability to readily leak memory. Regrettably, Microsoft's next release of Internet Explorer, IE 7, does little to resolve these issues."
+ +I am happy to say that I was wrong.
]]> +Microsoft's IE team has clearly been hard at work on improving their browser's memory management and JavaScript performance. IE 7 has made some significant leaps forward based on some initial in house testing here at Zimbra. We are in general observing about a 2x performance improvement with IE 7 vs IE 6 when using the Zimbra Web Client (ZWC). + +As is well documented, IE 6 is notoriously bad at leaking memory, particularly due to circular references that include COM objects. The good news is that our tests indicate that this problem has been solved in IE 7. While in our test profile, it appears to consume more memory than Firefox, IE 7 seems to have solved the horrendous memory leaks exhibited in IE 6.
+ +We also looked at the performance of Firefox, IE 6, and IE 7 over a set of common ZWC operations such as logging in, viewing messages, navigating around various folders, viewing contacts, and performing various calendar operations. The graph below shows the relative performance of each browser against the other:
+ + + +Again we see that across just about every operation, IE 7 performs better than IE 6; however, for the most part Firefox still beats out IE 7. When we looked at the sum total time it takes for all operations to be performed (admittedly a coarse grained metric), we noticed that IE 7 was about twice as fast as IE 6; however, Firefox was more than twice as fast as IE 7 and about four times faster than IE 6.
+ +In conclusion, IE 7 has made some quite significant improvements over IE 6, both in terms of performance and memory management; however, there is still room to improve - particularly against Firefox, a challenge I hope the IE team will be taking up.
]]> +Yes, the "2.0" hype is getting out of hand. However, just as with Web 2.0, the technology evolution we are participating in is sufficent to at least justify the discussion. So while I am still dubious about the Office 2.0 moniker, there is no doubt that the Web authoring, sharing, and collaboration technologies under the Web 2.0 umbrella are allowing us to do many of the things we used to do within proprietary Office 1.0 desktop applications, and to do so from any browser on the net. So before you dismiss Office 2.0 as yet another buzz word du jour, please consider some (modest) over-generalizations:
]]> +Office 1.0 Users: Power users (information workers/professionals)1.0 Model: Client-centric (desktop applications)
+2.0 Model: Network-centric (web applications)
1.0 Sharing (in the small): Pass by value (Email), pass by reference (Public folders)
+2.0 Sharing (in the large): Adds the ability to use the Internet to pass by value (Email, VoIP, IM, ...) and (effectively) by reference (XHTML pages/hyperlinks, Wiki, Blogs, iCalendar/CalDAV, iTasks, WebDAV, ...), all with access control
1.0 Navigation (sans meta-data): Folders
+2.0 Navigation (with meta-data): Hyperlinks, indexing & search, tagging, mash-ups …
1.0 Editing: Via proprietary desktop applications; WYSIWYG with change tracking
+2.0 Editing: From any browser; WYSIWYG (via Ajax authoring) with versioning and history
1.0 Data types: Proprietary
+2.0 Data types: Open (XHMTL, ODF, microformats, XML such as via Service-Oriented Architecture/SOA, REST, SOAP, etc.)
1.0 Content: Relatively static, with intra-desktop dynamic components
+2.0 Content: More dynamic (including web application-generated content, SOA mash-ups, …)
1.0 Multi-document: Object Linking & Embedding (OLE), Bonobo, …
+2.0 Multi-document: Hyperlinks, Ajax Linking & Embedding (ALE), mash-ups, ...
(No doubt the above takes a rather expansive view of Office 2.0, but then again Office 1.0 arguably covered most all computer-assisted authoring of content. Please also note: The above content would have proved substantially more compelling in an HTML table authored, say, with a WYSIWYG Ajax editor, like that included within the Zimbra Documents applications.)
+ +All this is not to say that Office 2.0 can or should supercede Office 1.0---Zimbra spreadsheets, for example, will not support pivot tables any time soon. I believe our goal should not be to reproduce Office 1.0 functionality on a Web 2.0 platform, but rather to realize an easier to use (a.k.a. less complex) collaborative authoring and sharing model that scales with the Internet. Office 2.0 users should be able to (1) author content from anywhere; (2) appropriately reuse and adapt (mash up) content (both static and dynamic) already published on the Internet; and (3) securely collaborate with others in whatever ad hoc fashion best meets their needs. The fun with "Office 2.0" is that thanks to the maturing of the underlying Web 2.0 technologies and near universal success of the Internet, this vision is close to realization.
+ +One thing I'm not yet happy with is that the above description does not draw a very compelling line between Web 2.0 and Office 2.0. Some technologies are more obvious: for example, Ajax, RSS, and SOA/XML fit under Web 2.0, while Ajax authoring and ALE arguably fit more naturally under Office 2.0. Given the emphesis on collaboration and authoring inherent in the Web 2.0 definition, I think these two potential categories are going to be tough to keep separate. After all, both Office 1.0 and Web 2.0 are about authoring rich content---the difference is that the former is focused on the desktop and "sharing in the small", while the latter is targeting the network and "sharing in the large". Office 2.0 then may merely mean leveraging Web 2.0 technologies to do many/most (?) of the things we used to do in Office 1.0.
+ +(Some of this thinking came out our our panel session at the Office 2.0 Conference in San Francisco, and our Web 2.0 Kongress session in Germany the day before. Just doing our bit to keep the airlines in the black :-).)
]]> +Thurs, October 5th at 10am PST. Length: 60 minutes.
+ +Subject: Modern Collaboration with Zimbra Collaboration Suite (ZCS) 4.0
+ +Overview:
+Fueled by demand for better productivity, the web is exploding as the primary communication medium for the modern organization.
ZCS leads the way, providing powerful next-generation messaging and collaboration.
+ +Join our CTO Scott Dietzen for this free live webinar to see:
+ + * How ZCS 4.0 is the right solution for today's collaboration demands
+ * Discuss and demo features such as Zimbra Documents, Admin UI, Zimlets, Mobile device sync, Active Directory integration and more…
+ * Why ZCS 4.0 enables organizations to realize the true benefits of an innovative and cost-effective collaboration solution.
+ * Plus live Q & A
Sign up:
+ +Please register; space is limited!
]]> + +Here's a sample of some of the other changes/fixes in 4.0.2:
+ +- perf improvements for IMAP (new MySQL indexes)
+- > 2GB support in the Zimbra Outlook Connector
+- i18n and some l10n for the Zimbra Outlook Connector
+- disabling AS/AV causes mail deferral
+- cursor fails to appear in Firefox
+- mailbox quota page does not contain any entries
+- several all day event and timezone bugs fixed
Unfortunately, one of the more common complaints against web-based applications is that they are, in many instances, lacking when it comes to supporting keyboard shortcuts and navigation. Frankly, the lack of keyboard support (both shortcuts and navigation) is something that has annoyed me about the Zimbra Collaboration Suite (ZCS), and it is something that I have been wanting to add to both Kabuki (the Zimbra Ajax Toolkit) and the ZCS; however, I didn't want to just stuff in some basic keyboard shortcuts and call it a day. Instead, I wanted to have a go at implementing the same level of keyboard support that most traditional UI toolkits and desktop applications support. This actually turned out to involve quite a bit of work - for example, since only input elements may have focus (in most browsers) we needed to simulate and track focus for toolkit components which frequently have no native input element associated with them - but at the end of the day, I think it was worth the effort.
]]> +So the good news is that Kabuki now provides a pretty rich keyboard model that in many ways approximates the level of support found in more traditional UI toolkits. Specifically, this includes support for a canonical focus model, customizable key bindings in UI widgets (not all of them just yet), as well as full support for tab group hierarchies for navigating native and toolkit visual components in an orderly fashion via the tab and arrow keys. Conrad (one of Zimbra's lead Ajax architects), took this work to the next level by implementing keyboard navigation and shortcuts throughout the ZCS and by improving the framework itself. As a result the ZCS now has significant keyboard support in version 4.0, about 80% coverage at the moment, and we are working towards making that even higher. Future work also includes normalized mappings among browsers (very high on our list), I18N support, and supporting custom user-defined bindings. + +The bottom line is that the ZCS now supports some pretty spiffy keyboard actions (over 100 of them) including:
+
You can find a more complete list of supported keyboard events on the Zimbra Wiki
+ +Now onto some of the more technical details on Zimbra's keyboard support.
+ +The keyboard management infrastructure is implemented in the DHTML Widget Toolkit (DWT), which is the Kabuki Ajax toolkit's UI framework. DWT consists of a component model, numerous widgets, an event model, drag and drop infrastructure, and now a keyboard shortcut and navigation model. DWT is loosely modeled after SWT. There are several elements that compose DWT's keyboard management framework:
+ ++A key map is a set of key bindings. A key binding maps a key sequence to an action. For example, I may decide that "Ctrl+U" marks an email message as unread, or I may decide that a multi-key sequence such as "Ctrl+N" followed by the letter "M" will create a new mail message (Note that by default, there is a 750ms timeout between keys for a multiple-key sequence, though this is configurable via the DwtKeyboardMgr class described later). + +
DwtKeyMap is the base class for key maps and provides bindings for DWT widgets. Below is a snippet from DwtKeyMap's constructor showing the key bindings for some of the widgets. Note how key sequences bind to the symbolic constants representing keyboard actions:
+ ++function DwtKeyMap() { + [snip...] + this._map["DwtDialog"] = { + "Enter": DwtKeyMap.ENTER, + "Esc": DwtKeyMap.CANCEL + }; + this._map["DwtButton"] = { + "Enter": DwtKeyMap.SELECT_CURRENT, + "ArrowDown": DwtKeyMap.SELECT_SUBMENU + }; + this._map["DwtListView"] = { + "Space": DwtKeyMap.SELECT_CURRENT, + "Ctrl+Space": DwtKeyMap.ADD_SELECT_CURRENT, + "Ctrl+`": DwtKeyMap.ADD_SELECT_CURRENT, // Mac FF + "ArrowDown": DwtKeyMap.SELECT_NEXT, + "Shift+ArrowDown": DwtKeyMap.ADD_SELECT_NEXT, + "Ctrl+ArrowDown": DwtKeyMap.NEXT, + "ArrowUp": DwtKeyMap.SELECT_PREV, + "Shift+ArrowUp": DwtKeyMap.ADD_SELECT_PREV, + "Ctrl+ArrowUp": DwtKeyMap.PREV, + "Ctrl+A": DwtKeyMap.SELECT_ALL, + "Home": DwtKeyMap.SELECT_FIRST, + "End": DwtKeyMap.SELECT_LAST, + "Enter": DwtKeyMap.DBLCLICK, + "Comma": DwtKeyMap.ACTION, + "Shift+Comma": DwtKeyMap.ACTION, + "Ctrl+Enter": DwtKeyMap.ACTION, + "Ctrl+M": DwtKeyMap.ACTION // Mac FF + }; + this._map["DwtMenu"] = { + "Esc": DwtKeyMap.CANCEL, + "Enter": DwtKeyMap.SELECT_CURRENT, + "ArrowDown": DwtKeyMap.SELECT_NEXT, + "ArrowUp": DwtKeyMap.SELECT_PREV, + "ArrowLeft": DwtKeyMap.SELECT_PARENTMENU, + "ArrowRight": DwtKeyMap.SELECT_SUBMENU + }; + [snip...] +}; ++ +
Applications may inherit from the above class and add their own maps or override existing ones (for example when subclassing widgets). Note that component and application authors don't need to worry about key sequences, rather they just need to implement the actions that their components support. The keyboard management framework takes care of handling the mapping from key sequences to actions. Once a key sequence has been mapped to an action, the action is passed to the handleKeyAction() method defined by the component (See the sections of DwtKeyboardMgr and DwtControl below for more details).
+ +Decoupling key bindings and actions makes it easy to change the key binding for a given action, or to allow multiple key bindings for that action. Key maps may inherit (including multiply) from other key maps. This allows for extensions as well as application-wide (or default) key maps.
+ +The sample code below shows a portion of the ZCS's key map. Notice how the ZmMailListController inherits from the Global key map.
+ ++function ZmKeyMap() { + this._map["Global"] = { + "`": ZmKeyMap.ASSISTANT, + "Shift+`": ZmKeyMap.ASSISTANT, + [snip...] + } + this._map["ZmMailListController"] = { + "INHERIT": "Global", + "R": ZmKeyMap.REPLY, + "A": ZmKeyMap.REPLY_ALL, + "R,S": ZmKeyMap.REPLY, + "R,A": ZmKeyMap.REPLY_ALL, + [snip...] + } + [snip...] +} ++ +
Key map entries may consist of:
+ +We are currently working on a serialization/deserialization interface so that key maps may be serialized to and deserialized from a textual representation. This will help in with localizations and custom/user defined keymaps, and will do away with the need for the hash tables shown above.
+ ++ +
Tab groups permit the definition of a hierarchical keyboard navigation model. A tab group is a tree structure where the intermediate nodes in the tree are other tab groups and the leaf nodes are focusable components i.e. DWT widgets and/or focusable native HTML elements such as input fields. Tab groups represent the order in which components that the user sees on the screen are traversed via the keyboard. The tab group hierarchy (or tree) is traversed "in order" by the user pressing the tab key, or in reverse order when the user typically presses the shift key plus the tab key.
+ +There is a special tab group called the root tab group. A root tab group has no parent and represents the keyboard navigation order for the components in a given application view. There can be multiple root tab groups within an application, e.g. an email message list view tag group, a calendar new appointment tab group, or a dialog tab group; however, only one root tab group may be active at any given time.
+ +As will be described in the section on DwtKeyboardMgr, tab groups may be "pushed to" and "popped from" the tab group stack. For example, when a dialog is popped up, its corresponding tab group is pushed onto the tab group stack and becomes the active tab group while that dialog is activated. When the dialog is popped down, its tab group is also popped off the tab group stack bringing the underlying tab group (i.e. the one for the active view) back into play, so that the component that had focus prior to the dialog being activated will once again have focus.
+ +Tab groups are implemented by the DwtTabGroup class. That class provides the API for manipulating tab groups. Here are some of the member methods:
+ ++ +
DwtKeyboardMgr is the engine that drives the keyboard management framework. It is responsible for intercepting key events generated by the browser, mapping them to actions (via the registered keymaps), and then dispatching the action to the correct component. In addition, DwtKeyboardMgr is responsible for enforcing the tab order specified by the currently active tab group. Finally, this class also has the machinery that handles multi-key keymap entires by utilizing a timeout mechanism for resolving such sequences.
+ +When dispatching actions, DwtKeyboardMgr will first try and resolve a key sequence with the component that has focus (be it a DWT widget or a native component such as an HTML input element). If the component does not have an action binding for a key sequence (an entry in its key map for the current key sequence), then DwtKeyboardMgr checks to see if a default handler has been pushed on its default handler stack (via the pushDefaultHandler method). If one has been pushed, then DwtKeyboardMgr will query it for the name of the keymap that should be used to resolve the key sequence to an action code. If an action code exists in the key map for the key sequence, then DwtKeyboardMgr will dispatch it to the default handler.
+ +A default handler is analogous to the root tab group. It provides a context for key bindings that are not tied to a specific widget. In a way, the default handler can be thought of as providing a global context. For example, if a button has focus when the character Esc is typed, DwtKeyboardMgr will first give the button a chance to handle the event. If the button does not handle Esc (which is the case), then DwtKeyboardMgr hands the event to the current default handler. So far, there are only two default handlers used within ZCS: an application-level default handler and a dialog-level default handler.
+ +A default handler must implement the following interface:
+ +As previously mentioned, DwtKeyboardMgr is also responsible for enforcing the component tab ordering specified by the currently active root tab group - i.e. the one that is on top of the tab group stack. The way this works is that upon intercepting the tab key, DwtKeyboardMgr will call the DwtTabGroup's getNextFocusMember() method. This method returns the next focusable component in the tab group hierarchy (be it a DWT widget or a native HTML input field). DwtKeyboardMgr will then call the blur() method on the previously focused component, followed by calling the focus() method on the component returned by getNextFocusMember(). Note that I intentionally paralleled the native HTML input element focus() and blur() methods within DWT so there is a canonical way of managing the focus state of any UI component (native or DWT). The combination of DwtKeyboardMgr and DwtTabGroup handles all corner cases such as skipping over components that are not enabled (i.e. grayed out), as well as dealing with scenarios such as the currently focused component becoming disabled.
+ +The following lists some of the more commonly used methods provided by DwtKeyboardMgr:
+ ++ +
DwtControl is the base DWT class from which all widgets ultimately inherit behaviour. DwtControl has a number of responsibilities including hooking into the drag and drop system, basic mouse event handling, and integration with the keyboard shortcut and navigation model.
+ +DwtControl exports public focus() and blur() methods that parallel the native HTML input elements so that there is a canonical set of methods for setting and blurring focus across native and DWT elements. DwtControl also declares four methods that widget authors must implement in order to support keyboard management:
+ ++ +
An application programmer wanting to use the keyboard management frameworks typically needs to perform the following steps:
+ +Ajax security considerations. Subject to the additional precautions enumerated below, Ajax applications can be made as highly-secure as the web technologies upon which the Ajax model is based.
+ +The most obvious security issue for Ajax applications is that the associated source code is inherently downloaded to the browser for interpretation. This is a concern for any application logic that contains intellectual property that the author does not want to share with the world: while obviscation and minimization (white space removal, shortening identifier) can certainly render JavaScript much harder to read (and debug), developers should consider Ajax applications to be like HTML in that others will be able to examine the fruits of your labor. The only real alternative is to either (1) limit log-in to the application to trusted users/partners (in this way only licensed/authorized users get to download the Ajax application logic); or else (2) keep closely-held algorithms on the server-side, and simply invoke them via web services from the Ajax client. All this is not an issue for the Zimbra Ajax Client, since it is, after all, open source.
+ +Zimbra provides the following additional guarantees to further secure Zimbra deployments over even public networks, techniques that we beileve are broadly relevant for securing Ajax applications:
+• Use SSL/TLS (i.e., HTTPS) – In addition to protecting the privacy/integrity XML/JSON HTTP communications to/from the Ajax client, SSL/TLS encryption limits access to the Ajax source code itself to only those that have legitimate log-ins (as per above), since no-one snooping on the network can see the app. logic. Moreover, SSL/TLS protects the Ajax application (JavaScript, CSS, etc.) from potential security attacks while it is in route to the user's browser.
+• No server-side interpretation of JavaScript or other client-submitted code – Zimbra receives vanilla XML requests from the browser client that are validated and then processed by Zimbra server-side Java code. No JavaScript flows from client to server, and there is no server-side interpretation of any application data (e.g., message bodies). In fact, there is no JavaScript execution on the server period. This ensures that there is no way for even a hostile Ajax client with an authentication credentials to inject malicious code for execution on the server-side.
+• Limited or no client-side interpretation of JavaScript within user data – The Zimbra Ajax client is, of course, an Email application that runs within the confines of the web browser. There is an additional risk, then, to displaying the contents of rich HTML messages that themselves contain JavaScript, in that JavaScript within the message might somehow be able to make malicious calls to the Zimbra server (it is generally precluded from making invocations to other sites). Zimbra blocks any “risky” HTML, first on the server and then again (for extra protection) on the client. When a rich HTML message contains any suspect JavaScript, simply better to err on the side of caution. For most Ajax applications, simply maintaining a strict separation of code from data (and never interpretting JavaScript that is included within user data) protects against such attacks.
+• Benign URLs – All Zimbra’s GET-based REST and URL-based APIs are read-only and do not modify data. This ensures that a user (with pre-validated security credentials) cannot be fooled into clicking on a malicious link (that someone sends he or she in an email or posts on his/her external website) that would have harmful side-effects on that user's data. Again, this is broadly relevant for Ajax applications that potentially display clickable URLs in application data.
+• Mash-ups/Zimlet validation – Zimbra's mash-up architecture does provide the opportunity to introduce server-side Java code (most Zimlets run only on the client side), but the introduction of Zimlets requires server administration privileges. Zimbra recommends only deploying Zimlets that have been certified by Zimbra or else which have been vetted by your security architects internally. The key is to ensure that only trustworthy mash-ups can be deployed with your Ajax application, mash-ups that do not expose additional attack points for malicious users.
The end result is that while an attacker with appropriate security credentials (such as a user's password) could certainly damage that user's server-side data, there is no way for them to compromise other user's data or the server in general. (And, of course, that user could have any damged mailbox state restored to the point before the attack by a Zimbra administrator.)
+ +Stronger network security can be afforded by additional technologies (such as VPNs, Smartcards, etc.), but that's our recipe in general for leveraging the benefits of Ajax without giving up the security your customers, partners, and business depend on. More detail on the Zimbra-specific approach can be found in the newly updated Zimbra Architecture Overivew (linked within our Community and Product Documentation).
+ +As always, thanks for listening (particularly to my verbose posts).
]]> +The alternative application model to the Web (I include WML/HTTP under the Web architecture) is of course more traditional fat client applications---such as those programmed for J2ME, Windows Mobile, Symbian, Palm, or mobile Linux. Fat client app's are ideal for PIM (email, SMS, calendaring, contacts, tasks), games, and other code that handset manufactures or the carriers are willing to preinstall, but a tougher sell for non-expert business and consumer end-user installation.
+ +However, there is yet another approach that we proposed. It is particularly relevant for applications that can be surfaced via PIM software, such as your customer contacts from your CRM system, your travel itinerary from your procurement application, an urgent notification (via SMS), or even an email request to visit a particular URL. Such items can be submitted to a server like the Zimbra Collaboration Suite (ZCS), and then delivered to the mobile device via "over the air" sync. Zimbra Mobile, for example, can sync contacts, appointments, and messages to Nokia, Motorola, Samsung, Treo, and Blackberry smart phones, and both intranet and Internet applications can securely export to Zimbra over open/standard protocols. Putting the two together allows Web-enabled applications to deliver PIM-oriented data all the way to the mobile device.
+ +So for applications that can be naturally surfaced via the native mobile PIM, there are now easier/cheaper options for mobile extension. For those business applications that have no such easy fit with PIM, I'm afraid you must still weigh the classic Web versus fat client architectural trade-off. In either case, I think that choosing the smart phone/PDA as the target profile makes more sense because of their relative consistency (screen size, scroll-to-click, J2ME vs. Windows Mobile platform), at least when compared with targeting the continuing stream of ever more compact, ever more personalized mobile phones.
]]> +The grief came in particular from my drawing parallels between Zimbra---a for-profit company---with more altruistic non-profit organizations like Apache and FSF regarding IP ownership. No doubt there are clear differences between for-profits and non-profits that the prospective community members have every right to consider, but I think in terms of IP ownership there is more in common than different.
+ +For a potential community member, the most important thing is the long-term guarantee of their freedoms: (1) Open source rights (granted under the open source software license) to use the product in perpetuity for free, to produce and redistribute any derivative works thereof for free, and so on; and (2) rights to do whatever they may see fit in perpetuity for any of their own contributions that they made in good faith to the project. (The good contribution agreements grant contributors back all of their rights except those that could interfere with the community, such as the right to withdraw their contribution in the future, the right to charge the community patent royalties down the road, etc. For example, Zimbra's Contributor Agreement can be found here. For another take, check out Dojo, one of our Open Ajax Alliance partners. ) This practice seems to me to strike the right balance between preserving individual freedoms without sacrificing the freedoms of the community as a whole.
+ +Both non-profit and for-profit open source organizations equally guarantee these freedoms to their communities, the difference being that the for-profit ones (like Zimbra) also strive to sell optional value-added services on the side, much of the proceeds of which then funds the further development of the open source software.
]]> +