Love it or hate it describeType is the only (almost) way to preform reflection on types in actionscript, it returns a XML document containing information about a type in one big dump! There are a number of excellent and proven libraries out their that can convert that XML dump into a nice OO data structure for you to code against, and it crossed my mind several times while developing dawn that they could make my life a lot easier. I however, created another reflection library… what was I thinking!?

Thing is, I have never needed a full strongly typed objected orientated representation of my type! That would be nice of course, but when I turn to reflection its not to create Method and Parameter objects (I’d rather the runtime did that to be honest) its because there are specific things about a type that I need to find.

A simple example of what I need reflection for in dawn would be to find all the methods in a type that have been decorated with the [Inject] metadata and have one or more arguments. i.e. all the injectable methods for a Class. Whether the reflection API gives me a XML document or the same information parsed into types I’m still going to have develop a way of finding all the methods with Inject metadata. Maybe that will be with e4x or maybe a loop over some objects (perhaps ensuring that they are methods not variables/accessors), then I will need to check that those methods have some arguments and are thus injectable. So whatever the means the types reflection information is provided by, the actual logic of my task is entirely up to me to develop and test.

With all that in mind, I built Fussy to be a little different from current reflection libraries (at least those that I know of). I wanted something to help me query my types, where the query represented whatever I wanted to find out about my types. To show you what I mean by “query”, lets see how fussy allows me to find the injectable methods on a type (the problem from above)

Start by creating a fussy

var fussy:Fussy = new Fussy()

Now to describe my query

var query:IQuery = fussy.query().findMethods().withMetadata("Inject").withArguments();

Now I can execute that query against any type, and get a array of strongly types Method objects

var methods:Array = query.forType(MyClass);

And TA DA! I have strongly typed method objects that satisfy my query for MyClass.

So what is Fussy?

Seems quite late in this post to be asking that, but I figured it would be easier to explain after an example. I call fussy an actionscript reflection query language. It does of course perform reflection, and parse the result of that reflection into strongly typed objects (only after a query has run) but the main aim of fussy was to make the logic of reflection (the reason why I was reflecting in the first place) easier as faster.

Fussy is a work in progress, I still think I can make the query API more elegant and there are lots more query extensions I can think of to add but its already pretty useful. It now supplies dawn with all its reflection needs, and what was a huge proportion of dawns code (searching and parsing types) base has been reduced down to one class.

Got lots more plans for Fussy, including things like metadata schema validation.  I find its pretty useful, so figured someone else might too.

Oh, here is the github link

When I first demoed Dawns injector in a LBi tech talk (almost a year ago now) one clever chap asked how it could be used to create a number of very similar, but different objects graphs. I only half got my head around the question at the time, and blurted out something about named injections. Then sometime (and some beers) later after discussing the problem more it became clear that Dawn didn’t really have a very elegant solution to the problem.

Time to explain the problem (if you’ve heard of the robot leg problem, thats the one!). How can I create two similar object graphs, with some defined differences without having to create new concrete classes to represent those different graphs (thats what you would have todo today btw)? Example time.

Picture a Car class (or just read the one below)

class Car {

  var engine:Engine;
  var transmission:Transmission;
  var driveLine:IDriveLine;

  public function Car(engine:Engine, transmission:Transmission, driveLine:IDriveLine) {
    // set properties etc //
  }
}

Engine and Transmission are base classes that have a number of subclasses like PetrolEngine, DieselEngine, AutomaticTransmission and ManualTransmission. IDriveLine is an interface for the various type of drive the car could have, FrontWheel, RearWheel or FourWheel etc.

The Car class itself is pretty flexible (polymorphism is handy like that), depending on how we construct the car we could get a four wheel drive diesel or an manual transmission, rear wheel drive etc. In Dawn today you could create a configuration for your Car and install it into the injector.

class CarConfig implements IConfiguration {

  public function configure(mapper:IMapper):void {
    mapper.map(Engine).to(PetrolEngine);
    mapper.map(Transmission).to(ManualTransmission);
    mapper.map(IDriveLine).to(RearWheel);
  }
}

// then where you create your injector

injector.install(new CarConfig());

Using the above code, every time you requested for a Car from the injector it would create one with a petrol engine, rear wheel drive and manual transmission. *Every Time* is not what we want though! Without private configurations we would have to find a way round this, most likely by creating subclasses of Car, such as PetrolCar, which had a constructor parameter of type PetrolEngine, then the same for RearWheelDriveCar, and so on, until we had classes to represent the varieties of object graphs we wanted.

Private configurations are a port of Guices solution (private modules) to the same problem. They allow you to create groups of mappings that are only available under certain conditions.

Here are a couple of private configurations for the above problem

class SportyCarConfig implements IPrivateConfiguration {

  public function configure(mapper:IPrivateMapper):void {
    mapper.map(Engine).to(PetrolEngine);
    mapper.map(Transmission).to(ManualTransmission);
    mapper.map(IDriveLine).to(RearWheel);

    mapper.expose(Car, "Sporty");
  }
}

class ChelseaTractorConfig implements IPrivateConfiguration {

  public function configure(mapper:IPrivateMapper):void {
    mapper.map(Engine).to(DieselEngine);
    mapper.map(Transmission).to(AutomaticTransmission);
    mapper.map(IDriveLine).to(FourWheel);

    mapper.expose(Car, "4x4");
    mapper.expose(Showroom, "SUV Land");
  }
}

If the two configurations above were just normal configurations we would have a little problem when we installed then into the injector, since they both create mappings for the same types. So the second configuration to be installed would overwrite the first ones mappings for Engine etc. Also notice that both the private configurations make one or more calls to an *expose* method.

Installing private configurations is almost identically to installing normal ones:

var injector:IInjector = Injector.createInjector();

injector.installPrivate(new ChelseaTractorConfig());
injector.installPrivate(new SportyCarConfig());

Installed private configurations do not overwrite mappings within other normal configurations or private configurations. So when we install the SportyCarConfig we have not overwritten the settings in the ChelseaTractorConfig. But how then do we create a car that uses either one of those configurations? Well thats what the expose method is all about! Private configurations are private (hidden) until a special exposed mapping is requested from the injector. Once the exposed mapping is requested the mappings within the private configuration become public, and take precedence over any configurations that already exist in the injector.

Lets expand the above code snippet a little to add some default mappings for the IDriveLine, Engine and Transmission.

var injector:IInjector = Injector.createInjector();

// add default normal car mappings
injector.map(IDriveLine).to(FrontWheel);
injector.map(Engine).to(PetrolEngine);
injector.map(Transmission).to(ManualTransmission);

// install the private configurations
injector.installPrivate(new ChelseaTractorConfig());
injector.installPrivate(new SportyCarConfig());

Now if we request a Car from the injector (injector.inject(Car)) we will get the default options:

var car:Car = Car(injector.inject(Car));

trace(car.engine is PetrolEngine) // true
trace(car.driveLine is FrontWheel) // true
trace(car.transmission is ManualTransmission) // true

To activate a private configuration we must request one of the exposed mappings. Ok, lets create a sporty car.

var sportyCar:Car = Car(injector.inject(Car, "Sporty"));

trace(sportyCar.engine is PetrolEngine) // true
trace(sportyCar.driveLine is RearWheel) // true
trace(sportyCar.transmission is ManualTransmission) // true

This time when we asked the injector for a Car we specified the name of the mapping, Sporty. When the injector sees that we are requesting a mapping of type Car named Sporty, it activates the SportyCarConfig, since that is the *exposed* mapping of the configuration! It doesn’t matter that the configuration does not supply a mapping for those options (type Car, named Sporty), it just knows that thats the mapping that unlocks it.

Now we can create a four wheel drive car

var bigCar:Car = Car(injector.inject(Car, "4x4"));

trace(bigCar.engine is DieselEngine) // true
trace(bigCar.driveLine is FourWheel) // true
trace(bigCar.transmission is AutomaticTransmission) // true

This time we requested a mapping of type Car named 4×4, which is one of the exposed mappings that activates the ChelseaTractorConfig, so the car we get is provisioned with the mappings found in the ChelseaTractorConfig over the default ones.

And that in a nutshell is what private configurations are all about. They are a terse and clean way to separate configurations for object graphs which can be activated by special exposed mappings.

This is all tested and committed to the dev branch of Dawn awaiting inclusion in the next release

I am aiming for dawns injector to be a complete injection solution (shiny bells AND whistles!!). Its not doing bad, but there are a few places that some polish wouldn’t hurt (better error reporting is a big on one those, its on the way).

This latest change was born out of a request from Mr. Tink. He wanted to be able to map one class (in singleton scope) to two interfaces. While such an exciting feat was possible previously, it really required knowledge of factory providers (and consequently some custom code). The new solution is much neater and is as simple as pie… I hope, O.K. an example:

Lets say I have a model object that implements a simple interface for views (or mediators or whatever said framework fancies). Simple, except that I also want methods on the object that shouldn’t be exposed to the view objects, so those can be added to an interface that extends the original one with the extra functionality.

// for dumb clients things like views etc
interface IAccessData {
  function getMyThing():Thing;
}

// for services/commands etc
interface IChangeData extends IAccessData {
  function updateMyThing(wibble:Wibble):void;
}

class ThingModel implements IChangeData { ... }

ThingModel implements both of these interfaces, and I only want one of my models to be created and that same instance to be injected for anything that require either IChangeData or IAccessData.

Previously I would have either had to map to a factory or an instance twice to get this to work, i.e.

// pray it has no constructor dependencies
var myModel:ThingModel = new ThingModel();
injector.map(IAccessData).toInstance(myModel);
injector.map(IChangeData).toInstance(myModel);

or

injector.map(IAccessData).toFactory(ThingModelFactory);
injector.map(IChangeData).toFactory(ThingModelFactory);

class ThingModelFactory { ... blah ... }

Either way, I have to create two mappings and its not so fun. If there was a third interface, or I wanted to also map the concrete class to the same instance it would require a third mapping.

In the next version of dawn (already in the dev branch) we can just do this

injector.map(IAccessData).and(IChangeData).to(ThingModel).asSingleton();

Ta Da!!

Much easier. Under the hood dawn still creates two mappings, its just sugar coated with the mapping DSL and our lovely ‘and’

Its also “chainable” (is that a word? I doubt it).. so if I also wanted classes that depend on the concrete implementation of ThingModel to get the same instance,  I could just add another ‘and’

injector.map(IAccessData).and(IChangeData).and(ThingModel).to(ThingModel).asSingleton();

And there you have it, multi-mapping goodness.  There are lots of other things coming soon, I just needed to get that one off my chest.

Also worth checking out is the asEagerSinglton scope that just made it into 0.8

I also feel fortunate that I had such a good topic to talk on, as that always makes it easier so many thanks to Cliff for doing such a great job with PureMVC

In case anyone is interested I have uploaded the slides and the sample code…
code
slides (keynote)
slide (swf)

I particularly enjoyed the talk given by the BBC. The somewhat muted service they provide for non-Windows users has always been a bug bearer for me. I was pleased to hear though that they have been handed a solution to their licensing issues by the DRM support in Air 1.5. This means we can now have the same download manager facilities, along with some notification goodness, wrapped up in a shiny cross-platform AIR app – result.

Another demo that caught my eye was a news reader for the New York Times. I was shown the current New York Times news reader about a year ago. It’s a chunky WPF application, so no good to me in Unix land. What it did do very nicely however was display column based text in whatever sized window you might have the app open in. That same functionally is now available (or soon to be, I’m not sure if it’s out yet) in an Air application. This is no doubt made a lot easier by the new text rendering engine within Flash 10, which allows text to flow between containers. For some more info check out this report

Ohh, and for general information about the Keynotes go here

ta ta

ps, I’m also posting on the LBi blog, check it out here

The basic idea is that with a nominal amout of metadata Snooze can create your database, and perform CRUD operations for your objects.  It supports the most common relationship types, one-to-one, one-to-many, and many-to-many, and I am planning to build a querying api into it.

If your interested in finding out more about it you can check it out on github… where hopfully you will see a lot of commits from this lazy geek!

With the above in mind I though it was about time I created a little application that I could send around to plug my abilities etc, and you can see it here

A little about how it works

The app is built using Flex 3.0 and the Cairngorm framework. Data is pulled in via XML, and displayed using a simple image viewing component I created.

Why use Flex

Flex enables me to build the same breed of applications we have all been building with Flash for sometime… only with Flex we can do faster, more reliably, with a fuller api and using a decent IDE… whats not to like?

Why Cairngorm

Cairngorm is all about building complex RIA’s in a consistent MVC manner… adobe puts it like this “The Cairngorm microarchitecture is intended as a framework for Enterprise RIA developers”. As you may have noticed the little image viewer I’m using as my example code is no enterprise application, in fact it only has a couple of user gestures, I’m just trying to demonstrate my familiarity with the framework.

I think Cairngorm is very important to the Flex developer community, it offers a well proven methodology for building applications, which separates concerns, promotes testability and leads to very predictable, scalable solutions.

About the view

I wanted to build a little set of classes that would allow me to display items (which could be anything from products to images etc.) in a number of ways, and was simple to extend. The snappyviewer, which is the name of the component displaying the images is an implementation of those classes.

The main classes the view is built around are two interfaces IItemView and IItemDisplayer.

Both interfaces contain a function named display. The display function in IItemVIew is intended to delegate the displaying of items to the IItemDisplayer via composition. The display function in IItemDisplayer is implemented for various display types, ie, displaying items in a grid, or in a row (GridItemDisplayer & SlideItemDisplayer).

To change which type of view the IItemView uses I can set the IItemDisplayer though the dispayer setter function in IItemVIew and hey presto, the view is updated.

You can check out the code by right clicking on the application and selecting Source View.

Any feedback welcome

ps.. you can see the application here

Since I first heard about Flex over a year ago and started working with it I have been very impressed. It’s a great platform for developers to create amazing web applications on… but for me there has been one big elephant in the room, and that’s the designer developer workflow!

We’ve all seen Blend combined with XAML now, and if you’re anything like me the first thing you thought when you saw it was why on earth cant Adobe do that with mxml!!!! And now it looks like they have with the project codenamed Thermo.

Thermo allows designers to use the tools they love (like the mouse…) and to draw the application as that want it. Thermo will then convert, on the fly (or when imported from a program like photoshop) the graphics into mxml! Perfect! It even allows for visual tweaking of motions and transitions. Its looks the the application I have been dreaming the Flash IDE would become for ages!

I personally can’t wait to see what comes of this… my hope (and this may be pie in the sky right now) is that we can in the not too distant future say goodbye to the Flash IDE (well, us developers at least). This would enable developers to focus on building applications rather that bullying design into behaving like one!

For more info on thermo check out this demo.