Darren on Flex: Flexins Project Launch

I am proud to announce the launch of the Flexins Project!

This project is the result of some work I started several months ago. I started looking into ways to leverage Flex's declarative MXML to add extra behaviour to applications (or parts therein), using mixins. The project's homepage is over at Flexins Project @ Google Sites. It's in flux at the moment as I'm still getting my bearings in administering the site; please bare with me on that one. The source code is hosted at Flexins Project @ Github. I decided to give Git a spin on this project as it appears to be the emerging SCM of choice for open/public projects.

So what's it all about?

We are all familiar with includes, which work for both .as and .mxml files. This supports the code-behind style, which is a very useful separation mechanism when dealing with complex UI logic or copious event handler code. However, as a mechanism it is pretty stupid, relying only on assumption that internal dependencies (e.g. property existence) are satisfied. Of course, one can declare interfaces in .mxml and implement them in .as code-behind; I suppose this is the standard approach. The syntactical interface declaration (think: compiler) here also serves to declare (the availability of) any relevant behaviour (think: application feature) [Mixins are not necessarily or typically used this way, to add application features, but it is nonetheless the theme for my initial work]. However, firstly, the interface has to be defined and secondly the include is a waste full source include [Ok, it's debatable the real impact of this on binary size and performance blah blah blah... but from a idealist pov... it's not ideal]. I have found with this new approach to implementing mixins, you can achieve complete separation of responsibility e.g. keeping whatever it is your components are primarily supposed to do, from the behaviour implementation of the mixin. The state required for the mixin to function can be managed internally, negating the need for any interface definitions, declarations or implementations. And because the mixin is not used via a source include, there is only one compiled instance of the code in the binary. Application of the mixin is achieved through normal object-instantiation, not source inclusion everywhere the mixin behaviour is required. Another advantage of this new approach is that you do not need access to any source code; you do not need to re-write or extend some existing class in order to bolt on your desired behaviour. I will blog soon on how all this can be achieved. For now, have a look at an example of what the end result looks like; check out my Drag'n'Drop Mixin showcase. Cheers, q(^_^)p