Just a quick post on a flex builder 3 bug I just found.

Defining a constant on an interface causes Flex Builder to give you the ever helpful message at compile time :

“An internal build error has occurred.  Right click for more information”

Of course, there is no more information, you have to find what you did to break it through old fashioned sleuth work.

Anyway, constants on interfaces :  A stupid mistake, yes… but it’d be to have the compiler issue a stern telling off rather than flex builder throw it’s hands in the air and give up on me completely.

Really, Flex Builder – after all you and I have been through!?

Faithfully yours,

Abandoned.

I’m now finally allowed to post information about a project I worked on : Morgan Stanley’s  ”Matrix

It’s by far the biggest flex application I’ve ever worked on, and probably one of the most significant uses of the Flex platform to date.

The client, Morgan Stanley is one of the biggest investment banks in the world, and their product - Matrix is a trading platform that allows rich, real time collaboration through chat, video, sharing of trade ideas, charts.  

The development team was full of some of the top developers I’ve ever worked with, working on the project was a priveledge and a non-stop learning experience!

Check out the site, and take the tour!

I’ve recently been getting my feet wet in Java, and starting integrating with dpHibernate to facilitate lazy loading across to Flex.

Here’s what my stack looks like:

  • Spring 2.5.6
  • Hibernate 3.3 (including annotations, and transaction management)

Trying to get dpHibernate wired in, I was getting lots of errors along the lines of the following:

No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here

 

The problem here is that using transaction management, things get a lot tighter on how and when you can get access to a hibernate session.  dpHibernate tries to get it’s session by essentially calling sessionManager.getCurrentSession();

However, as far as Spring’s transaction manager (which is wired into the SessionManager) is concerned, the thread which is executing has no session, and has no business trying to create one — specifically, outside of a transaction.

After spending several hours trying to work out how to sidestep Springs transaction management, I realized the trick was simply to wire dpHibernate closer to spring.  This is tricky, because dpHibernate is using an extension of the flex’s JavaAdapter, and exists completely outside of the Spring infrastructure.

HibernateSerializer makes a call to a dpHibernate object called SessionManager, which returns the current session outside of a valid Spring transaction.

So, I ditched the SessionManager completely, and replaced it with a good old fashionsed SessionFactory object, as follows:

    @Resource
    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory) {
        this.sessionFactory = sessionFactory;
    }

    public SessionFactory getSessionFactory() {
        return sessionFactory;
    }

The @Resource tag there tells Spring to give me a wired up sessionFactory instance.

I also decorated the HibernateSerializer with a @Transactional tag, so that Spring knows the context in which this will operate:

@Transactional(readOnly=true)
public class HibernateSerializer implements ISerializer
{

Now, if I add the HibernateSerializer as a bean, Spring knows to give it access to a sessionManager, and to do so in the context of an active transaction.

Add the bean declaration as follows:

<bean id="hibernateSerializerBean" class="net.digitalprimates.persistence.translators.hibernate.HibernateSerializer" />

Nearly there. Finally, I just need to tell dpHibernate to go and fetch this wired up Serializer from Spring, rather than instantiate it’s own. Inside SerializationFactory, I modified the getSerializer() call to read as follows:

    public static ISerializer getSerializer(String type)
    {
        if( HIBERNATESERIALIZER.equals(type) )
        {
            ServletContext ctx = FlexContext.getServletContext();
            WebApplicationContext springContext = WebApplicationContextUtils.getRequiredWebApplicationContext(ctx);
            ISerializer serializer = (ISerializer) springContext.getBean("hibernateSerializerBean");
            if (serializer == null)
            {
                throw new RuntimeException("bean named hibernateSerializerBean not found");
            }
            return serializer;
        }

        throw new RuntimeException("unsupport serialization type: " +type);
    }

Note that I’ve hard coded the name of the bean here for simplicity sakes. Chances are you’ll want to paramaterize that.

That’s it! Now, calls that pass through dpHibernate happen with a Spring managed transactional session. Great!

 

Edit: Espen came up with a simpler alternative over on his blog — check it out : http://espenskogen.wordpress.com/2009/06/04/more-dphibernate/

Here’s a trick which you may already know about (after all, it’s in the docs) but I only discovered it today when I needed it.

Conditional compilation allows you to vary the classes and functions included in a compilation based on a config value.

Eg., You may have a slightly different codebase used for your debug build than for your release build.

For example, on my current project we have a couple of convenient hacks in use in our test environment to prevent us from needing to log in every time we launch a debug session.

However, somewhat predictably, one of these hacks recently made it through to our testing team, and broke all sorts of stuff.

So, I figured I’d find a way to automatically remove it as part of our build process.

The class got modified to look a little something like this:

public class PrepCommand extends SimpleCommand
{
      public override function execute(notification:INotification):void
      {
            doDebugLogon();
      }

      CONFIG::debugging
      private function doDebugLogon():void
      {
            trace("This is where the logon should happen");
      }

      CONFIG::release
      private function doDebugLogon():void {}
}

Note that the doDebugLogon() method is defined twice within the method, varied by the CONFIG attribute.

This attribute defines under which compilation configuration to include the method. You can do the same thing for a full class.

Next, I modified the compiler-config.xml file used for our project to include this snippet:

<flex-config>
    <compiler>
        <define>
            <name>CONFIG::debugging</name>
            <value>true</value>
        </define>
        <define>
            <name>CONFIG::release</name>
            <value>false</value>
        </define>
    </compiler>
</flex-config>

Then, simply swapping the values of debugging & release would modifiy which of the function calls are included in the compiled source.

Not bad, but still not very automatic.

Because we’re a .NET shop here, our build tool of choice is nAnt. Most of our config files for the flex build are generated from template files, using nAnt variables to give us nice flexible builds. (pardon the pun).

So, I introduced a new target into our build file for performing a release compile:

    <target name="release" description="Performs a release, setting appropriate config values.">
        <property name="debug" value="false" />
        <call target="build" />
    </target>

…and added a couple of new variables to the properties file:

    <property name="useDebugConfig" value="true" />

    <!-- Derived from useDebugConfig.  Set the value of useDebugConfig rather than setting useReleaseConfig.
        Note that only one of these values must be true, or compilation will fail -->
    <property name="useReleaseConfig" value="${string::to-lower(not(useDebugConfig))}" />

Then, I tweaked the compiler-config described above to look like this:

<flex-config>
    <compiler>
        <define>
            <name>CONFIG::debugging</name>
            <value>${useDebugConfig}</value>
        </define>
        <define>
            <name>CONFIG::release</name>
            <value>${useReleaseConfig}</value>
        </define>
    </compiler>
</flex-config>

Now, ensuring the correct code is included is as simple as:

nant // Calls 'build', our default target using the debugging compilation options
nant release // Uses release compilation options

That’s it.

It’s worth reading up on conditional compilation in the docs, as there’s a bunch of great examples in there.

Questions / comments welcome.

Marty

In the Silverlight vs Flex debates, I’ve always been staunchly located on the Flex side of the fence.

But, as much as it pains me to say it, it’s beginning to dawn on me that the dirty ol’ boys in the Microsoft labcoats may just have the leading edge.

And, it’s not about browser penetration, or hi-def video, or 3D capabilities, or swanky new sound API’s.

It’s about language.

If you wanna compare these two frameworks, feature-by-feature, then as it stands, Flex wins out — every time.  But what people tend to miss (IMHO) is that we’re comparing frameworks, and not languages.

Do a comparison of Actionscript to .NET, and it’s a whole different kettle of fish.

Comparatively, shipping a new release of a framework with additional features takes much less time than adding features to your language.

In the time span between Alpha and Beta 1 of Silverlight, MS added a bucket load of features to their (somewhat limited) framework.  Beta 1 to Beta 2 saw lots more of the same.  Add to that the development community who will throw their collective weights behind the platform, and you’ll see real traction.

Does the Silverlight UI framework suck?  Maybe.  But it doesn’t matter.  If it’s really that bad, it won’t take long for the development community to provide one that rocks.

We see the same thing every day in the Flex community.  Hate Cairngorm?  Meet PureMVC / Mate.  Not a fan of <some 3d API>, not a problem — we’ve got 3 or 4 alternatives waiting just around the corner.

But — all of these frameworks share the same lowest common denominator — the Actionscript language.

And, it’s a little embarrassing to tell my .NET mates that mid 2009 the Flex community is getting support for typed arrays.  (Woot!)

I might be wrong, I’ve had limited exposure to Silverlight, but from what I understand the language is boasting some pretty impressive .NET features…

  • Typed Arrays
  • Generics
  • A decent reflection API
  • Dynamic Compilation
  • Abstract classes
  • Threading
  • LINQ / Lamba expressions
  • All sorts of C# 3.0 / 3.5 goodness!

Fire up Silverlight, and you’ll get all these things out of the box.  Today.  Right now.

For that matter, if you don’t like the language, you can write your own!  (IronPython, IronRuby)

And, by the time that Flex 4 and our typed arrays make a release, you can expect that C# 4.0 & VB10 will be boasting some funky new features in early preview.

Sure, Flex is an extremely powerful framework…today….comparatively.

But .NET is an extremely powerful language.  And where there’s a language, there’s developers.  And, where’s the developers, there’s eager minds….filling gaps in markets, plugging holes, and pushing boundaries.

Don’t get me wrong.  I think that Adobe are kicking ass with Flex.  In fact, had they not done such a good job, Silverlight probably wouldn’t be the contender it is.

And — come to think of it — Adobe are doing one helluva job in including the development community in guiding where the framework is headed.

So maybe it’s out fault.  Hell – maybe, it’s just me.  Maybe the community really does want a better designer / developer workflow over and above the ability to mark a method as abstract.

But I worry that while we’re getting swanky new ways of integrating designers and developers, the Microsoft team are giving their developers ways to achieve more powerful products with less code.

And, if Paris Hilton has taught us anything, it’s that looks can only get you so far in this world!

I just hope I haven’t backed the wrong horse in this race!

I just stumbled across a little type conversion quirk within Flex. I haven’t tested this in-depth, so I may yet be proven wrong.

However….check this out:

var someVal:string = “true”;
var bool:Boolean;
bool = someVal as Boolean; // bool == false;
bool = someVal; // bool == true;

If you try to explicitly cast a string to Boolean, the casting appears to fail silently, leaving the Boolean with its default value of false.

However, if you leave it to the runtime to convert, the conversion works fine.

Ya learn something new every day!

billboard_feed_128x128.pngI just got the email, that I’ve been aggregated on MXNA. HOORAH!

I gotta admit, that I thought this would never happen, after Ryan Stewart punked us all with his april fools post.

I personally am a huge fan of MXNA, and read it several times a day. The bloggers whose posts are a part of the MXNA herd are all outstanding, so I’m amongst some fine company!

Note to self : Must actually post blogs now…

An important part of a good test suite is repeatability, and independance from external changes. Therefore, if your method loads data from an external source, that’s a real testing no-no.

However, using the features of dynamic classes in AS3 we can whip up a mock webservice which gives us a guaranteed result, every time.

Here’s the class:

package com.martypitt.testing.mockObjects
{
    import flash.utils.Dictionary;
    import flash.utils.flash_proxy;

    import mx.core.Application;
    import mx.core.mx_internal;
    import mx.messaging.messages.AsyncMessage;
    import mx.messaging.messages.IMessage;
    import mx.rpc.AbstractOperation;
    import mx.rpc.AsyncToken;
    import mx.rpc.events.ResultEvent;
    import mx.rpc.soap.WebService;

    use namespace flash_proxy;
    use namespace mx_internal;

    public dynamic class MockWebService extends WebService
    {

        /** The default response is returned if a call is made to a method that has not been explicitly
         * set using setResponse() */
        private var _defaultResult:Object;

        /** Determines bevahiour if a call is made to a method where the response has not been explicity set.
         * If true, an error is thrown.
         * If false (default) the defaultResponse is returned.
         * */
        private var _throwErrorIfResultNotSet:Boolean = false;

        private var _resultDictionary:Dictionary = new Dictionary();

        public function get defaultResult():Object {
            return _defaultResult;
        }
        public function set defaultResult(value:Object):void {
            _defaultResult = value;
        }

        /** responseDictionary holds a list of predefined methods and their associated responses.
         * */
        protected function get resultDictionary():Dictionary {
            return _resultDictionary;
        }
        protected function set resultDictionary(value:Dictionary):void {
            _resultDictionary = value;
        }
        public function get throwErrorIfResultNotSet():Boolean {
            return _throwErrorIfResultNotSet;
        }
        public function set throwErrorIfResultNotSet(value:Boolean):void {
            _throwErrorIfResultNotSet = value;
        }

        public function MockWebService(destination:String=null, rootURL:String=null)
        {
            super(destination, rootURL);
        }

        /** callProperty is called by the Flex / flash framework when something tries to access
         * a method or property of a dynamic object which has not been defined in code.
         * Here we override the default behaviour to return the correct response.
         * */
        override flash_proxy function callProperty(name:*, ... args:Array):*
        {
            var response:Object;
            var methodName:String = getLocalName(name);

            switch (true) {
                case (_resultDictionary[methodName] == null && throwErrorIfResultNotSet) :
                    throw new Error(String(methodName) + " does not have an appropriate result set.");

                case (_resultDictionary[methodName] == null && !throwErrorIfResultNotSet) :
                    response = defaultResult;
                    break;

                case (_resultDictionary[methodName] != null) :
                    response = _resultDictionary[methodName]
                    break;

                default :
                    throw new Error("Unhandled switch case scenario in MockWebService");
            }

            var message:IMessage = new AsyncMessage()
            var token:AsyncToken = new AsyncToken(message)

            // We want to return the Async token now (just like a normal webservice would)
            // but we get the app to dispatch the ResultEvent on the next frame

            // It's important that the result event is dispatched from the operation itself.
            var operation:AbstractOperation = super.getOperation(methodName);
            Application.application.callLater(operation.dispatchEvent,[ResultEvent.createEvent(response,token,message)]);
            return token;
        }

        public function setResult(methodName:String,responseValue:Object):void {
            _resultDictionary[methodName] = responseValue;
        }

    }
}

Nothing overly swanky, but all the magic happens courtesy of this line :
override flash_proxy function callProperty(name:*, ... args:Array):*

This method gets invoked whenever you call a method on the class which has not been defined in code. We catch the call, and generate an Async token that makes the caller think that we’re busily off chatting to our webserver.

The other key line is this:
Application.application.callLater(operation.dispatchEvent,[ResultEvent.createEvent(response,token,message)]);

In essence, we’re just dispatching a result event here. But, because our method is called syncronously, and webservices behave asyncronously, it’s important that we dispatch the event on the next frame. Hence Application.application.callLater.

Also, the result event must come from the operation itself, not our mock service, so that whoever has called this method gets notified of the result event, just like they would if it were a normal webservice.

So, with all that done, we simply set up the webservice, and invoke it:


var result:XML = new XML();
var ws:MockWebService = new MockWebService();
ws.setResult("callMyRemoteMethod",result)
someClass.webservice = ws;

It’s important (and good design practice) that you expose the webservice on your class as property that can be modified at runtime.

That’s pretty much it.

Questions and comments welcomed.

Marty

Although there’s a bunch of cool plugins out there for formatting code, for those of us too cheap to host our own wordpress blog, options are limited.

Luckily, there’s a handy javascript app over on blogger which gives us some clean markup to paste in.

Checkit:

http://formatmysourcecode.blogspot.com/

I’m a fan of unit tests. And, although I probably wouldn’t blazen it across my chest like some, I am sold of the benefits.

However, coming from .NET, I miss quite a bit of the elegance present in NUnit when working with FlexUnit.

Most specifically, the setup of a test suite is kinda clunky.

Normally, you have several classes of unit tests, each which have a static suite() method, returning a test suite comprising the unit tests in that class.

Check out the following example:



 public static function suite():TestSuite {

    	var ts:TestSuite = new TestSuite();	   	ts.addTest( new MyTestClass("testMethodA") );

    	ts.addTest( new MyTestClass("testMethodB") );

    	ts.addTest( new MyTestClass("testMethodC") );

    	ts.addTest( new MyTestClass("testMethodD") );

    	return ts;

 }

As you can appreciate, it doesn’t take long for this to get long and clunky. Also, maintanence is a pain in the butt — adding tests don’t get run if you forget to add it in the Suite method, changing names causes RTE, etc etc etc.

In NUnit (and, presumably JUnit), you just decorate a class with [TestFixture], and a method with [Test], and NUnit takes care of the rest using that groovy cat, Reflection.

Luckily for us, Flex gives us the ability to tell the compiler to retain custom metatags in Flex 3. This means we can achieve similar functionailty — at least at the method level.

The first step is to set the compiler option. In Flex Builder 3, right click your project, hop into Flex Compiler, and add this to the list of compiler options:

-keep-as3-metadata+=Test

Then, using flash.utils.describeType() we can find any methods within a class that are decoared with our [Test] method.

The following method examines a class, and returns a TestSuite which contains a test for each decorated method.

        /**

         * Generates a test suite with all the methods in a class decorated with [Test] metadata

         * @param clazz

         * @return

         *

         */

        public static function fromClass(clazz:Class):TestSuite {

            var suite:TestSuite = new TestSuite();

            var testMethodNames : XMLList = describeType(clazz).method.(metadata.(@name==”Test”)).@name

            for each (var node:XML in testMethods) {

                    var methodName:String = node.value()

                    var test:Test = new clazz(methodName);

                    suite.addTest(test);

            }

            return suite;

        }

Personally, I chose to add this to the TestSuite class in FlexUnit, though you may prefer a seperate util class.

Now, getting all the tests for a class is as simple as:

var suite:TestSuite = TestSuite.forClass(myClass);

Much more readable!

Comments welcomed.

Marty

Update : I modified the disvoery method to use the E4X expression suggested by Theo. I must’ve been having a brain-fart at the time, as I’m a huge fan of the E4X syntax. Nice spotting Theo!