However it is still going strong and a couple of things prompted me to release this update to bring it to v1.2.1.

The first thing was Tom Hirashima (sorry Tom, wasn’t sure if you have a site you want me to link to) sent me an email last week with an update to the code to allow it to work with the latest versions of Prototype & script.aculo.us out of the box (1.6.1.0 & 1.8.2 respectively). Although the last time I tried the cropper with the latest versions of them both it worked fine, you just had to change the bundles that script.aculo.us included, Tom has made some further changes. This is a good thing as for the past couple of years I’ve pretty much been out of the prototype & script.aculo.us loop having moved to MooTools and now jQuery (which I hated at first, but that’s another story).

The second thing was that the cropper was mentioned (and my how old does this site design look to me now) in the latest (and as usual excellent) Railscast, Cropping Images.

As a part of integrating Tom’s changes I decided to tackle a load of bugs from the bug list to try and reduce the list so I can keep on top of it better going forward (a long list of open bugs is never conducive to getting any of them fixed).

Here’s a full list of the changes:

• Added support for latest versions of Prototype & script.aculo.us (1.6.1.0 & 1.8.2 respectively). Changes provided by Tom Hirashima.
• No-longer package prototype & script.aculo.us with the release
• Changed tests to use google ajax libraries API to load prototype & script.aculo.us
• Added option to not auto include the cropper CSS file
• #00008 – Fixed bug: Dynamic include of cropper CSS expected cropper.js and failed when using cropper.uncompressed.js
• #00028 – Fixed bug: Doesn’t work with latest script.aculo.us – Fix by Tom Hirashima
• #00030 – Fixed bug: Doesn’t work in Firefox 3.5 (CSS include issue)
• #00007 – Fixed bug: onEndCrop isn’t called when moving with keys
• #00011 – Fixed bug: The image that is to be cropped does not show in IE6.0 — included CSS fix
• Tidied up source code & fixed issues that jslint found so it will compress better

Finally as usual, please use the bug reporting link or discussion list mentioned on JavaScript Image Cropper UI code page rather than leaving comments to report bugs.

Head over to the JavaScript Image Cropper UI code page for download and documentation.

Advertisement: JavaScript Image Cropper UI Download my feature-rich JavaScript Image Cropper.

M: I was thinking about the event.setArg() method, and thought it would be nice if you could have it set the variable to session or cookies within the same call, e.g. event.setArg(‘name’,'value’,true,true), what do you think?

Me: I see what you’re thinking, but I don’t like it. I think that your code should be clear to you and others what it is doing and those true arguments don’t give you much insight into what they’re doing.

You’ve got to think about someone else coming to maintain your code, would they be able to see what it was doing without digging through to find the definition of event.setArg()?

Also how many times will you use it, and if not many, will you have to check the definition yourself to remind you which one is setting the cookie and which the session next time you see it?

So in the end I proposed 3 methods, the original setArg() method and two for setting cookie values & session values, basically a couple of cookie and session façades, and I think that’s what he went for in the end.

In my view the few times you’d want to set the same value to cookie and or session is very rare and the following example shows the worst case scenario where you want the value in all 3 places:

event.setArg( ‘myArg’, myVal );
cookie.set( ‘myArg’, myVal );
session.set( ‘myArg’, myVal );

It’s not the driest piece of code, but in my opinion much better than being presented with event.setArg(‘myArg’, myVal, false, true).

So that brings me to the title of this post, “Coding Clarity Over Cleverness”, the example with the extra façades for the session & cookie can’t really be any clearer in my opinion, it’s not the cleverest or driest solution but as far as readability and future maintenance in my opinion it’s much better. Presented with that code you probably wouldn’t even dig into the documentation or code to see what cookie.set() and session.set() are doing as it’s pretty clear.

The clarity over cleverness argument goes for any coding situation, you might hide some really clever code behind a method or function, but it’s name and signature should clearly show what it’s doing.

So the next time you come up with a clever solution, ask yourself if it’s clear what the code is doing if not then re-factor it so that it is.

The key changes are:

• Release has two downloads – one compiled to Flex 2.0.1 and one to Flex 3 – as it appears changes to Flex internals meant you couldn’t use the Flex 2.0.1 compiled swc in a Flex 3 project.
• Fixed: Issue where error thrown when no test results selected.
• Fixed: Issue where resizing columns could cause the itemRenderer for the status to display horizontal scrollbar.
• Added: Ability to choose whether to display test results live or wait until all tests complete (as displaying them live results in slower execution of tests, as it’s constantly updating the UI) – this is saved as a preference.
• Added: Ability to toggle display of the class path for the test case – this is saved as a preference.
• Added: Test result details now extract Expected & Was from message string for failures and display in a manner that is easier to compare.
• Changed: Test details now displayed on change rather than click event, to allow keyboard navigation of test results.

Head over to the FlexUnit Test Runner code page for all the downloads and to see the updated demo.

Which also means we’re one step closer to releasing it.

Which also means I’m one step closer to being able to tell you all about it, ohhhhh it’s so exciting!

• Fix as many bugs as possible, if not all.
• Add a couple of new features to the base cropper.
• Core architectural changes to improve flexibility of the cropper, read alternative framework support.
• Improved documentation and support network.
• Improvements to maintenance and updates, read more regular updates.
• Any performance improvements that can be made (a fresh look at the code always seems to reveal areas that can be improved).

Over the past couple of evenings I have documented and investigated my plans and the architectural changes that I would need to implement to take the cropper to the next level and these have provided me with a rough timeframe for completion of V2.

However I am incredibly busy at the moment and other commitments are taking priority, but I also do not want the cropper codebase to stagnate as I understand the popularity of the cropper — it’s the main traffic driver on my site and has had nearly 32,000 downloads so far and is averaging over 1,000 per month.

But as I say my other commitments are taking priority and a lot of my spare time, so I thought I would try an experiment, fund raising.

Why fund raising?
Firstly I must state that this is not about the money, if it were I would not release my code for free (and this will continue for version 2 of the cropper). But it is the only thing I could think of that could give me a clear indication of the desire for an updated version of the cropper. It is all well and good having the odd comments praising the cropper and/or mentioning the desire for feature x or bug fix y, but it is something different to put your money towards achieving that.

So far the cropper donation ratio is about 0.04% of all downloads result in a donation (that’s 14 donations out of around 32,000 downloads), so the fund raising activity should really test the reaction of the version 2 plans — thus the target figure I’ve entered and the timeframe are not as important to me the reaction.

So when will version 2 be released?
That is partly down to the results of the fund raising, I do seriously want to implement all my plans, but whether that’s this month, next month, next June etc. I cannot specify right now due to my current commitments, all I can say is that if the reaction to the fund raising is successful then it will help me prioritise the cropper appropriately and will result in version 2 being released sooner rather than later.

Okay, enough of the sales patter, how do I donate?
I’ve setup a campaign on Pledgie, which you can use your existing PayPal account (or credit card if you don’t have a PayPal account) to make a donation.

I look forward to your help and support and the changes that V2 will bring to the cropper.

I have used unit testing in a few different languages, so obviously when I started using Flex I wanted to start off on the right foot by using unit testing from the outset. However after a couple of days using the base runner which is provided with FlexUnit I found myself spending a lot more time than I thought I should just looking for the details of the problem in the flex runner.

So as usual I attempted to make something that would work a little better for my requirements, see the FlexUnit Custom Test Runner code page find the full details and the download. As usual any comments should be made on the code page.

I didn’t have time to look at a work around during work hours as it really isn’t a feature that is needed of our product, just something that annoyed me. So I decided that I would quickly knock a solution together at the weekend and then write up a short post of how it was done, in case other people wanted to find out how to do it.

However it didn’t quite work out that way.

After a few frustrating hours I managed to get a fully working solution which I thought I’d share. You can read on for the story behind the component, or you can head straight to the FoxyComboBox code page to view the results.

So I sat down late Saturday afternoon and started poking through the source code for the ComboBox and its related classes (god bless Adobe for providing the source). I noticed that the listBase class (which the ComboBox uses for its drop down) has a method in there already to find an option by string, "fantastic this will be a doddle", I thought.

So I figured all I needed was to created an new List which overrode the keyDownHandler so we could build up a string to use as the search criteria (and reset it during a period of typing in-activity). Then it would be a simple case of using the new List as the dropDownFactory by extending the ComboBox.

That took a while to figure out after looking through the source code, but not that long to implement – and it worked, except for one problem: it only worked while the ComboBox option list was open.

This didn’t make much sense, a bit of debugging and a lot of "Huh, why would it do that?", it seems the ComboBox gets a new drop down every time we try and change the selected index, unless the user has opened the drop down and selected an item. This wasn’t going to work.

So my next attempt was to turn it on it’s head, make the ComboBox the controller for this functionality, this isn’t the best solution (in my opinion) but it was the only workable one I could think of.

A bit of refactoring later it worked, except now whenever the drop down was open and the user typed it would close as soon as we changed the selected index. This made no sense, the normal ComboBox wasn’t doing this and I was calling the same findByString() method to select the item. I spent a bit more time digging through the source code and in the debugger trying figure out where it was being closed and why.

It turned out (and I had seen this earlier but glossed over it) that the keyDownHandler() in the ComboBox was setting a private property called bInKeyDown which if true stopped the dropdown_changeHandler() method from closing the drop down. Phew, that was a whistle stop tour of the inner workings of the ComboBox, hope you’re still following along.

So I had to hack around further to emulate this functionality in as clean a way as possible in my custom ComboBox, as bInKeyDown is private. I did something very similar, but made my variable a bit more generic and protected rather than private – just in case I want to extend the FoxyComboBox later.

A bit of refactoring later it worked.

So what I thought would be a quick half an hour job turned out to be about 4 1/2 hours work and a new code release from me (as I don’t want anyone else to have to suffer with this issue, either the end users of Flex or a developer digging through the ComboBoxto make a custom version with this functionality).

So if this is something you wish your Flex application could do, you can grab it now, I called it the FoxyComboBox (not very inspired, but my brain was a little fried by the end of it).

p.s. Those of you who have downloaded something of mine before will notice I’ve introduced a download page where I ask for a tip and give a suggested amount. In the case of the FoxyComboBox that is a measly $2, so I ask if you download it and find it useful please consider if saving yourself a few hours of time is worth $2, or maybe more :). Okay, that’s the begging over with, enjoy.

So using the XML language file as a base I quickly knocked one together.

The story all begins when I took over the Coldfusion platform support for, I started to find myself spending a bit of time watching cfstat on the servers to get a feel for the current status of the machines. As we had multiple servers (then 4, now 6) and only being able to get to cfstat directly on the machine, this was not really practicable.

What I really wanted was a little desktop application that could give me the headlines of cfstat for as many servers as we had, all in an easy to digest format, the result is the CFStatShot Yahoo Desktop Widget.

Today I received this message:

I think someone's trying to say I'm old.