Tuesday, January 9th, 2007
Category: Builds
, Dojo
Shane O’Sullivan of IBM has released a GUI build tool for Dojo that is built on Eclipse RCP.
He talked about this new tool earlier:
There has been a lot of talk currently about making the build system for Dojo simpler. The web based method (customise a build on the Dojo website and download it from there) definitely shows promise, and will be attractive to many users. However, I think that many developers would like to have more control over the build process, while still having the possibility of all of it being automated for them. For this reason I’ve decided to look in to the possibility of using an Eclipse based build system that can operate as a standalone Rich Client application or be a new perspective in Eclipse.
Monday, January 9th, 2006
Category: JavaScript, Builds, Java, Toolkit, Firefox, Testing
J3Unit is a new OO testing framework for Javascript with optional integration with Jetty and Junit for automation into your test suite. It builds upon the work done with the Script.aculo.us test unit runner and JSUnit.
Of course, you can grab the zip file and just get up and running in static mode. Or take a look at the demo page for how static mode works.
Local browser mode sounds like an alternative to Selenium, or maybe Watir, though the description isn’t quite clear on it:
Local Browser Mode is a JUnit test case DefaultJ3UnitTest that runs both Jetty and Firefox on your local machine. This test case is intended to be included in a larger suite of JUnit tests that the user plans on running directly on his or her machine.
So I’m guessing the idea behind this mode is you can write your test cases in Junit or Javascript, and have a consistent, stand alone run environment with the Jetty+Firefox package. Of course, going with Junit brings with it the possibility of integration with Ant and CruiseControl, as the dojo folks have been doing this for awhile with Jum.
Does anyone know of similiar automation options for Javascript that don’t depend on Ant or Java?
(via Matt, who appears to have trackbacks disabled)
Tuesday, November 22nd, 2005
Category: JavaScript, Builds, Flash
haXe is an open-source programming language supporting portable code across the different web platforms: Ajax, Flash, and server-side. Developer Nicolas Cannasse lists its capabilities:
- create Flash SWF files using Flash APIs for Players 6,7,8 and soon 8.5.
- generate Javascript code using Browser DHTML API, so you can create AJAX web applications.
- generate Neko sourcecode that can be used on the Server side or in standalone executable.
Each of theses platforms have their own API, but they share the same programming language and the same standard library, so if your classes are pure code (using no platform-specific API) then they can be compiled and used everywhere, depending on your needs.
To clarify: haXe isn’t a set of cross-platform widgets and libraries, but is instead a standard syntax for loops, data structures, and so on. Syntax is Java-like:
class Point {
public var x : Int;
public var y : Int;
public function new() {
this.x = 0;
this.y = 0;
}
}
Some Ajax apps have business logic (e.g. validation) inside the browser to speed things up, but also have to duplicate the logic in the server, for the sake of security. One way to manage the duplication is with server-side Javascript, but haXe might make a good alternative.
Tuesday, March 15th, 2005
Category: Ajax, JavaScript, Builds, Java
A lot of developers ‘poo poo’ any code that is written in JavaScript.
- “JavaScript isn’t a real programming language”
- “JavaScript is just about browser hacker scripts”
- “You can use it to focus(). Big deal.”
- “JavaScript is for the HTML designers, not for REAL coders”
Giving thought to your JavaScript code
As such, any JavaScript code in a project, doesn’t get the thought that it deserves. Why would you be anal about unit testing your Java code, and ignoring your JavaScript code?
You no longer need too, as we have JsUnit, and other tools.
Dependencies are dependencies
As soon as you stop thinking of your JavaScript code as a bastard step-child, you can apply the same practices that we have in our other worlds (e.g. Java).
One of the problems with Java web applications, is that you can often do a search for files on a developers hard drive, and see MANY of the same files.
For example, you search for struts.jar, and there are 23 instances of it on the file system. Of course, they are not all the same size, since they are various versions (but you don’t know).
We get around that problem by using a tool such as Maven, or Ivy.
Now, we can define our project dependencies, and the correct versions are tracked, and downloaded automatically. Very nice.
WEB-INF/lib == /scripts
Why don’t we do this with JavaScript code? We have the same problem with commonscript.js as we do with struts.jar. So why not manage it?
Maven JS type
Maven has the base framework that we need to make this quite trivial. First, we can just agree on the ‘type’ of dependency. I am using js. Then you can just add dependencies as per normal:
<dependency>
<groupId>adigio</groupId>
<artifactId>xhr-test</artifactId>
<version>0.1</version>
<type>js</type>
</dependency>
This means that maven will try to grab:
/[groupId]/[type]s/[artifactId]-[version].[type]
or in the example above:
/adigio/jss/xhr-text-0.1.js
from the various repositories that you have setup in your project.properties:
maven.repo.remote=http://adigio.com/maven,http://www.ibiblio.org/maven,http://www.codeczar.com/maven,http://xdoclet.sourceforge.net/repository,http://dist.codehaus.org
NOTE: ‘[type]s’ is hard-coded. There is no way to map “when you see type ‘js’ look in directory ’scripts’, or something like that. This means that ‘jss’ looks a lil’ silly :).
maven-war-javascript
So, we didn’t have to do anything to get Maven to start grabbing dependencies for us. But, in our projects we don’t just want to grab some JavaScript modules and put them in your local repository. We want to use them :)
Rather than writing some manual goals to handle this, I wrote a Maven plugin which piggy-backs on the war plugin.
The maven-war-javascript-plugin offers a war:js / war:js:copy-scripts goal. This manually looks through your dependencies, and copies any JavaScript modules to your web app (in the scripts directory by default. To change, use the maven.war.javascript.dir property).
However, although you have a goal in which you can kick off this task, in practice you don’t need to use it. The plugin registers itself with the war module, and whenever it is invoked, it sneaks in and does the copy. So, it is a seemless introduction!
Installation
To download and install the plugin, you can simply:
- Add: http://www.adigio.com/maven to maven.repo.remote
- Run the commmand: % maven -DartifactId=maven-war-javascript-plugin -DgroupId=adigio -Dversion=0.1 plugin:download
Conclusion
So, now I can take JavaScript more seriously, and can start managing my JS dependencies with the care and loving touch that I do with the immense amount of open source library bloat :)
