Sorting a paginated DataGrid

Ever had the problem of a paginated DataGrid only sorting on the page that is currently being viewed? Yeah, pretty useless I know. I needed the whole set of data to be sorted and a quick search on tinernet suggested quite a few other people did too. Unfortunately none of the blogs I read seemed to have the exact answer. So here is the full working solution – I did this quickly so it may not be perfect. The pagination was done using this chaps implementation so if you’re not using that the below bit of code may not make much sense. A little bit of inspiration was taken from stackoverflow.

After sorting the ArrData list I realised that the refreshDataProvider method doesn’t even use it and instead uses some source property which is an Array representation of the list. Amazingly this has to be sorted separately! I don’t understand why ActionScript has this “feature”.

Cairngorm: Tread carefully

A popular choice of framework when working with Flex is Cairngorm which has a nice tutorial to get you started. The reason I’m writing this blog is because of some code I came across recently. A developer had read the Cairngorm guide, taken it as gospel and then implemented it exactly. The only problem is that he wasn’t writing an application for an online shop which required a shopping cart. In particular the unnamed developer should have ignored the advice on the singleton model and in particular how one implements the IResponder interface.

The Cairngorm example is simple and the singleton model binding to your mxml pages is simple – it’s the quickest way to make Flex’s asynchronous behaviour work easily. If your application is a little more complicated then this simplicity becomes highly inflexible. To make my point a little clearer look at how the result method sets properties on the model.

Ok fine. But let’s imagine a user could have more than one shopping basket (unlikely I know but just to make my point). Or even better, what if your model had separate products for his and her shops. With this pattern you’re now stuffed because the model can only handle one set of products or one shopping basket. Yes, you could change the model so it can handle multiple sets of products, multiple shopping carts but that wouldn’t be the right way to fix the problem.

To overcome this inflexibility all you need to do is ditch the singleton model. Ok maybe don’t ditch the singleton model but only store truly global properties in it – the logged in user, a list of countries etc. Now how do you get your changes from an asynchronous service call to show up in your UI? Well without sounding too radical you could just implement MVC/MVP and pass the result of the event to you controller/presenter class.

I’m not entirely sure what Cairngorm’s Command classes are supposed to do. But my Command classes do virtually nothing and I let the Controller classes manipulate any result before setting it in the view.

Your controller class can then set the result on your mxml page (not very MVC but no bindings required) or you can bind the mxml page to a property on your controller class (the MVC way).

Why is this more flexible? The simple reason is that you have a Controller class for every mxml page. So if you 2 shopping baskets you have 2 ShoppingBasket controller classes. If you have his and her shops you have HisOnlineShopController and HerOnlineShopController – whatever granularity works best. It also stops you using the powerful but ultimately horrendous [Bindable] property on loads of properties in one class which every mxml page is looking at. In MVC the view should only be looking for properties where it needs to be – i.e. the controller/presenter that is handling the display of data in it. That way when you’re trying to find a null reference exception you only need to look at one mxml page (plus any nested pages) and one Controller class to work out where it is. I find this much better than putting a finger in the air and hazarding a guess as to which of the million [Bindable] properties in my singleton model is being set to null and which mxml page is bound to it.

And even better ActionScript is a functional language so it’s really easy to invoke a function after an asynchronous call finishes. Java can only achieve this by using interfaces which is not quite as neat (though the flow is quite clear).


Synchronise Events with Bindings in Flex

I have recently had to delve into the world of Adobe Flex and ActionScript and wanted to share some of my trials and tribulations with it. As I’m not a massive fan of Flash or proprietary technologies I had to assume the work had been assigned to me as a punishment for crimes committed in a previous life. In fact, 2 months in, I’m not entirely convinced what embedded Flash has to offer over conventional html and javascript – especially considering the features available in HTML5. “Meh” pretty much sums up my feelings for Flex – perhaps I’ve been doing too much Java.

Having previously been programming JSF I found Flex quite … different. One notable difference being it’s easy approach to the Observer Pattern with Bindings and another being it’s asynchronous behaviour. As JSF does not have any features comparable to these so this was all unchartered territory for me. In particular, I was experiencing some difficulty with asynchronous calls and the ViewStack. Basically the application was Single-Sign-On and I didn’t want the home view to show until they had been authenticated. Simple right? All you have to do is a bind a Boolean which is set by a CairngormEvent when authentication succeeds. Next problem was that there was some data to show on the home screen. But because every service call is asynchronous the screen would load with a blank area which would only be filled-in once the service call had completed. Well, what’s the point in showing a page unless it’s ready to be shown. I now have 2 conditions that must be true and ChangeWatchers seem to be the only thing that are going to help me.

A capability to synchronise asynchronous events is all I could think of to achieve the desired result. So I created a SynchronisedChangeWatcher class. WARNING – this is an over-engineered solution so I’m not sure if I would recommend using it:

And it’s usage:

So doStuff() will be called when both UserLoggedIn and _CreationComplete properties change – Simplz!