Reorderer components' name change

Michelle D'Souza michelle.dsouza at
Wed Sep 24 20:23:34 UTC 2008

This strategy makes sense to me. I think if we do this for 0.5 then we  
should leave both the options in and in 0.6 beta move to the separate  
file for the old API. So here are the options that I see:

1. Wait until after 0.5 is cut to update the wiki.
2. Update the wiki but don't update the code
3. Update the wiki and code leaving the old API in place
4. Update the wiki and code with the old API in a different file

My vote is for option 3.


On 24-Sep-08, at 3:47 PM, Anastasia Cheetham wrote:

> On 24-Sep-08, at 3:30 PM, Colin Clark wrote:
>>>> An alternative approach would be to provide an optional JavaScript
>>>> file that offers backwards-compatibility for such API changes. This
>>>> is very much inspired by John Resig's approach to API change in
>>>> jQuery.
>>> Hm. I'm not sure I understand what this file would contain - the old
>>> APIs wrapped around calls to the new APIs?
>> Yep, that's exactly what I'm thinking. Adapt the new API back to the
>> old API for those who aren't ready to make the switch.
> Ok, I think I like that option. Users don't have to change their code
> to keep it working, but they *do* have to do the small task of adding
> the 'compatibility' file to their HTML, a la
>     <script src="0.4compatibility.js"/>
> which has in it things like (waaay overly simplified)
>     var lightbox() = function () {
>         return reorderImages();
>     }
> I like the idea that they would have to do *something*, as a small
> encouragement to upgrade :-)
> -- 
> Anastasia Cheetham                   a.cheetham at
> Software Designer, Fluid Project
> Adaptive Technology Resource Centre / University of Toronto
> _______________________________________________
> fluid-work mailing list
> fluid-work at

Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto

More information about the fluid-work mailing list