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.

Uploading files with Flex
To upload files with flex you need to use either the FileReferenceList classes, the main difference between these two is that FileReference is for uploading single files and FileReferenceList allows multiple file uploads.

Issue 1: How to send other data, such as meta/model data with the file upload:

Say you want to upload an image and save that using Rails along with other model data for that image (such as a title etc.) then you’ll have to hack that into the request that FileReference sends.

This Adobe tech note recommends using the uploadDataFieldName argument of the upload() method, however to me this seems like a really awful hack as you’ll then have to parse the name/value pair string in your uploadDataFieldName param at the backend. What you really want is separate parameters (ideally within the POST body).

The only viable solution I could come across was using the query string to pass the parameters through, your mileage may vary on this depending on the parameters you are sending, but I’m pretty sure that no modern browsers enforce the 255 character limit on a URL anymore.

Issue 2: Session cookie not sent in Firefox:

This problem is explained really well over at Thanks Mister!, it may apply to other browsers (probably the other gecko-based browsers work the same) but quite simply it means that if you’re relying on some data in your session during the upload you need to manually pass the session cookie through, however this raises further issues with Rails, so I’ll break it down further.

Issue 2: Part 1 — Passing the cookie when uploading files with FileReference:
It’s fairly simple to get around this part of the problem, you just need to include your session identifier within the query string, the biggest issue with this is getting the cookie value — as Flash doesn’t have native access to the browsers cookies.
To get the cookie you’ll need to use the ExternalInterface to call some JavaScript to retrieve the cookie, this is covered quite nicely in this post. So when working with Rails we just need to retrieve the cookie that lives in whatever we’re using as the session ID and pass that through via the query string, but that brings us to another problem:

Issue 2: Part 2 — Rails won’t let you pass session ids in the query string:
So now we need to tweak Rails to let us pass the session id via the query string, luckily there is another great post on this, however some of the Rails 2 security improvements require further workarounds which are in the comments on that post.

To quickly cover what you need to do is as follows:

1. Add the patch (make sure you get the one for Mongrel/Apache linked at the bottom of the post) to the CGI::Session class to your application — it really deserves to live in a plugin rather than the environment.rb file, which you’ll have to roll yourself.
2. For Rails 2 you have to add another override by adding session :cookie_only => false at the controller level. I personally feel it is best to do this in just the controller that you’re using to upload the files with.
3. I still had issues with it not picking up my session — I was using the Rails 2 default of saving the session information in the cookie. There is probably another hack or change that I could make to get around this, but I chose to move (back to) Active Record sessions but this time using the Fast Sessions plugin for a bit of a performance boost.

   I’ll probably look into this again at a later date, but right now I just wanted to get this part working and move on.

So now we’ve got our file uploading to the backend, within our session and our other model/meta data being sent as well. “Great we’re done, what else could go wrong now?” is just the kind of thought you’d be forgiven for having. Of course there was another issue that came up which needed to be handled.

Issue 3: Attachment_fu and Flex file uploads

FileReference uploads all files with the MIME type of application/octet-stream which gives us a couple of problems:

1. Your attachment_fu content-type filter will probably reject all uploads out of hand – the easy hack would seem to be to add in the application/octet-stream to your acceptable content-types, but that’s an awful hack that basically removes the content-type filtering and doesn’t address our second issue.
2. If using attachment_fu to create thumbnails and you do accept the application/octet-stream MIME then you won’t have any thumbnails generated, because as far as attachment_fu is concerned your upload is not an image.

Again the solution was only a few searches away, and the changes covered in this post over at Vixiom Axioms do fix the issue — although note that I had issues with that fix and had to apply my own changes – see the comment on that post.

Conclusion

So finally we have file uploads working from Flex to Rails, our session information is maintained, we’re passing along our model data and our images are being handled as they are supposed to.

This really shouldn’t have been this difficult, it should have been a simple case of using FileReference add some data to be POSTed and we’d be done but alas decisions made in/or issues with the Flash player lead to this merry dance of hacks, tweaks and workarounds to make everything sing to the same hymn-sheet.

Hopefully covering this and collecting together these links will save someone else from a wasted day of figuring out the solution to the myriad of problems that I encountered.

Previously I’ve used query strings parameters within asset requests so that they act as a ‘cache bust’ parameter, these have usually been the source control revision number and is built into the release process. But I’ve never taken the step of force an expiry date on content that can be cached and the solution in the post is a lot more fine grained than my previous solutions. Something to consider for the future.

• 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.

If you’re not aware what Firebug is, the official site quote is:

Firebug integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

But that doesn’t explain just how excellent Firebug is, it is by far and away not only the most complete debugging plugin I have found for any browser, but it also seems to be one of the most complete and professionally executed Firefox plugins around.

I cannot bear to live without it, especially when I am working in JavaScript, so the lite version goes some way to ease the pain when working in other browsers by providing a similar console for dumping information to. Until I found the lite version recently I had a workaround function that either used alerts or my own debug console (which I’m not linking to as I am contemplating dropping from the site) in other browsers to ensure that the code still worked and provided some useful debug information, now I no longer need that work around.

I still long for a real cross browser version of the full Firebug feature set, but I’m pretty sure that would be a lot of work for some of the browsers.

cross trainer

However my previous experience with unit testing JavaScript haven't been the most pleasent, I have tried the most common nUnit variations for JS, the best of which was JSUnit. But I always found this a little cumbersome and difficult to use, however I had recently read about the unit testing available with script.aculo.us and although the only documentation I could find was the PDF available at mir.aculo.us I thought I'd give it a go.

My only worry with using the script.aculo.us unit testing was its dependency on prototype and script.aculo.us (obviously) and now I've moved across to mootools for most things I thought there may be some clashes between prototype and mootools for this.

However with the current versions of each of those I managed to get everything working by changing only two lines in the unittest.js:

to

The script.aculo.us unit testing framework is very fast (one of my tests performs 16 tests with 1904 assertions in about a second) and it does a great job of catching scripting and syntax errors and presenting those in a useful way without breaking the tests, which some frameworks I've used in different languages don't always handle too well.

The only let down is the current level of documentation, but if you've looked at unit testing in any other language this is almost the same and you can figure out what most of the assertions do from reading the PDF and looking at the source. The only minor niggle is the need to use the

syntax for all your assertions, I haven't found an explanation for why this is needed within each of the test methods and why it can't be hidden from the user, but you need it otherwise it won't work.

I haven't looked at using the functional tests available within script.aculo.us yet as it's still at a very early stage and I'm not sure whether it's needed as I think I can do everything I need right now with unit tests. I hope to write more about specific examples of unit tests, e.g. complex ones which require DOM manipulation or user interaction etc., in JavaScript when I have some decent examples in place.

I really like the completeness of this script, how it handles the node elements and the cross browser support. I've not tried using it in development yet and I doubt it would replace my console.log() calls in Firefox when using Firebug, as that offers so much more, but for the poorer members of the web browser family (poor little IE) I can definitely see it coming in handy.

This adds quite a few bugs fixes, feature additions (the much requested ability to set maximum dimensions) and speed improvements and general streamlining.

NOTE: One really important change to note is that the cropper no longer has the default behaviour of automatically setting a ratio when both min width & height passed, the ratioDimensions must be now passed when this functionality is required.

Here's a full list of all the changes:

• Added id to the preview image element using 'imgCrop_[originalImageID]'
• #00001 - Fixed bug: Doesn't account for scroll offsets
• #00009 - Fixed bug: Placing the cropper inside differently positioned elements causes incorrect co-ordinates and display
• #00013 - Fixed bug: I-bar cursor appears on drag plane
• #00014 - Fixed bug: If ID for image tag is not found in document script throws error
• Fixed bug with drag start co-ordinates if wrapper element has moved in browser (e.g. dragged to a new position)
• Fixed bug with drag start co-ordinates if image contained in a wrapper with scrolling - this may be buggy if image has other ancestors with scrolling applied (except the body)
• #00015 - Fixed bug: When cropper removed and then reapplied onEndCrop callback gets called multiple times, solution suggestion from Bill Smith
• Various speed increases & code cleanup which meant improved performance in Mac - which allowed removal of different overlay methods for IE and all other browsers, which led to a fix for:
  • #00010 - Fixed bug: Select area doesn't adhere to image size when image resized using img attributes
• #00006 - Removed default behaviour of automatically setting a ratio when both min width & height passed, the ratioDimensions must be passed in
• #00005 - Added ability to set maximum crop dimensions, if both min & max set as the same value then we'll get a fixed cropper size on the axes as appropriate and the resize handles will not be displayed as appropriate
• Switched keydown for keypress for moving select area with cursor keys (makes for nicer action) - doesn't appear to work in Safari

Phew!

Actually all of this was pretty much wrapped up in the first couple of weeks of October, but being as anal as I am I didn't want to remove a bug fix that I had in place and working perfectly in Firefox but which went crazy in IE and Opera (hence my last post). That fix was having some overflow CSS properties on the wrapper around the image to which the cropper is applied to, the fix and test page worked perfectly if Firefox, but not in IE and Opera. The fix is still
in place, but the test page is not - I may re-address this in the future.

Finally as usual, please use the JavaScript Image Cropper UI code page to leave comments & bug reports etc. on the cropper UI.

I've not had the time to play around with MooTools yet, but simply looking at the help page you can't deny that it looks sweet.

"OK" you may say to yourself, "it doesn't look like there is anything too new in there". Well even if it were just the really nice syntax changes, such as when extending classes:

Which is a lot more intuitive and concise than the current method offered in Prototype:

I'd be happy to recommend MooTools on those improvements alone, intuitive and concise is always the best combination when it comes to programming languages as far as I'm concerned, but there is much more:

• OO inheritance, allowing you to call methods on the parent object when extending objects.
• Using the $ function to extend elements with the Element methods.
• Defining custom methods on elements.
• Powerful yet simple effects.
• The full release (when the compressed option is chosen) is around 20kb, consider that the latest version of Prototype alone is 53kb and when compressed (with the fabulous Dojo Rhino compressor) is still 36kb. To work around the large size of Prorotype & script.aculo.us combined I've had to break Prototype up into its component parts and then use a custom manager for managing script requirements (I plan to post about this in future once I've worked up a couple of examples); I mean who uses all the functionality Prototype offers at the same time?

Another of the potentially great things about the MooTools library is the FX themselves, I'm aware that Moo.fx has been around for a while, but the really great thing about Moo and is that it doesn't seem to try and do all the work for you. If you've ever taken a look at using the script.aculo.us dragables or sortables for anything that slightly differs from the test cases or examples you'll soon come a bit of a cropper, Johnathan Snook gives a good example of the simplicity and flexibility of the MooTools way of doing things in his post exploring drag and drop with MooTools.

I'm sure I'll have more to post about MooTools in the near future as I'm planning to use it as my primary JavaScript framework for my next large project, so we'll see if it lives up to expectations. For now I'll just share a few links that I've found informative so far:

• The MooTools help page
• Useful Utility Functions in mootools
• Extending Objects and Classes with mootools
• drag and drop with MooTools