Monthly Archives: January 2010


AS3 Multiple Inheritance/Mixins 2

Well, I just got done reading this post about multiple inheritance in as3 which probably should have been titled AS3 mixin technique, because that is more or less what it is, check out the wikipedia article on mixins for some history and pros and cons. I’ll will admit straight out that I am a supporter of MI and Mixins and the like. I am not much for the aristotelian idea of the universe, sometimes A is A, and sometimes it’s both A and B and MI, when used responsibly helps you to find more elegant and concise solutions to a great many problems. Just because people use something incorrectly in some instances doesn’t make that thing inherently evil, take for instance perscription drugs, would you rather painkillers where completely banned or never prescribed just because some or even alot of people abuse them? No, a great many things when used excessively with little understanding of what it is and how it works can be called evil, but they aren’t, the people who abuse them are evil, let’s start calling a spade a spade. The problem with MI and Mixins is not that they are evil, it’s that evil people use them for nefarious purposes. Anyway, back onto topic, I liked the guys article, and to be honest, he was pretty brave for putting it up, the minute you say something about MI, either way, a “discussion” read “flamegeddon” ensues, not always, but it’s generally a risk when you start throwing words like Inheritance around with […]


ActionScript 3.0 Wishlist

ActionScript 3.0 is just, well, pretty damn awesome. Nevertheless, as I’ve been working in AS3, I have come across a few limitations of the language, that while not show stoppers, leave just a little something to be desired. 1. No control over GC. That doesn’t sound important to your average Joe Programmer, but being able to commandeer, or at least influence Garbage Collection would be so totally awesome. For instance, I am working on a framework that more or less enforces a singleton based architecture, everything should be a singleton, except in 1 or 2 small circumstances that the framework controls. I.e. I have a special object wrapper that controls an inner object and can do some fancy footwork about it, all without you really having to worry about what is in the object. I would love for the user to be able to call SpecialObject.destroy(), and have it completely obliterated from memory. As it stands right now, this is not possible. Further more, it’s not really possible to make sure anything is removed from memory, because if it has even 1 single existing reference in your entire app, it will not be GCed, as was pointed out in the gskinner.com post about the AS3 Garbage Collector. Furthermore, if it has an event attached to it, it can’t be destroyed, which causes all kinds of issues, including one I’ll talk about in a moment. One method of fighting against this, that I am working on, but unsure of, is to discourage putting objects into variables […]


Adobe Flex/AS3 MX:Grid Class

Well, I said it in a previous flex tut, that you shouldn’t manually create your mx:grids cause it’s super ugly, instead of just telling you, I decided I’d show you, heres a basic start class for creating an mx:grid dynamically, you can modify the previous demo code to use it easily, that’s how I tested it. Table.as package org.jasonmartin.demo.views.components { /** * … * @author Jason Martin */ import mx.containers.*; public class Table { private var rows:Array; private var pointer:int; public static const NAME:String = ‘Table’; public var id:String; public function Table() { this.pointer = 0; this.rows = new Array(); } public function addRow(row:Array):Boolean { this.rows.push(row); return true; } public function addColumn(col:Object):Boolean { if (typeof(this.rows[this.pointer]) != ‘object’){ this.rows[this.pointer] = new Array(); //just in case } this.rows[this.pointer].push(col); return true; } public function next():int { this.pointer++; return this.pointer; } public function previous():int { this.pointer–; return this.pointer; } public function resetPointer():Boolean { this.pointer = 0; return true; } public function grid():Grid { var g:Grid = new Grid(); g.id = this.id; for (this.pointer = 0; this.pointer < this.rows.length;this.pointer++) { var r:GridRow = new GridRow(); r.id = this.pointer.toString(); for (var i:int = 0; i < this.rows[this.pointer].length; i++ ) { var gi:GridItem = new GridItem(); gi.id = “Row_” + this.pointer + “_Item_” + i; gi.addChild(this.rows[this.pointer][i]); r.addChild(gi); } g.addChild(r); } return g; } } }


Adobe Flex View Partialing and xmlns

When you are creating an AIR/Flex app, and especially when doing so using PureMVC, you really need to break your views into component parts. With a very complex view component, you made need to break your components into components. One thing that, in all my reading, I haven’t heard said, is that you cannot think of MXML as XML, it’s not, think of it as an ActionScript class that instead of defining in ActionScript, you define it in an xml like markup language. You need to think of it like this, because you need to think in OOP, and each component is a thing which has State + Behavior. Don’t just put a textinput, put a textinput object that knows who and what it is, and what it is supposed to do, encapsulate all of the textinput behavior into that component, and then suddenly, you have a reuseable view component that can have alot of complex behavior and you only ever have to code it once. This is going to be pretty simple, and I will just start with a basic app, and create a standard package structure. My package will be org.jasonmartin.demo, and for that package, I’ll create a subdirectory called views, and in the views, components and form_components. As you can see, I have created some MXML files in there, here is the code for each: //Main.mxml //Form.mxml //MyTextInput.mxml These are pretty basic views, and I have coded in the basic functionality. The Form adds children to itself, and this is where most […]