Here is a link to my slides and to find out more about this language visit these links.

This was part of the appeal to learning haXe in the first place – to not be tied to a single platform and to equip myself with the skills and knowledge to diversify if and when I need to or want to.

So how does haXe 2; Beginner’s Guide help with this?

Well, I’ve started learning how to develop on the PHP target after studying this book.  I’ve been planning on doing this anyway but now I’m a little ahead of myself.  I also tried using SPOD for the first time (and think it is a great feature!).  I was aware of SPOD before reading the book but the simple blog exercise in Chapters 8 and 9 made it very accessible to me – it turns out the basics are not that difficult after all.

Reading the book has also prompted me to look further into templating in haXe and I’m now considering using this feature to generate XML files for an upcoming project.

Would I have learnt about these features without reading this book?  Probably.  However, a book like this helps to accelerate learning by providing the relevant information to get started in a single place.  It is hard to find the time to learn new things and I am more than happy to get help with this.

On a side note, I noticed that the standard haxe.Template API is the templating system covered in the book even though other (more popular?) third party options exist (i.e., Templo and HTemplate).  I also noticed that JQuery, which has recently been added to haXe’s standard javascript API, was not covered in the chapter on javascript.  I would have liked to see some JQuery examples covered.

I found the book to be written in a very clear and accessible way and the information and advice contained in it is more than adequate to assist with getting started with haXe development.

The content of the book is also nicely structured – each chapter begins with a gentle intro to a topic that culminates with a ‘have-a-go-hero’ practical activity.

The book also follows a logical order with chapters building on what has been revealed in the preceding chapters – very conducive to learning being both continuous and progressive.  This seems like an obvious thing to get right but isn’t always the case.  I get a sense that a lot of thought has been put into it.  It could work well as a textbook to teach programming through haXe in schools.

The book is far from being a definitive guide to haXe though, nor does it claim to be by the fact that it is marketed as a beginner’s guide.  There is no mention of specific third party APIs although haxelib (a common repository for community libraries) is mentioned in the Preface.  There is also no coverage of the CPP target but this is probably beyond the scope of an introductory book and really merits a book of it’s own.

The Flash target, which is covered mostly in the final chapter, is not covered in any great depth – this suited me just fine since it is the non-flash areas that I was interested in.  It is fair to say that Flash is adequately covered as an introductory topic to the same extent as the coverage of Neko, PHP and Javascript though and Chapter 7 provides some really useful information about getting Neko/PHP, Flash and Javascript communicating with each other.

So would I recommend this book?

Absolutely.  This book is ideal for developers with no experience with haXe and also intermediate haXe developers with gaps in their knowledge and for those developers who are specialized in one area of haXe development but want to start broadening their knowledge.

The release of a new haXe book was announced this week by Benjamin Dasnois called haXe 2 Beginner’s Guide that I plan to review soon.  There aren’t many titles currently available for haXe so I was delighted to hear about this release and am looking forward to reading it and hopefully learning more about topics that have been on my todo list.  Stay tuned..

I’ve been using haXe for almost a year now and targeting Canvas using the Javascript target with my simple experiments has been fairly straightforward using Jeash (an API that mirrors most of the Flash API) because the workflow is identical to a Flash workflow.  Of course the Javascript target knows nothing about SWF files so it was clear that I was going to have to wean myself away from some of the really useful features of Flash like accessing linked library objects.  Adapting my workflow was what was required and luckily there are a lot of useful libraries that individuals and companies working with haXe have made available as Open Source projects.

Libraries such as Gm2d from Hugh Sanderson and the PushButton port called Hydrax have been interesting but I found the TouchMyPixel libraries to be particularly helpful.  Specifically, I like how they manage to use the Flash Authoring environment in their workflow even if they are not targeting the Flash Platform.

The TouchMyPixel code looked like a great way to further my knowledge of how to use haXe so I ended up forking their repository on my GitHub account and set about playing with the code and seeing if I could add support for EaselJs.

EaselJs is a library written by Grant Skinner and his team.  It effectively provides a displaylist for drawing on the Canvas element. The API design is clearly influenced by his Flash background since it provides a Flash-like displaylist but without it being identical to the Flash Displaylist. I was very happy when I discovered that Zjnue had already written the EaselJs externs for haXe.

What is nice about this approach is that I am using Flash CS5 to design layouts for Canvas-based applications and I could even make the same game or simulation also target the Flash Player. As an added bonus, the TouchmyPixel codebase has in-built support for Box2d and it didn’t take too much effort to get it working with EaselHx.

Click on this preview image to launch the Canvas demo. When open, click on the play button to start the simulation:

Click here to see a version published as a SWF file.

A screenshot of the demo being created in Flash CS5:

Note: Bare in mind that my TouchmyPixel fork is just experimental – use the original TouchmyPixel codebase if you want to use something that is more tried and tested.  The CPP target is also not working in my forked project – maybe I’ll play around with that next.  Jeash is maybe a more feasible javascript option for haXe if cross-platform development and access to a more complete Flash API is important.

The steps are the same as described in the link, except for the configuration on the main tab on the External Tools Configuration window.  The equivalent settings for Eclipse on a Mac corresponds to this terminal command:

current-directory-path> open .

How to Launch Finder in the project directory:

How to Launch Finder in the currently selected document’s directory:

The information on this page helped in creating a Run Configuration that opens Finder in the directory of the currently selected document.  The working directory in this case is set using: ${workspace_loc}${container_path}

You can achieve the same thing by installing the Easy Explore plugin but it’s good to have different options and I think that this approach is a little more convenient if it is listed on the favourites menu.

My quick fix at the time was to install Google Chrome, which I have grown to like but I needed to use HTTP Fox for something today and a quick search revealed the solution to restoring the toobars.  You basically launch Firefox in safemode from the commandline with this command:

“C:\Program Files\Mozilla Firefox\firefox.exe” -safe-mode

A dialog will then appear providing the option to reset toolbars and controls.

Update:

An even quicker tip is to toggle the visibility of the menu bar by pressing the ALT key! (tip from Tony Smith)

The Physaxe library contains a custom type called JsCanvas that acts as a wrapper for the Canvas element and it’s 2d drawing context.  JsCanvas shares the same method names as the graphics property belonging to display objects in Actionscript.  Compiler conditionals are then used in another class called FlashDraw to determine whether or not a member variable will be of type flash.display.Graphics or phx.JsCanvas.

It’s worth checking out.

• create a subclass of FlxGame with a frame metatag for specifying a preloader
• create a basic menu state with some basic presets added
• create a subclass of FlxPreloader
• create a subclass of FlxState that overrides create and update
  
• create a subclass of FlxSprite that overrides update, hurt, kill and reset

Download here

You can add it to FDT by going to:

Preferences/FDT/editor/Templates – Import

The Proxy and Mediator

• The Proxy typically sends notifications
• The Mediator receives notifications and can also send notifications
• The Proxy is located in the Model and is a natural location for domain logic, something that tends to be wrongfully be placed in Commands
• The Mediator performs the key task of separating the View and Model (which is the responsibility of the Controller in Cairngorm)
• The Mediator and Proxy have a similar setup
• Methods to override in the Mediator include;
  • listNotificationInterest(),
  • handleNotification()

About Commands:

• Since service interaction occurs in the Proxy (located in the Model), commands in the Controller are limited to things like; startup, shutdown.
• A Command is used when you want to do multiple things in response to a notification.
• Mediators can directly call methods on the Proxy instead of sending a notification.  You don’t have to create a Command for everything.
• Method to override in Command
  • execute()

The Facade

• Facade is where you retrieve, register and remove actors.
• The Proxies, Mediators and Commands all have access to the Facade.
• Some of the methods to override in Facade:
  • retrieveProxy(proxy)
  • registerMediator(mediator)
  • registerCommand(command)

Update:

Javier got in touch with me and kindly pointed out a couple of things that I had got wrong and also offered some encouragement.  These are a few points he made (I’ve made the amendments to my notes above):

“The Proxy contains controller-like code but is actually in the Model part of the architecture”

Javier – I’m not sure where you picked up this one but definitely not the case, or at least not for the Proxy. You’ll find that the Mediator already acts like a controller and that can trip people up about the framework. The reason for this is that the Mediator already does the key job of separating the View Component from the Model (e.g. a or many Proxy class) thus you don’t really have a huge need for commands, in fact very little. This is expected and because the Mediator essentially acts like a controller.

“…Controller are limited to things like; startup, shutdown, database calls.”

Javier – I could be misunderstanding database calls here as you could mean that a Proxy that makes a call to the server to fetch data from a database but was triggered by a command. Or say an AIR app that can interact with SQLite. But things like that you want to avoid having in the Command and move into the Proxy. This is one of the big differences between PureMVC and other frameworks because by moving service interaction into the model we can achieve portability and reusability.

“Mediators can directly call methods on the Proxy instead of sending a notification sometimes.  You don’t have to create a Command for everything.”

Javier – Cliff Hall, the creator of PureMVC, and others, especially myself couldn’t be more proud. You learned probably one of the most important things to take away from the presentation. A lot of people get this wrong. I use the word “wrong” as Cliff has stated very good reasons why this is not only acceptable in the framework but pushed for you to do. Don’t create a command class for an action that only ever happens in one place, you are just doing more work and adding more bloat.