Saturday, 27 December 2008

Flex MVC frameworks

Over the last two months, I have been involved in writing Flex code using the Cairngorm framework. It claims to be an MVC framework. On closer examination, Cairngorm provides an alternative event mechanism that focuses on the use of commands, a standard location for the implementation of services, and a set of development principles.

The Cairngorm framework encourages the use of singletons for:

  1. A front controller that is used to register commands and events that fire them,
  2. A service locator used to hold dictionaries to remote object, http service, or web services. The service delegates use this to locate the correct service object,
  3. A model locator used to gain access to the applications data model,
  4. A view locator that allows the location of views from commands if required, and
  5. An event dispatcher that dispatches events using Flash event mechanism.

The event dispatcher is behind the scenes as the programmer doesn't need to be aware of its existence. It is the only one of these singletons that is actually referenced by any of the Cairngorm code. None of the others actually need to be singletons.

The Cairngorm framework also recommends the defining of event classes for each event in the application. The primary purpose of the event class / object is to define the data to be passed to the command executed when the event is fired. An ICommand interface is provided to give a standard command type. A series of events can be chained together by defining commands that extend the sequence command class.

The view locator and view helper are provided so that reference back to view objects can be achieved if required in the application. A value object interface is provided for model value objects.

The basic processing structure us that user gestures are translated into Cairngorm events which are dispatched causing the associated command to be executed. The command causes the model to be updated. Through the data binding mechanisms, the view is notified of changes and refreshes.

The first impression when trying to use the Cairngorm framework is that all these singletons restrict the ability to test drive the code or to have multiple contexts within the application. Since none of the singletons are actually required by the framework, it proves easy to use the Cairngorm event mechanisms and the basic structure but not use all the singletons.

In my experimentation, in order to be able to test code using remote objects, I have mocked out the service locator and the associated remote objects. A little bit of exploring of the Flex SDK on the definition of remote objects showed that this is relatively easy to do. We use a application controller singleton to hold references to the front controller (register of events and commands), service controller, and the model. A façade class defines static functions that make it easier to use our code structure.

I have implemented an initialisation entry point for the application controller that allows me to define alternative front controllers, service controllers, and models. I have also implemented a method to destroy the singleton so it can be reset for a second set of tests.

With this structure, it is possible to inject test code to verify the correct firing of events, to trap service calls to verify that they are being set up correctly. So far, I haven't replaced model elements but that could be achieved as well. More importantly, through mocking out the services, it is possible to fire test data back into the application to verify its overall operation.

Instead of using the view helper and view locator, we have implemented our own notifier. This is not too different from Cairngorm events except that it doesn't restrict the number of receivers of the notification and the receiver can say what method to call when the notification is sent. With out notifier, we could discard the Cairngorm framework completely but we already had a commitment to its use.

Sticking rigidly to the Cairngorm conventions introduces a lot of redundant code. For example coding an event class for every event or the delegate structure for accessing services. We have eliminated the use of event classes but at this stage are still using delegates. Some code refactoring may see those removed.

For the views, we have defined a mediator actionScript class that extends the base class used for the view that it relates to. The mxml view file then uses this as its base tag thus from the perspective of the mxml making the actionScript class appear to be part of the mxml. The advantage of this is that we implement most of the code that carries out actions for the view in the mediator class. We can then test drive this free of the mxml components. I have endeavoured to enforce that the only way that the mxml view component can be updated is though the data binding mechanisms. In a sense, the mediator is a supervising controller (Fowler 2006).

We have also examined the PureMVC framework and concluded that like Cairngorm, the advantage of PureMVC is the conventions that it proposes rather than the specific code that it implements.
PureMVC suggests the use of:

  1. Views with associated mediators that sit between view and rest of system (our naming comes from here although I originally called them presenters),
  2. A controller and commands with both a simple command and a macro command (similar to Cairngorm's sequence command),
  3. A model accessed through proxy objects (The proxies provides access to remote data through services. Domain logic implemented in proxies),
  4. A façade that acts as the gateway to the application (Brokers requests to the model, view, and controller. Initialises the controller with command mappings. Uses commands to prepare model and view), and
  5. Observers and Notifications (These provide a publish, subscribe mechanism. Notifications trigger commands. Mediators send, declare interest in and receive notifications. Proxies send but do not receive notifications).

Again most of this is convention rather than requirement. The only real code in the PureMVC framework is in the observers and notification structure. The rest is primarily interfaces so that conventions are being followed.

The idea of both frameworks is to reduce the binding between views, the business logic, and the model. Cairngorm has chosen to use an event structure that restricts the events to firing one command. PureMVC has chosen to implement a more flexible notification structure. Both frameworks are quite small. The core components (the event or notification mechanism) can be implemented quite quickly by any experienced programmer.

My conclusion is that you should think carefully about what you want to achieve and the overhead introduced by using these frameworks. In my case, my objective was implementing the idea of a supervising controller and endeavouring to ensure the minimum amount of dependency in the code. I have already decided that I wouldn't use either Cairngorm or PureMVC on future projects unless mandated by the client. A simple notification mechanism and some careful coding conventions will serve my purposes.

Reference

Fowler, M. (2006, 19 June). Supervising controller. Retrieved 9 November, 2008, from http://martinfowler.com/eaaDev/SupervisingPresenter.html

Thursday, 25 December 2008

It's tough learning to trust

For almost two months now, I have been working with new colleagues and endeavouring to understand their abilities and hopefully, they have been learning about my strengths. It has proven difficult at times as we have each struggled to adapt to our role within the software development project. How much faith and trust do we put in another's abilities or do we keep checking to see whether they are doing what we asked and in the way that we wanted?

I used to have a boss, who I said I trusted not to do what was right for the department. That was a negative trust. If someone worked for me and I had that kind of trust then I would be suggesting that he looks at working somewhere else.

This process of learning to fit into an organisation and to trust my colleagues in a positive way has made me rethink what it means to trust God. Our colleagues don't necessarily do things the way that we expect. Sometimes what they do seems to be totally wrong but unless we want to do everything ourselves, we have to learn to trust them and focus on the things that we need to get done. Likewise God isn't going to operate in the way that we expect but if we don't trust Him, we will never understand what He has planned for us.

In Jeremiah 29:11, God said through Jeremiah, “I know the plans I have for you, plans to prosper you and not to harm you, plans to give you a hope and a future.” It certainly didn't look that way. Israel was going into exile in Babylon. The promised land seemed to being taken away from Israel. The question becomes are the plans that we have for ourselves the same plan that God has for us?

Through this adapting to a new work environment and new work colleagues, I have tended to reflect on how I might respond to those with who I am having difficulty. I form big elaborate strategies and then find when it comes time to carry them through that they no longer apply. Even this week leading up to this Christmas break, I was thinking that I needed to tell someone something only to discover that when we did meet that none of those things seemed important any more. I planned my responses but never allowed God to lead me in those situations. In effect, I didn't trust Him to lead me through even though we are confident that I am in this job because He put me here (but that is another story).

Last weekend, we listened to an Elvis Gospel CD. One of the tracks on that CD has been reccurring in my thoughts. “Lead me O Lord, won't you lead me. Lead me, guide me along the way. For if you lead me, I can not stray. Lord just open my eyes that I may see. Lead me, O Lord, won't you lead me.” This sounds a great prayer but... !!! The theology doesn't make sense to me any more. Do I really believe that God doesn't seek to lead me? Maybe the words of this song should be “Lead me, O Lord, yes, you lead me, yes, you lead me and guide me along the way. If I opened my eyes then I would not stray.”

Why do I have a problem with the theology? It assumes that we have to plead with God for Him to lead us. It assumes that this isn't something that He already wants to do and is trying to do. Remember, He knows the plans that He has for us. I have begun to see that when I pray for what God already is doing or wants to do in a way that asks Him to do it then I am breaking His heart, I am not trusting Him to live up to His promises. We have to learn to trust Him and act on that trust.

There is another song that we used to sing with youth groups. Its words went something like this: “Change my heart, O God, make it ever new.” “Make me more like you.” I can now see God responding “I'm trying, but you resist” or “Yes, I will but I don't think that you may like it.” The problem isn't that God isn't working to change us or lead us. The problem is that we have already decided where God should be leading us and what he should be changing us to. When it doesn't happen as we expect, we plead with God to lead us, guide us, and change us. Where is our trust that God is doing what he has promised and that he will make us what he wants us to be if we will let him.

As I write this, we are celebrating Christmas Day in New Zealand. A day on which Christians celebrate the birth of Jesus. As I have reflected on this issue of trust and God leading as he has promised, I have also thought about the number of times when I have been asked why God doesn't reveal himself to us. The thing is that He did and those who should have recognised Him rejected Him. Barclay in his commentary on the shepherds coming to see the infant Jesus (Luke 2:8-20) relates an interesting story. He describes a “European monarch who worried his court by often disappearing and walking incognito amongst his people. When he was asked not to do so for security's sake, he answered, “I cannot rule my people unless I know how they live.” (Barclay 1975). The monarch knew the importance of identifying with his people in their daily struggles. Being locked away in a palace didn't help him understand the struggles that they go through each day.

God in Jesus walked humbly amongst us. He shared in our struggles and understood our temptations. Each day he continues to walk with people who have learnt to hear his voice and acknowledge his leadership in their lives. He seeks a relationship with us. Instead of praying for God to make himself known to us or to walk with us, we need to learn to thank him for making himself known and walking with us each and every day. The transformation of theology makes a big difference.

As you read this my challenge to you is to look at your day and consider where you allowed God to lead and where you shut him out. Thank Him for doing as He has promised and apologise for when you have closed the door and locked him out.

Reference

Barclay, W. (1975). The gospel of Luke (revised ed.). Edinburgh: The Saint Andrews Press.

Saturday, 20 December 2008

FlexUnit revisited

On my current project, I have been working with FlexUnit and discovered that it will locate test methods in a class based on their name starting with test. I am using FlexUnit 0.85 since that is currently in the repository used by the Flex mojos.

In all the examples for Flex Unit, they show the use of a method that adds individual test methods to a test suite using 'addTest(new TestClass(“testName”).' This method to build the suite is usually placed in the test class (TestClass). In looking at trying to build a tree of test suites, I looked at addTestSuite method. Reading the documentation at the front of the class, it talks of adding a test class by using new TestSuite( TestClass ). This approach adds the test class as a suite by locating all methods that have names starting with test. This reduces the coding overhead and makes it easier to use.

FlexUnit 0.85 doesn't seem to report the suites in a tree hierarchy. This is rather frustrating as the number of tests grow. Flex Unit 0.90 does correct this but still lacks the use of attributes for identifying tests and some of the other features now in JUnit for Java and NUnit for .NET.

Sunday, 14 December 2008

Assertive tests

Continuing my review of unit testing frameworks, I have been looking at how you might evaluate the features. Some of the issues that I have looked at include:

  1. the way that tests are identified

  2. the type of standard asserts or comparisons provided

  3. the ease with which the assert framework can be extended

  4. the coding style of the asserts

  5. the ability to run the tests in different environments (i.e. the GUI, Ant tasks, and Maven builds)

I am sure there are other comparisons that could be done but I wanted a quick ability to compare the different frameworks. The focus of this blog is on the asserts supported by each of the frameworks. My assumption when I started working with these frameworks is that they would all support the common set since most are built on the JUnit framework. It seemed logical that all would provide the same asserts unless the language made one meaningless or there were new conditions that needed special handling.

So what assert conditions are supported by each suite?

Condition

FlexUnit

Fluint

FUnit

FluxUnit

Equals

4

4

4

4

Not equal

4

4

Object equals

4

4

Object not equal

Same object

4

Not same object

4

String match (1)

4

4

4

String no match

4

4

String contained

4

4

Not contained

4

String empty / not empty

4

4

Starts with

4

Ends with

4

Equal ignoring case

4

True

4

4

4

4

False

4

4

4

4

Null

4

4

4

4

Not null

4

4

4

4

Undefined

4

4

4

Not undefined

4

4

4

Fail

4

4

Instance of

4

Not instance of

4

Is finite

4

Is NaN

4

Is >

4

Is >=

4

Is <

4

Is <=

4

Collections

4

Asynchronous tests

4

(1) Regular Expression string match

It is possible to extend the asserts in all of the frameworks.

FlexUnit defines its asserts in a static class, Assert, that is extended by the TestCase class. This is simply so that the user doesn't have to type Assert.assertEquals().

Flunit defines its asserts as protected methods within the TestCase class. This has a similar effect to FlexUnit with respect to how the asserts are referenced.

FUnit uses static methods in an Assert class that is used by typing Assert.areEqual().

FluxUnit provides a mechanism for defining your own matchers. This is described in the documentation. These are referenced trough the expect().to(equal(), value) structure. The equal is a matcher. As well as the .to method, there is a to_not method. The biggest difficulty with defining matchers is understanding the dynamic function and class mechanisms used in Flux units programming.

If you are interested in maximum flexibility without having to extend the framework then FUint has the greatest range of predefined asserts. In this respect, it provides a good base for doing unit testing.