Sam MacPherson

Flash, Haxe, Game Dev and more…

Category Archives: web

Web 2.0 with Haxe

When it comes to modern web infrastructure there are three main things you need to worry about when programming: Front-end development (JS, DOM, CSS, etc), stateless http(s) service and within recent years stateful push services. I’ve been building a website over the past year and a half, and I must say that Haxe has been a great asset for this project. Traditional web development would have required me to write in php, javascript, html, css and perhaps java for the stateful service (modulo some other similar languages). But NO! With the exception of css everything is written in Haxe. The client, the http server and the stateful push server are all using the same code base.

To demonstrate how awesome Haxe (and the community) is I will explain how the chat on my site works. Below is an example of some client sending a message to two different people. All 3 of which are on completely different devices and browsers.

As you can see all 3 clients have the capability to communicate with the http server. I hope you can agree that it is a reasonable assumption that all browsers are able to communicate via http. 😀 On the other hand Client 3 is unable to communicate with the push server because of lack of support for web sockets and flash.

The first message that Client 1 sends is addressed to Client 2. The message gets sent to the http server which notices this is a chat message and immediately forwards it to the push server that Client 2 is connected to. It might make sense for Client 1 to send the message directly to the push server, but this may have issues if Client 1 and Client 2 are not connected to the same push server. Anyways, Client 2’s push server then forwards the message to Client 2. Behold instant messaging!

In the second scenario Client 1 sends another message to Client 3 who is browsing the site with his Android device. Unfortunately as of the time of this writing Android’s native browser does not support web sockets (nor flash), so we are stuck with http polling. What happens here is even though Client 3 is not connected to a designated push server we can still agree on a stateful server to hold the message until Client 3 requests it. The http server can’t hold the message because it is stateless. If the user won’t be requesting the message for a while, long term database storage is a good idea.

Now if we were doing this with 2 different languages for both the http and push servers things would be a little nightmareish. Duplicate code would pop up all the time with interpreting protocols and backwards compatibility for users who need to rely on http polling. Not to mention duplication in the client code as well. Haxe unites all 3 essential programming components of websites into a largely overlapping code base.

I want to say also that https://code.google.com/p/haxe-websocket/source/browse/library/js/WebSocket.hx is a great library for Haxe-based modern web design. It allows for setting up a Haxe push server which can communicate with web socket enabled browsers as well as a client implementation for server-server communication. If the client’s browser doesn’t support web sockets or flash then the http server can act on behalf of the client to communicate with the push server.

Advertisements

Why Haxe is Just Awesome

Recently I’ve switched gears and am working on a website. For this website I had originally decided to use the Drupal CMS as the backend. This was before I actually started working with Drupal on another unrelated site. Drupal to me seems like a fine choice for certain kinds of websites, but in the end it just seems to rigid for my needs. It’s also built to minimize the amount of programming you need to do. The thing is that programming is one of my strengths, and I don’t want to ignore that when choosing a backend. However, I am not very knowledgeable in scripting languages — PHP/Javascript in particular. So I decided to give Haxe a try and so far I am loving it.

The fact that Haxe can compile to both javascript and php allows me to merge the server and client logic into the same codebase. Very nice for event driven behavior. For example, if I want to do client-side form validation, traditionally I would have to design the form in php and have some sort of javascript validation function loaded in somewhere. This is okay for small projects, but I am aiming big and want everything to be as nice as possible.

My solution was to abstract all the HTML nodes into an Element class and use that as the base for everything. The element class has a lot of fancy functionality for attaching and detaching classes and such, but at the core everything would operate through the getAttribute and setAttribute methods which (using conditional compile flags) compile differently depending on whether I was targeting javascript or php. Here are the methods:

public function setAttribute (key:String, value:String):Void {
	#if js
	domNode.setAttribute(key, value);
	#else
	attribs.set(key, value);
	#end
}

public function getAttribute (key:String):String {
	#if js
	return domNode.getAttribute(key);
	#else
	return attribs.get(key);
	#end
}

What the php version does is prepare the attributes for printing to the html response while the javascript version will access the properties directly on the html nodes. I then have a special bootstrap function in javascript (Idea taken from the Distill Haxe library) which will prepare the html into a tree of Element’s on load. If you want to do something similar then have a look at the Distill library for reference.

What does this allow me to do? Things like this.

class DivWithClickListener extends Element {
	public function new () {
		super("div");
		
		add(new P("Some text produced in PHP"));
		addEventListener(Element.EVENT_CLICK, this);
	}

	public static function event (e:Event):Bool {
		Lib.alert("This is a javascript click event!");
		return true;
	}
}

For technical reasons the event handler must be static, but I do include several useful properties.

Event.source:Element – The source object.
Event.handler:Element – The handler object.
Event.type:String – The event type.
Event.jsEvent:Dynamic – The original javascript event. (Browser dependant so should be used with care)

Accessing and changing the html elements is very simple. As I’ve made sure the Element class is completely functional from both php and javascript. So for example if you want to add/remove a class from an element then all you have to do is:

Element.addClass(“myCssClass”);
Element.removeClass(“anotherCssClass”);

This code will do the exact same thing no matter if it’s run from the server or the client. Very cool!