Posts Tagged Dojo

WebWorks Resource Name Not Valid Workaround

I’ve been looking at using Phonegap and Dojo for rapid application development on mobile devices. As I have been doing blackberry development for the past year or so I thought that this would be a good platform to start on. However, I almost immediately ran into a problem with the WebWorks packager.

The problem is that the packager will not permit paths with special characters in them – special characters including the somewhat limiting “_” and “-“. Instead of packaging the files it would return the error Invalid widget archive – resource name is not valid This is especially a problem with dojo and it commonly uses these conventions for stylesheets and js files.

After Googling, I found that this behaviour was by design. It seems that if you pass a file with a dash in it, the RAPC compiler thinks that it is a command line switch.
See:
https://www.blackberry.com/jira/browse/WEBAPI-50
http://supportforums.blackberry.com/t5/Web-Development/bbwp-quot-resource-name-not-valid-quot/m-p/607222
http://mobijournal.com/common-blackberry-webworks-development-pitfalls-that-can-be-avoided/

Fortunately, RIM has recently open sourced the Webworks API. I knew from my experience with bb-ant-tools that you were able to pass a file containing paths to the files to include in the package, thus circumventing the problem with the command line switches.

The packager now successfully packages _bad-path.txt.

To patch your webworks packager, download WebWorksPatched extract it and move the bbwp.jar to your webworks bin folder (Usually C:\Program Files\BlackBerry WebWorks Plug-in Eclipse\plugins\net.rim.browser.tools.wcpc_1.5.1.201010291444-22\wcpc\bin).

For the brave of heart, source code is available on GitHub at https://github.com/51systems/WebWorks

, , ,

2 Comments

Greasemonkey And Dojo Integration Redux

Back in 2007 I wrote a post on how to integrate Dojo with Greasemonkey.
Since then, Greasemonkey has been re-written to include security and bug fixes which has broken my demo code. The problem is that the new security model doesn’t return an instance to the newly created dijit.Dialog when the constructor is called. The work-around is to set the ID of the dialog, and then call dijit.byId() to get a handle to it.

Of course, this is going to pose problems when creating non-dijit objects, as they will all be created on the page-level scope. The work-around is likely constructing clever eval() strings, and then accessing the objects using unsafeWindow. If anyone comes up with a more elegant solution, let me know about it in the comments.

The following can be used to overwrite the previous version of the user-script, restoring the broken functionality as well as making use of some of the newly introduced Dojo features.

// ==UserScript==
// @name           Dojo Integration Test
// @namespace      test
// @description    Proof Of Concept To Integrate Dojo And Greasemonkey
// @include        *
// ==/UserScript==
 
function startup(){
	dojo = unsafeWindow["dojo"];
	dijit = unsafeWindow["dijit"];
 
	dojo.addClass(dojo.body(), 'tundra');
	dojo.require("dijit.Dialog");
 
	//Don't do anything until "Dijit.Dialog" has been loaded
	dojo.addOnLoad(function(){
		//Actually Create The Dialog
		new dijit.Dialog({
			id: 'test',
			title: "Dojo Integration Test",
			content: 'Dojo lives... In Greasemonkey'
		});
 
		dijit.byId('test').show();
	});
};
 
//include flags to djConfig to tell dojo its being used after its been loaded
unsafeWindow.djConfig = {
	afterOnLoad: true,
	addOnLoad: startup
};
 
//Include Dojo from the AOL CDN
var script = document.createElement('script');
script.src="http://o.aolcdn.com/dojo/1.4/dojo/dojo.xd.js.uncompressed.js";
document.getElementsByTagName('head')[0].appendChild(script);
 
//Include the Tundra Theme CSS file
var link = document.createElement('link');
link.rel = "stylesheet";
link.type= "text/css";
link.href="http://o.aolcdn.com/dojo/1.4/dijit/themes/tundra/tundra.css";
document.getElementsByTagName('head')[0].appendChild(link);

, ,

2 Comments

Inject Dojo Bookmark

Sometimes it can be handy to inject Dojo into pages that would not otherwise have it. I’ve used this so I can use dojo.query() on a page to select DOM objects while testing a parser in a different language.

Use drag this link into your bookmarks and have Dojo at your fingertips no matter where your browser takes you:
Inject Dojo v.1.3.2

, ,

No Comments

Zend JSON-RPC with Dojo Howto

I have been using the Dojo toolkit as my Javascript library of choice since back in early 2006 when it was still around version 0.4. Since then, the project has made tremendous strides including the release of version 1.0 and 1.1 with 1.2 on the way. At the beginning of 2008 I started using the Zend Framework to build MVC PHP applications and, with the release of 1.5, it has become my PHP framework of choice.

To my delight, the Zend Framework and Dojo have recently announced a partnership which will lead to tighter integration of these two great open source frameworks.

One of the most exciting additions to the Zend Framework is the Zend_Json_Server support for JSON-RPC. I have been using JSON-RPC with Dojo for quite some time and, up until now, it has been challenging to find a design pattern that plays nice with the Model View Controller implementation in the Zend Framework. However, with the addition of the Zend_Json_Server this is no longer the case. Read the rest of this entry »

, , ,

9 Comments

Automatically Require Dijit Widgets

Recently I have been playing with the dojox.dtl: the javascript port of the Django templating engine. So far I am quite impressed, not only is it fast and full featured, but by writing a wrapper class it is easy to make it behave like server side templating systems: you specify a template and pass it an object and it will render that object according to the template rules.

The only trouble I ran into was when I wanted to used Dijit Widgets in my templates. Since on my main page I didn’t know what template I would be calling, I didn’t know which Widget classes to include with dojo.require(). To fix this, I have come up with a little hack that does the job, although not too elegantly.

Bascially my approach includes hooking into dojo.parser and changing its behaviour. Now when it is parsing widgets from the page it checks to see if they exist and, if not, it does the appropriate dojo.require() to try to pull them in.

var fn = dojo.parser.instantiate;
dojo.parser.instantiate = function(nodes){
    dojo.forEach(nodes, function(node){
        var className = node.getAttribute(dojo._scopeName + "Type")
        if(!dojo.isFunction(dojo.getObject(className))){
            //It is not an object... yet
            dojo.require(className);
        }
    });
    return fn(nodes);
}

The above code-block shows the implimentation. Simply place this in between <script> tags in your header. Now you should be able to do dojotypes anywhere on your page and have the appropriate classes automatically included.

There are several disadvantages to my approach. For example, if you have a typo in one of your dojoType, it will try to pull down a file that doesn’t exist. We also have the impact of running through the array of nodes an additional time, although since the dojo.parser.instantiate function is already bounded by O(n) this shouldn’t make a noticeable impact.

, ,

No Comments