This is the final part of our three part series on porting Dojo methods to Flash.

In part one of our series, we implemented Dojo’s hitch method, and then used hitch in part two, where we made our connect method. In part three, we will be using both of these methods as we connect a JavaScript object to a Flash object.

(more…)

Adobe recently announced their new Open Screen project, which opens the licensing of the Flash Player and much more.

We’re celebrating this event with a three part series on Dojo and ActionScript and previewing some of the work by the Dojo team.

(more…)

There’s been some breaking news from Adobe, announcing their Open Screen project. As of today, they are opening the licensing of the Flash Player, FLV/F4V video, publishing the AMF protocol and device APIs for the player, and more.

This is great news for businesses, developers, and the Open Web in general. No longer does open source ActionScript code need to do workarounds and leave things out in an effort to make it “as open as reasonably possible”.

In celebration of this announcement, we’re beginning our three part series on ActionScript code, and preview some of the Dojo team’s efforts in this area.

(more…)

The Dojo Toolkit 1.1 (currently at RC2 stage) has introduced an improved RPC system that provides support for multiple forms of RPC like JSON-RPC and raw POST requests. The new RPC system also supports REST. Understanding the relationship between RPC and REST can help you to fully utilize this new system.

Often Representational State Transfer (REST) style architecture is pitted against Remote Procedure Call (RPC) style architecture. These contrasts may be beneficial for understanding the conceptual motivations and benefits of these two architectures. However, by understanding their relationship, RPC and REST style interaction can both be leveraged harmoniously. By utilizing the right combination of RPC and REST in the appropriate situations you can maximize application manageability, scalability, and efficiency. The relationship can be defined quite easily.

(more…)

We have been leading the efforts in the development of Service Mapping Description (SMD). SMD is a flexible format and can be used to describe JSON-RPC, REST, JSONP, and other web services. SMD will provide a foundation to facilitate a future of pluggable interoperable SAO-based web services, where client and server components can be decoupled. Existing client/server frameworks tend to have tightly coupled communication, and applications built with standalone JavaScript libraries like the Dojo Toolkit generally must build their own client and server communication with the only assistance in the form of Ajax wrappers. With SMD, web services can be described with an open format, and client libraries can utilize these SMD descriptions to build high-level friendly communication wrappers. Of course, the Dojo Toolkit has taken the lead with the new SMD implementations in the Dojo Toolkit 1.1, but with SMD-based web service interaction, there is no lock-in. This provides an open definition of web services: any client and server can participate in providing or consuming these web services.

(more…)

Palo Alto, CA - February 25, 2008 - SitePen Inc. today announced updates to the Dojo Toolkit that allow Ajax developers to easily deploy web applications created with the Dojo Toolkit on Adobe® AIR™. Adobe collaborated with SitePen to revise the Dojo Toolkit and enable compatibility with Adobe® AIR™.

“The Dojo Toolkit is a popular and important toolkit for web application developers, and now Dojo Toolkit developers can seamlessly deploy their applications on Adobe AIR,” said Rob Christensen, senior product manager, Adobe AIR at Adobe. “We engaged with SitePen and their expert team of Dojo Toolkit Contributors to make this possible for developers.”

(more…)

The first Dojo Toolkit 1.0 Release Candidate is complete. To celebrate, let’s take a look at one of the new features in Dijit’s dijit.Declaration.

We are already familiar with Dijit’s capabilities to render widgets in markup. This is a powerful way of providing widgets in your page with about the same effort as styling with CSS. Recently, Alex Russell blogged about new Dojo alternate script types as a way of attaching code via markup through a creative use of the script tag’s type attribute. One of the newest features in the Dojo Toolkit, dijit.Declaration, extends that approach by giving us a way to define widgets in markup.

(more…)

Dojo 0.9 is a different beast than any Dojo before it. It’s smaller, it’s (much) faster, and it “feels” different in many ways. As Jon Sykes noted, “everything is familiar yet strangely different”. I could go on for hours about why dojo.query() is completely indispensable or how having dojo.behavior as a part of Core changes everything, but there’s some fun stuff up the stack too. In particular, new parser bears mention, and a bit of explanation. In addition to now letting you build instances of any class (not just widgets), it also lets you configure their behavior as well as their properties.

For a long time systems like Flex and Laszlo have had a corner on naturally mixing behavior with markup. HTML’s native <script> tag doesn’t provide any context, and worse, can’t provide a way to be triggered by a particular event or action (outside of proprietary extensions). Several use-cases are important:

• Scoped execution
• Event-driven execution
• Attachment vs. replacement

In Dojo 0.9 we took a hard look at them and devised <script type="dojo/method"> and <script type="dojo/connect">. Lets take a quick tour and show how it makes writing event handlers natural, building new widgets a snap, and over-riding built-in behavior trivial.

(more…)

SitePen and Dojo are proud to announce a new beta release of Dojo Offline. This release has a huge amount of exciting new functionality, including a full port to Google Gears, a port from Dojo 0.4 to 0.9, and more.

(more…)

Well, the plan was to go through every type of input object, button, and image in Safari on my shiny new iPhone and make notes about what functions were available, how event handling works, and any other fun little goodies that came along. I started out with the good old text input box, and after an hour or two of executing functions in all sorts of different orders and being seriously freaked out a couple of times, I’m worried about the pretty severe limitations of one of the most basic widgets of the web browser:

• When the input does not have “virtual keyboard” focus, calling its focus function calls its onfocus function, but does not give the input “virtual keyboard” focus
• When the input does not have “virtual keyboard” focus, but you’ve called its focus function, calling its blur function will call its onblur function. When the input does have “virtual keyboard” focus, calling its blur function does absolutely nothing (which breaks some scripts that prevent input by blurring on focus).
• When the input does not have “virtual keyboard” focus, calling its select function does nothing, until you scroll or zoom in on the page, at which point it calls both its onfocus and onblur functions. When the input does have “virtual keyboard” focus, calling its select function does absolutely nothing.
• Calling its click function calls its onclick function as expected.
• Selecting an input box fires: onfocus, onmouseover, onmousedown, onmouseup, onclick, and sometimes onmousemove
• Selecting the next item on the page fires: onblur, and (conditionally) onchange, but still no key events.
• Clicking the “Done” button in the “virtual keyboard” fires: onblur, and (conditionally) onchange, but still no key events.
• The only key that registers any key events is the return key.