News aggregator

JSBridge is an incredibly alpha, but interesting new project, lead by Mikeal Rogers, that bridges Python and JavaScript with respect to Mozilla. It uses mozrunner, the Python library that can power Mozilla applications (e.g. Firefox).

Once you fire up jsbridge MozRepl will kick into gear, and you will be able to interact across the bridge. “This includes JavaScript < -> Python object translations and a callback mechanism for Python responses to custom events fired in the javascript environment.”

Of course, this isn’t related to IronMonkey the project that allows you to write Python (and Ruby and …) on top of Tamarin.

Alx Dark has created The Tombs of Asciiroth a fully functional roguelike-meets-puzzle-arcade game.

Asciiroth is a a complete, functional, open source game, written using GWT, and distributed either as an Adobe AIR application, or as a game you can play over the web. In the latter case, it uses Gears to provide saved game support. (So bottom line is you can play it using AIR or Firefox… IE is too slow, Opera/Safari aren’t supported by Gears.) It also has a map editor that is distributed as an Adobe AIR application.

It is very cool to see applications written using Ajax, and then using both Gears for in-browser functionality, and AIR for desktop deployment.

I am really jazzed about the first entry in a new series on HTML 5. Mark Pilgrim (of Python, Greasemonkey, Open Web, writer extraordinaire, and creator of Google Doctype) has started the series This Week in HTML 5 which aims to keep us up to speed on the spec, and progress across the board (what are browsers implementing etc).

In the first episode he discusses the progress with workers, interesting clarification around providing text instead of images, and more.

Anyway, over to Mark:

The biggest news is the birth of the Web Workers draft specification. Quoting the spec, “This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism.” This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.

Also notable this week: even more additions to the Requirements for providing text to act as an alternative for images. 4 new cases were added:

1. A link containing nothing but an image
2. A group of images that form a single larger image
3. An image not intended for the user (such as a “web bug” tracking image)
4. Text that has been rendered to a graphic for typographical effect

Additionally, the spec now tries to define what authors should do if they know they have an image but don’t know what it is. Quoting again from the spec:

If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just “{}“), then even the kind of image being shown is not known.

• If the image is available, the element represents the image specified by the src attribute.
• If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).

Great to see this series kick into gear, and having Mark keep us in the loop on the very important HTML 5 effort.

Tìm cụm tử “Cuil vs Google” qua cuil Tìm cụm từ “Cuil vs Google” qua google

I was wary about posting on this one, as it does involve scantily clad women. If that offends you, skip now, and please accept my apologies, and I know that this probably fits better for a Friday Fun posting, but let’s get to it:

Ok, so when I was on the Adobe AIR tour, some folks showed me an AIR app that The Sun, a gossip rag / newspaper in the UK was working on. Sure you can get the news from the website, and through RSS feeds, but how about a branded experience? (as Ryan Stewart would say!)

This newspaper puts aside the third page to introduce you to a “lovely lass” each day. This is part of their brand, and probably is a reason why it is the most read newspaper in the world (a little sad but true?).

Thus, they decided to try writing an article alert application with a twist… that being one of the lasses would walk onto your screen when there is news and show it to you. I had to admit, that I didn’t think that Ajax would be able to do that.

The question is, do these brand experiences take off? Is this a gimmick? Do people really just liking their RSS feeds with as little disruption as possible…. or do they cling to certain brands and enjoy that extra touch. I somehow doubt that anyone would want a “Desktop Ajaxian” where Ben and I come out to give you the news ;)

One little annoyance that I saw after running it, is the dock icon coming and going as they poll the AIR app. I hope that is fixed in the next version of AIR (Mike Chambers just put out a call for requests).

Bert Bos, a W3C fellow, thinks that CSS variables are to be considered harmful:

Adding any form of macros or additional scopes and indirections, including symbolic constants, is not just redundant, but changes CSS in ways that make it unsuitable for its intended audience. Given that there is currently no alternative to CSS, these things must not be added.

He has some very compelling points in there, some of which I agree with, and others that I don’t:

This PHP version proves that it is not necessary to add constants to CSS. Just like the existence of the WebKit implementation cannot be taken as proof that constants in CSS are useful, so the PHP implementation cannot prove that either. But the PHP implementation has the benefit of letting authors determine the usefulness for themselves, without modifying CSS on the Web.

You can obviously use pre-processors to do many macro situations. This doesn’t mean that it is the right place for functionality like this. I don’t want to force every CSS request through PHP. I also like having functionality in CSS itself, as that can be shared across projects and developers without “oh, and by the way this looks a little different as we pre-process it with a magic Rails action”. Something as important as variables should be low level IMO.

It is quite likely that somebody who is trying to learn CSS will give up learning it when he sees that style sheets that occur on the Web don’t actually look like the tutorials he started from. Difference in upper- and lowercase or in pretty-printing are hindrances to learning, too, but limited ones: you soon learn to ignore those differences. But symbolic constants are different in each style sheet and have to be interpreted and understood each time anew.

A touch too strong. Things change. Tutorials get out of date. C’est la vie. And, you can always use old form…. and the feature is so simple that it won’t take you weeks to work it out!

People who understand CSS in principle may still have trouble understanding the indirection provided by the em unit, many have trouble with the advanced selectors in level 3, and many more won’t understand, e.g., any of the properties that have to do with bi-directionality or vertical text. For each feature that is added to CSS there must be a careful balance (based on an informed guess, because these things are difficult to test) between the number of users that will be excluded by that feature and the number for whom it is essential that it be added.

I agree in the balance. There are some crazy complicated parts of CSS. However, simple variables is trivial in comparison! Also, I think it will be used a hell of a lot more frequently.

Treating symbolic constants as an independent module would make them available for use in other contexts than CSS, would make them available to precisely the people who need them without hindering other people, would allow them to be developed without impact on CSS, and allow them to be developed more easily into what they are sure to develop into anyway: full macros, able to replace anything, not just CSS values, and able to make files shorter instead of longer.

I agree about modularity. There will be issues with scope and such, and we will have to fight to keep the system as simple as possible.

However, I can’t wait to be able to re-skin something by changing the variables only that represent semantic parts of my application. Search and replace isn’t good enough. Having tools that see the #xxxxxx and show you a color aren’t good enough. You end up reading a lot more CSS than you write, so we should help that use case. I don’t think CSS should become a programming language with if statements and the like, and I doubt this is a gateway drug to that.

I created an introductory example discussing custom events as an implementation of the Observer pattern. I posted this on my personal blog first and quickly got a port from my Prototype version to Malte’s jQuery port (and now we have a DOMAssistant and Appcelerator versions). I hope others keep them coming so we can aggregate a simple example of custom events and how it works across various toolkits:

The example dynamically adds functionality based on checkboxes to simulate events that could change processing and uses the fire() and observe() methods from Prototype.

I strap on behaviour to a list of names. When you click on the name, something can happen. To do this I could have done the following:

$$('ul#leftchoices li').each(function(el) { el.observe('click', function(e) { if ($('colorchange').checked) { changeColor(); } if ($('contentchange').checked) { changeContent(el.id); } }); });

In the click event itself, I do various checks and kick off behaviour. That can be fine for small actions, but what if you want to do more? This is when I prefer to abstract out the action and just fire an event:

$$('ul#leftchoices li').each(function(el) { el.observe('click', function(e) { el.fire('selected:choice'); }); });

At this point, this bit of code becomes dumb. It doesn’t know what to do when you select the item, and it just hopes that somewhere, someone is listening. That is where the observers come in, such as this one that changes the main content based on the selected name:

$('contentchange').onchange = function(e) { if (e.target.checked) { document.observe('selected:choice', changeContent); } else { document.stopObserving('selected:choice', changeContent); } }

When someone clicks on the checkbox, this method is fired and an observer is either added, or taken away.

Once you start building applications with this in mind, you may find a bit of a sea change. You start to think about the various events as a public API that you can easily expose to observers. Gone is the simple ability to look at one method and see what is happening, but the loose coupling gives you the ability to easily layer in your architecture. Based on some settings, behaviour can be dynamically added. You could even expose these events in a way that makes it easier for Greasemonkey hackers to come in and work with your application. All in all, a win-win for anything more than a simple example.

Although this example uses Prototype, you could do the same with the other top class JavaScript libraries. In fact, if someone wants to port this example to Dojo, jQuery, Mootools, YUI, or anything else, send me the files and I will put them up so we can all compare how custom events are done in the various toolkits.

Matthew Congrove took some time to play with the iPhone SDK, but it wasn't his bag, so he decided to go back to building a Web application for the iPhone, and was pleasantly surprised with the updates to Safari that enabled new things:

In the midst of all my research for help I stumbled across something that I, like most, had completely forgotten about; the iPhone update wasn't just for native third-party applications, but it also upgraded the existing applications. Yes, that includes Safari. The upgrade for the iPhone's on-board browser added in support for CSS animations and transitions, a JavaScript accessible database, a few new DOM selectors and more. For me this meant that the myDailyPhoto web application could look and feel more like it was a native Cocoa Touch enabled experience. As soon as the idea crossed my mind I sat down to churn out this little test app.

To get the flick effect Matthew wrote the following CSS:

PLAIN TEXT CSS:

1.  
2. .divSlide {
3.         -webkit-animation-name: "slide-me-to-the-right";
4.         -webkit-animation-duration: 1s;
5. }
6. @-webkit-keyframes "slide-me-to-the-right" {
7.         from { left: 0px; }
8.         to { left: 100px; }
9. }
10.  

In the code-on-demand style, a client component has access to a set of resources, but not the know-how on how to process them. It sends a request to a remote server for the code representing that know-how, receives that code, and executes it locally.

The above quote comes from the infamous thesis by Roy Fielding which kicked off REST.

Joe Gregorio reminded us of this quote to remember that JavaScript fits in nicely with REST and the cloud:

The word 'code' here means JavaScript. Well, at the time it was written all the examples given were Java applets, but the idea is the same, that code is downloaded and executed. The takeaway here is that JavaScript is a fully fledged RESTful part of the web, and those JavaScript APIs, just like the hyptertext I pointed out yesterday, are RESTful points of integration of Cloud Computing.

It's almost as if the web were designed for this stuff.

Michael Mahemof is working a lot with TiddlyWiki and posted on how the project injects HTML into an iframe, and then get them out later. This enables you to use the browser parser to do its thing:

PLAIN TEXT JAVASCRIPT:

1.  
2. // put it in
3. var doc = iframe.document;
4. if (iframe.contentDocument)
5.   doc = iframe.contentDocument; // For NS6
6. else if(iframe.contentWindow)
7.   doc = iframe.contentWindow.document; // For IE5.5 and IE6
8.  
9. // Put the content in the iframe
10. doc.open();
11. doc.writeln(content);
12. doc.close();
13.  
14. // and then get it out
15. var storeArea = doc.getElementById("storeArea");
16.  

Ext 2.2 has been released, and it has features to complement the usual maintenance bug fixes and performance updates (Ext now works better in Firefox 3).

New features include:

CheckboxGroup / RadioGroup

Technically, while the individual Checkbox and Radio controls are not new, they may as well be, considering the overhaul they have had in this release. Gone are the ugly standard browser input controls, now replaced by attractive, visually-consistent Ext-ified versions (a long-overdue improvement).

In addition to that, we’ve added group controls for both that support complex layouts with just a config option or two. Previously in order to accomplish similar grouping layouts you would have had to create a container with a ColumnLayout and manually place your controls across multiple column configs.

History

Another component that has been missing in Ext is a browser history utility to enable history stack navigation within your single-page Ext application. The new Ext.History singleton makes it extremely easy to do exactly that, and it uses an event-based API to notify you when the browser history as changed.

MultiSelect / ItemSelector

These two components were contributed to Ext by community member TJ Stuart (thanks TJ). The MultiSelect is a traditional list control that allows for selecting multiple list items, and the ItemSelector combines two MultiSelects into a more sophisticated control that includes drag-and-drop list selection and bulk selection and deselection among other features.

FileUploadField

This is an official extension provided as a sample for implementing a useful form component. Not everyone needs a form upload component, but if you do, you can’t live without it. This control is fully styled and has an API consistent with other Ext form controls. It also supports both Text+Button (read-only text) and Button-only modes, and can participate fully in form layouts.

XmlTreeLoader

This official extension provides a great demonstration of extending an existing Ext component to provide functionality that you need in your own application. Again, loading an XML document into a tree is not needed by everyone, but if you do need something similar, this should be a great demo.

GMapPanel

This extension was originally written up as a demo for one of our previous blog posts. However, it proved to be such a hit with the community that we transformed it into an official extension. This is another useful example of extending a standard Ext component, in this case to interface with an external API.

The video above is a "concept" called Aurora, created by Jesse James Garrett of Adaptive Path. Give it a play and you will see his vision for a very visual immersive, space-age-like environment that is very social.

There are a couple of others too, such as Wei Zhou's bookmarking concept and Aza Raskin's mobile phone concept that we have discussed in the past.

This isn't about these concepts though. The Mozila Labs folks have a call for participation:

Today we’re calling on industry, higher education and people from around the world to get involved and share their ideas and expertise as we collectively explore and design future directions for the Web.

You don’t have to be a software engineer to get involved, and you don’t have to program. Everyone is welcome to participate. We’re particularly interested in engaging with designers who have not typically been involved with open source projects. And we’re biasing towards broad participation, not finished implementations.

We’re hoping to lower the barrier to participation by providing a forum for surfacing, sharing, and collaborating on new ideas and concepts. Our goal is to bring even more people to the table and provoke thought, facilitate discussion, and inspire future design directions for Firefox, the Mozilla project, and the Web as a whole.

Time to get creative and put on your inventor hat. Maybe your idea can get into Firefox?

Facelift Image Replacement (or FLIR, pronounced fleer) is an image replacement script that dynamically generates image representations of text on your web page in fonts that otherwise might not be visible to your visitors. The generated image will be automatically inserted into your web page via Javascript and visible to all modern browsers. Any element with text can be replaced: from headers (<h1>, <h2>, etc.) to <span> elements and everything in between!

sIFR takes over the elements and puts small swf files into place. FLIR on the other hand generates images on the server and puts them in place. They both suffer from the progressive switch in place that you often see as you watch the page load.

Also, one downside is that once the text is an image you can't copy and paste it. Ben can once again drool over the typography.

Bruce Johnson of the GWT team has continued the deep dive into GWT with a posting on a new GWT 1.5 feature: JavaScript overlay types. This feature goes beyond the JNSI technique to "make it easy to integrate entire families of JavaScript objects into your GWT project. There are many benefits of this technique, including the ability to use your Java IDE's code completion and refactoring capabilities even as you're working with untyped JavaScript objects."

The first example that Bruce gives is to mix JSON objects with Java:

PLAIN TEXT JAVASCRIPT:

1.  
2. var jsonData = [
3.   { "FirstName" : "Jimmy", "LastName" : "Webber" },
4.   { "FirstName" : "Alan",  "LastName" : "Dayal" },
5.   { "FirstName" : "Keanu", "LastName" : "Spoon" },
6.   { "FirstName" : "Emily", "LastName" : "Rudnick" }
7. ];
8.  

PLAIN TEXT JAVA:

1.  
2. // An overlay type
3. class Customer extends JavaScriptObject {
4.  
5.   // Overlay types always have protected, zero-arg ctors
6.   protected Customer() { }
7.    
8.   // Typically, methods on overlay types are JSNI
9.   public final native String getFirstName() /*-{ return this.FirstName; }-*/;
10.   public final native String getLastName()  /*-{ return this.LastName;  }-*/;
11.    
12.   // Note, though, that methods aren't required to be JSNI
13.   public final String getFullName() {
14.     return getFirstName() + " " + getLastName();
15.   }
16. }
17.  

PLAIN TEXT JAVA:

1.  
2. // the glue
3.  
4. class MyModuleEntryPoint implements EntryPoint {
5.   public void onModuleLoad() {
6.     Customer c = getFirstCustomer();
7.     // Yay! Now I have a JS object that appears to be a Customer
8.     Window.alert("Hello, " + c.getFirstName());
9.   }
10.  
11.   // Use JSNI to grab the JSON object we care about
12.   // The JSON object gets its Java type implicitly based on the method's return type
13.   private native Customer getFirstCustomer() {
14.     // Get a reference to the first customer in the JSON array from earlier
15.     return $wnd.jsonData[0];
16.   }
17. }
18.  

Bruce then shows us some performance wins that you get, as GWT gets to do a lot of inlining:

A quick digression for compiler geeks. Another neat thing about overlay types is that you can augment the Java type without disturbing the underlying JavaScript object. In the example above, notice that we added the getFullName() method. It's purely Java code — it doesn't exist on the underlying JavaScript object — and yet the method is written in terms of the underlying JavaScript object. In other words, the Java view of the JavaScript object can be richer in functionality than the JavaScript view of the same object but without having to modify the underlying JS object, neither the instance nor its prototype.

(This is still part of the digression.) This cool wackiness of adding new methods to overlay types is possible because the rules for overlay types by design disallow polymorphic calls; all methods must be final and/or private. Consequently, every method on an overlay type is statically resolvable by the compiler, so there is never a need for dynamic dispatch at runtime. That's why we don't have to muck about with an object's function pointers; the compiler can generate a direct call to the method as if it were a global function, external to the object itself. It's easy to see that a direct function call is faster than an indirect one. Better still, since calls to methods on overlay types can be statically resolved, they are all candidates for automatic inlining, which is a Very Good Thing when you're fighting for performance in a scripting language.

From this Java code:

PLAIN TEXT JAVA:

1.  
2. class MyModuleEntryPoint implements EntryPoint {
3.   public void onModuleLoad() {
4.     JsArray<customer> cs = getCustomers();
5.     for (int i = 0, n = cs.length(); i <n; ++i) {
6.       Window.alert("Hello, " + cs.get(i).getFullName());
7.     }
8.   }
9.  
10.   // Return the whole JSON array, as is
11.   private final native JsArray<Customer> getCustomers() /*-{
12.     return $wnd.jsonData;
13.   }-*/;
14. }
15.  

The compiler inlines away to get to the followinig (not obfuscated to see):

PLAIN TEXT JAVASCRIPT:

1.  
2. function $onModuleLoad(){
3.   var cs, i, n;
4.   cs = $wnd.jsonData;
5.   for (i = 0, n = cs.length; i <n; ++i) {
6.     $wnd.alert('Hello, ' + (cs[i].FirstName + ' ' + cs[i].LastName));
7.   }
8. }
9.  

Although my iPhone screen has enough grease on it, we are now seeing some that is useful. GreasePocket is a Greasemonkey/Kit-like plugin that allows you to write userscripts for your iPhone.

Not only can you access the DOM and such, but you can access device APIs themselves. Thus, you could write a GreasePocket script that talks to your contacts list, or your camera. There are obvious security concerns here, and the team hasn't fixed the issues that Greasemonkey itself had to deal with.

To help with this issue, Ishan Anand and Ajay Kapur are looking to opensource the project to get some help.

You can read more in their presentation.

It always makes me laugh a little when people try to "protect" things on the Internet. The dwProtector tries to "protect" your images with you just having to:

PLAIN TEXT JAVASCRIPT:

1.  
2. window.addEvent('domready', function() {
3.         var protector = new dwProtector({
4.                 image: '/blank.gif',
5.                 elements: $$('.protect')
6.         });
7. });
8.  

How does it protect?

• Prevents right-click "Save Image As".
• Prevents dragging an image to the desktop.
• Prevents right-click "Save Background As".
• Prevents right-click "View Background Image"

Check out the example and try to copy it. Of course, a simple print screen / apple-shift-4 does the trick, let alone a view-source.

Are you an ExtJS and Django user? If so, you will want to check out this article by Matt of Tangible Worldwide on Using ExtJS's Grid Filtering with Django.

He goes into detail on how to tweak the grid filtering system that is aimed at PHP, and getting it to work in a way that allows you to write this Django code:

PLAIN TEXT PYTHON:

1.  
2. # take a ContentType model name (say, from the URL)
3. # and create a QuerySet
4. ctype = ContentType.objects.get(model=ctype_model)
5. model_class = ctype.model_class()
6. obj_qs = model_class.objects.filter()
7.  
8. # 'q' is the set of POSTed filtering parameters
9. filter_params = request.POST.get('q', '[]')
10.  
11. # decode the filtering parameters w/ simplejson
12. filter_params = simplejson.loads(filter_params)
13.  
14. # apply the filtering params
15. filtered_qs = get_queryset_from_ext_filters(obj_qs, filter_params)
16.  

ExtJS 2.1 saw inclusion of the popular (at least in my world) user extension for AJAX filtering of data by grid columns. As useful as this is (provided you can abide by the GPL or paid licensing options), the filter parameters serialized as a PHP array, which is not particularly useful for other languages. With a quick modification to the grid filtering serialization method and a helper function for Django, we can rewire the system to send a JSON string that Django can use to directly apply filtering to a QuerySet. I've found that most clients love having this sort of command and flexibility over their data -- especially the kind that don't necessarily realize that this visualization and control exists. I like that. Additionally, the amount of work and code required is minimal, and the code both reusable and straight-forward. I like that, too.

There are 4 steps to this process:

1. Modify the serialization method in GridFilters.js
2. Set up the helper function that will process the QuerySet with the grid filter parameters
3. Slightly customize your models (see below)
4. Add (simple) helper code to your Ajax view

Flash can get to “ubiquitous” across the entire web with new capabilities in roughly 18 months and the Open Web faces a best case replacement time-frame of 5 years.

Reducing that differential from 42 months to zero is now the defining challenge of the Open Web. HTML is back in the hunt. Time to see how fast we can teach it remember the new tricks we’re so eager to teach.

This is a key comment in Alex's perspective where he discusses his analysis on the browser market, and how it is changing... or isn't changing.

It can be a little depressing, but if you are optimistic like Alex, we can work to make life better. How can we help?

The NoGray Time Picker is a component that lets you add a time picker that is visual. The clock shows up, and you move the hands to wherever you need to be. All via a simple:

PLAIN TEXT JAVASCRIPT:

1.  
2. var tp = new TimePicker('time2_picker', 'time2', 'time2_toggler', {format24:true});
3.  

Or a more complex version that tracks the changes:

PLAIN TEXT JAVASCRIPT:

1.  
2. var tp = new TimePicker('time_picker', null, null, {onChange:function(){
3.                                           if (this.time.hour <12) var ampm = this.options.lang.am;
4.                                           else var ampm = this.options.lang.pm;
5.  
6.                                           var hour = this.time.hour%12;
7.                                           if (hour <10) hour = "0"+hour;
8.                                           var minute = this.time.minute;
9.                                           if (minute <10) minute = "0"+minute;
10.                                           $('time3_value').setHTML(hour+":"+minute+" "+ampm);
11. } });
12.  

After all that though, is it easier than asking to put in the time?

Tom Trenka of SitePen has created a new top-level Dojo package called Deft which "focuses on ActionScript components created in support of the various projects within the Dojo Toolkit (mostly for DojoX). Deft source files are well organized based in part on the organization of other Dojo Toolkit projects, as well as the package structure required by the Flex compiler. Most Flex applications are based on the Flex AS3 Application class, which forces you to write at least one “controlling” MXML file in order compile your code. Instead of this, Deft components inherit primarily from the Sprite class — which allows you to write pure ActionScript code."

It contains a few goodies in it including the multi-image uploader, and pre-alpha quality support for dojox.gfx. Future plans include support for audio and video. "Hopefully Adobe will continue its current path towards being open source friendly, helping Deft flourish."

The article goes into detail on downloading the Flex SDK so you can build applications with it.

This is an interesting experiment in the melding of Flash and Ajax techniques. I would love to see the Flash player giving us more access via simple JavaScript, so we don't even need to create SWF bridges.