Max Blog My Blog

JavaFx vs. MXML syntax and language design

Both languages are designed for UI declaration.

MXML is XML based representation of UI tree. Each XML tags represent UI components implemented in AS3 and you have many possibilities to embed AS3 code in MXML. Under the hoods the compiler will generate a number of AS files from one MXML file and compile them to a Flash Application (SWF file).

JavaFx is a complete new script language with AS3 like syntax. The representation of  UI tree is JSON like, so it's not as verbose as XML. I am not familiar with the internal processing of "fx" scripts but after compilation you get a few ".class" files that represent the elements you declared in the script.

JavaFx is just a script language for JVM, like for example Groovy, that has some special tools for UI creation.

In my opinion those are the key benefits compared to ActionScript 3:
- Function signatures are strong typed

- Static is banned in favor of Script Variable / Function
- Ranges are provided

- first citizen value changed observer

- first citizen value binding

-immutable objects and elements
-Bidirectional Binding

If you are interested in details have a look at this URL:
http://openjfx.java.sun.com/current-build/doc/reference/JavaFXReference.html

To type, or not to type

Static typing is a great thing. It makes a really good IDE support possible. It's encourage you by developing, because your code is validated by compiler and you can write intuitive API's.

But some times it is also cool to have dynamic typing.

AS3 is a very creative language also from this point of view. It let's you extend code in many ways.
First and most convenient way is class inheritance. So you have a class A and it is extended by class B. Nothing special it is a rudimentary feature of an OO language.

Second and not convenient way of extending an instance of a class is to declare the class as dynamic (have a look at Object class).

package {
  import flash.display.Sprite;
  public class MyClass extends Sprite {
    public function MyClass() {
      var a : Object = new Object();
      a.element = 30;
      trace('a.element: ' + (a.element));
    }
  }
}

But you can also extend a class that is final or not dynamic in AS3, because AS3 is not only Class based OO language but also Prototype based. That's how we can implement so called monkey patching.

package {
  import flash.display.Sprite;
  public class MonkeyPatch extends Sprite {
    public function MonkeyPatch() {
      Object.prototype.sayHello = function():void{trace("hello from " + this);};
      var myThis : * = this;
      myThis.sayHello();
      var s : Sprite = new Sprite();
      addChild(s);
      var myS : * = s;
      myS.sayHello();
    }
  }
}

Those funny declarations

When you declare a local variable in AS3 it turns out that it is visible for the hole scope it was declared in.
So for example you can declare a variable after its usage in code:

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
	  trace(a);
	  var a : String = "hello";
	}
  }
}

But the assignment will be executed as "expected" after the trace and that's why you see "null" traced in the console.

You can also make a duplicate declaration of a local variable, if it keeps the same type.

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
  	  var a : String = "hello";
	  trace(a);
	  var a : String = "hello2";
	  trace(a);
	  // var a : int = 2; That would be bad!
	}
  }
}

Another interesting declaration behavior is the declaration of error variable in catch block:

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
	public function Decl() {
	  try{
		trace(a);
		a.length;
		// trace('error: ' + (error)); Invisible			
	  }catch(error:Error) {
		var a : String = "error";
		trace('a: ' + (a));
		trace('error: ' + (error));
	  }
	  trace(a);
	  // trace('error: ' + (error)); Invisible
	}
  }
}

So error is only visible in the catch scope but the catch scope is not really a scope because if we declare variable "a" in the scope itself it is visible in the whole method.

Last funny example is about for-loop and static initializer.

package {
  import flash.display.Sprite;
  public class Decl extends Sprite {
    static var array = [1,2];
    for (var i : int = 0;i < array.length;i++) {
      trace(array[i]);
    }
    public function Decl() {
      trace(i);
    }
  }
}

The problem with this code is that variable "i" is declared inside of class declaration and that means that it is a field. It also not declared with static modifier and that's why you can't use it in your static initializer code.