And I’m happy to say all three are ready to go.  Here’s a quick break down of what’s being released.  You can go to http://projects.sophomoredev.com for information about all three.

Effects

http://projects.sophomoredev.com/yui-gallery-effects/

I’ve always loved how you can quickly add slick animations in jQuery and other JavaScript library with a simple $("#elephant").fade() and other similar commands.  Now YUI 3′s Anim module can definitely handle a simple fade and a bunch more, but the code you have to write is a little verbose.  The “gallery-effects” module is meant to provide a simple framework and API for using the YUI 3 Anim utility that will allow you to quickly and easily animate nodes.  You’ll see that the framework and API are derived from Scriptaculous (heck, even the examples are taken from their documentation). The goal is to make animation with YUI as easy, if not easier, than with other JavaScript libraries.

In addition, I’ve tested this thoroughly on all Grade-A browser so it will “just work”

Lightbox

http://projects.sophomoredev.com/yui-gallery-lightbox/

Lightbox and it’s numerous spin-offs and in use all over the Web.  YUI 3 has great support for overlays and the widget framework is great, but no Lightbox yet.  So I’ve taken care of that with a literal port of Lightbox to YUI and plans to make it more flexible going forward (think non-image content, slideshow support, etc.).  Although if you’re looking for immediate slideshow support, there are some great module already available in the YUI 3 Gallery.

Data Storage

http://projects.sophomoredev.com/yui-gallery-data-storage/

Finally, although you never feel like you’ll need it, I’ve been constantly wishing YUI had support for data storage on individual nodes ala jQuery.  It feels like every jQuery plugin I look at uses it in some way and it’s just an awesome convenience.  Well no more, I’ve ported it to YUI so it can be used natively with Y.Node instances and any old JavaScript object.  Also, the YUI 3 Node class has begun to introduce support for this already, so all I really had to do was build on top of that.

Anyway, that’s all for today.  Definitely let me know if you have questions, issues, whatever.  I’ll document any progress on these modules as I go.  Also, if anyone has any suggestions for the best way to document code with examples, I’m all ears.  I felt it was a pretty painful exercise for this project, but I could just be complaining since my bracket was busted while I was documenting.

Just as a bit of context, I’ve been playing with Google App Engine recently and it’s been my first attempt at writing Python code. Python and Django? Love ‘em. App Engine? Eh, good at what it does, but I don’t really like working in Google’s sandbox. It just feels so restrictive. So for my next project I decided to skip the App Engine bit and try to build a site still using Django, but with a MySQL backend. Because of my work with App Engine, I already had installed Django and obviously Python 2.6 and 2.6 come with a standard Snow Leopard install, so I had those as well.

So from there I set off. The first thing I knew I would need was MySQL. I’ve used MySQL before, but since doing a clean install of Snow Leopard a few months ago, I hadn’t put it back on, so first to handle that.

Finding the binary installer for Snow Leopard was easy, but here I made a mistake.  I figured I’d install the 32-bit version which ended up causing me some headaches.  What I didn’t realize is that Snow Leopard installs most programs as 64-bit if your machine is 64-bit.  How do you find out if your Mac is 64-bit or not?  See this short post on how to tell from simply looking at your processor.  So I mistakenly installed the 32-bit version and was on my way.

The next thing you need to do is install a MySQL Python adapter.  The source for that is here.  I chose to sudo python setup.py build/install, but you could use easy_install if you want.  Once I installed, I tried to import the MySQLdb package and got the following error:

File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line 13, in
    raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)

This post and others indicated it was related to the build architecture of Python and MySQL. Bah, so this is when I realized I needed to go back and install the 64-bit version of MySQL.  Okay, so I downloaded the 64-bit installer and ran that.  (See further below how that worked, but not completely and I eventually did a clean install.)

Then I ran the following to try to re-install the MySQLdb adapter stuff:

cd MySQL-python-1.2.3c1
ARCHFLAGS='-arch x86_64' python setup.py build
ARCHFLAGS='-arch x86_64' python setup.py install

No dice, still not working. Poking through the comments of the post above, I came across this indicating that re-building doesn’t actually do it from scratch and you need to go into the build directory and manually rm *.  Once I did that, then I was in business — the import MySQLdb statement now worked.

Following the Django tutorial, I created by app, code-named “sanddollar.” So far so good until I got to:

python mange.py syncdb

and crossed my fingers. Forgot to create the database, but after that I still have a problem. I’m getting an error related to MySQL being able to create/write to a file:

File "build/bdist.macosx-10.6-universal/egg/MySQLdb/connections.py", line 36, in defaulterrorhandler
_mysql_exceptions.InternalError: (1, "Can't create/write to file '/usr/local/mysql/data/sanddollar/auth_permission.MYI' (Errcode: 2)")

This was a tough one.  It spawned this Stack Overflow question, but after some poking around I noticed that despite the fact I was able to create databases through the MySQL Workbench, they weren’t creating new database directories under the mysql/data folder.  My suspicion was that multiple installs on MySQL had gotten MySQL in a messed up state.  Solution: remove all traces of MySQL and then do a clean install.

This sounds pretty straightforward, but it wasn’t.  In the end, it took two sources (here and here) to get all the instructions for wiping MySQL where the second set of instructions is specific to Snow Leopard.  Alright, once I had done that, I used the same .pkg installer to install the 64-bit version of MySQL one more time.

Then I tried to connect to MySQL, and I get the following error:

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)

Fairly straightforward fix.  No idea where the actual mysql.sock file is, but because I could connect via MySQL Workbench over TCP, someone in the IRC channel tipped me off to run:

SELECT @@socket

which outputted the location of the mysql.sock file.  In my case, it was located at /var/lib/mysql/mysql.sock.  So then I ran the following from a bash shell:

$sudo ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock

and voila, now I can connect from Terminal.  Almost there.  I created a new user for the “sanddollar” database named “sanddollar” and granted the user privileges for basic CRUD operations at host 127.0.0.1 (for some reason localhost wouldn’t work).  Tried to connect through Terminal, worked great. Then tried the syncdb command again and this time paydirt.

Final thoughts: 32-bit/64-bit is complicated, more complicated than it feels like it should be.  This makes working with Snow Leopard as a development environment a pain.  However, I learned about the “file [filename]” unix command to determine the architecture of programs.  No idea what it means but opened it up on Stack Overflow with this question. In the end, not too bad for getting things started.  Feels like it could be simpler, but less than a day isn’t that bad, so onwards!

Consider the following page which includes both and then simple tries to style a number of elements on the page via an ID and class selector:

<!doctype html>
<html>
    <head></head>
    <body>
        <ul id="list">
            <li class="element">1</li>
            <li class="element">2</li>
            <li class="element">3</li>
            <li class="element">4</li>
            <li class="element">5</li>
            <li class="element">6</li>
        </ul>
        <script src="http://yui.yahooapis.com/3.0.0/build/yui/yui-min.js"></script>
        <script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.1.0/prototype.js" type="text/javascript"></script>
        <script type="text/javascript">
            YUI({ filter : "raw"}).use("node", "event", function(Y) {
                Y.on("domready", function() {
                    Y.all("#list .element").setStyle("border", "solid 1px red");
                });
            })
        </script>
    </body>
</html>

This seems simple enough, but if you try this in any version of Internet Explorer, it won’t work. After digging through the YUI code and using the fantastic step-debugger that is part of the IE 8 Development Tools, I figured out that the problem was that Prototype adds the getElementsByClassName method to the document object if it doesn’t exist and YUI uses the existence of that method as a proxy for whether that browser implements getElementsByClassName for both the document object and HTMLElement instances. So in this case, that check doesn’t quite work.

For now I’ve added “&& document.documentElement.getElementsByClassName” to that check in our local copy of YUI and filed a ticket against this issue.  Use this as an example that you need to careful when combining third party JavaScript libraries.  No guarantees they’ll play nice together.


Exception Type: ImportError
Exception Value: No module named PIL
Exception Location: /Library/Python/2.6/site-packages/django/forms/fields.py in clean, line 495
Python Executable: /usr/bin/python2.6
Python Version: 2.6.1
Python Path: [..., '/Library/Python/2.6/site-packages', '/Library/Python/2.6/site-packages/PIL']


Hmmm, a little stuck at this point. It’s clearly in my python path.  So I turned to my favorite programming resource, Stack Overflow, and posted this question.  Well, as it turns out there’s one thing I should’ve known and another more subtle detail.  The first, obvious thing was that of course if PIL is installed in my Python site packages, of course Google App Engine (GAE) can’t access it.  Maybe it could in my environment, but of course in production, I’m in a sandbox, so that’s definitely not going to work!  The second revelation was that PIL won’t work because it’s a C-based library and everything in GAE must be entirely Python.  So to remedy this, the GAE folks added an Images API.  This all makes perfect sense now, not sure why I didn’t see this immediately.

Anyway, problem solved.  The annoying bit here of course is that I wasn’t going to use PIL directly, but rather through the Django forms stuff.  Alas, that won’t work.  This is something I’m finding frustrating about GAE — namely, that I see cool stuff in Django and then can’t quite use it.  I guess that’s the price you (or I) pay for using GAE.  They can’t support everything, so I have to work within the supported subset.

Well, I use Eclipse and I’m sure others out there do as well, so here’s how to figure it out in Eclipse. First, use Ctrl+3 to pull up Eclipse search. I had no idea this existed, but man it’s awesome. More info on this awesome search here. It supports searching across Perspectives, Commands, Menus and more as well as the camel case search many of us have come to love from Ctrl+Shift+R. I searched for “delimiter” and it pulled up three commands that will take care of the line delimiters for the big three – Windows, Mac and Unix. Okay, that’s fine, but I want a shortcut. No problem. Just go to into the Preferences and look in General > Keys. Again, I typed delimiter, highlighted the appropriate command. I chose a short cut of Ctrl+Shift+D for delimiter, but obviously pick whatever you want.

Hopefully that little insight is helpful.

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>I can't believe this happens...</title>
</head>

alert("bialecki = " + bialecki)
} catch (e) {
alert("Error!")
}
</script>
</body>

The only other point is that if you “var” scope the variable, everything is fine and it behaves as expected, even though it’s still scoping the variable to the global/window scope.  So what’s the point? Always use the “var” keyword even if you’re not going to scope your variables.  Although you should do that too.

Anyways, the point of all of this is that I’ve been trying to weigh some of the pros and cons of the different libraries as we begin to think about where we should begin to migrate our code going forward.  I’ll devote another post to enumerating some of the differences I’ve found between those two libraries, but suffice it to say, I’ve seen awesome sites written with both, so I’m not too concerned that our choice is going to have a big impact on our ability to create a great client side experience.  After playing with YUI 3 for a while over the past few days, especially their Widget framework, it seems like a natural progression of where we were headed with our code base anyways, so YUI 3, here we come.

Even though I’ve made a decision to pursue YUI 3, there is still a ton I don’t know about it.  The components and utilities it offers are very different from YUI 2, although you can start to see some convergence in later point releases of YUI 2.  I’m sure there are others in the same boat, so I’m going to begin blogging about YUI 3: the new functionality, the new frameworks, and how to “translate” YUI 2 to YUI 3.  At the same time, I hope to walk through, line by line, some of the YUI functionality to help folks get a better understanding of how the Yahoo! engineers structure their code.

Y.bind

This may not be the most interesting topic for starters, but it’s one that illustrates a cool technique in JavaScript that John Resig has blogged about before called partial.  The official documentation for this method is here.  You can probably guess from the name, but this method has something to do with binding functions to objects.  It’s most common use case is with event handlers.  In YUI 2, you might have the following code:

YAHOO.util.Event.on("myElement", "click", this.myClickHandler, this, true);

This just says, when a user clicks on the element with ID “myElement”, call the method “myClickHandler,” which is a method of some object and execute that function in the context of that object.  This is a pretty common setup.  Here’s how you’d do the same thing in YUI 3:

Y.get("#myElement").on("click", Y.bind(this.myClickHandler, this));

This looks pretty similar.  Most of this is relatively straightforward and reminds me a lot of another JavaScript library (cough…jQuery…cough), but the one piece I was interested in was the “Y.bind” method.  Here’s what the method looks like as of the YUI 3 Beta 1:

/**
 * Returns a function that will execute the supplied function in the
 * supplied object's context, optionally adding any additional
 * supplied parameters to the beginning of the arguments collection the
 * supplied to the function.
 *
 * @method bind
 * @param f {Function|String} the function to bind, or a function name
 * to execute on the context object
 * @param c the execution context
 * @param args* 0..n arguments to include before the arguments the
 * function is executed with.
 * @return {function} the wrapped function
 */
 Y.bind = function(f, c) {
     var xargs = arguments.length > 2 ? Y.Array(arguments, 2, true) : null;
     return function () {
         var fn = L.isString(f) ? c[f] : f,
             args = (xargs) ? xargs.concat(Y.Array(arguments, 0, true)) : arguments;
         return fn.apply(c || fn, args);
     };
 };

This method is pretty short, but what is it doing?  Let’s break it down line by line.   Notice that it takes two required arguments — a function and an “execution context,” which is a fancy way of saying an object that will be the “scope” of the function when we call it — followed by any number of optional arguments that will be included as arguments to the eventual function call.  The first line of this method determines whether we have more than two arguments, and if so, parses out all of the extra arguments into an array.

After that, we create a function object we’re going to return.  This is one of the things I love about JavaScript.  You can have a function that returns another function.  Really powerful.  In this case, the function we are returning first checks to see if the argument “f” is a string, and if so, assumes it’s a method on the context object.  This is just for convenience.  I could’ve re-written my example as:

Y.get("#myElement").on("click", Y.bind("myClickHandler", this));

and it would’ve worked exactly the same way.  Now that we have the function, we want to determine what arguments to pass to it.  If we passed extra arguments to the Y.bind call, then we want to concatenate the arguments that will be passed to this returned function onto those arguments.  Otherwise, just use whatever arguments will be passed to this function.  Finally, this function will call our original method with the context we passed in (or if it wasn’t passed in, in the context of the function we passed in itself…not quite sure what the use case for that is), applying the set of arguments we’ve merged together.  And that’s it.

Before finishing this, it might be helpful to see an example of how what adding extra arguments does:

var alertAllTheArguments = function() {
    for (var i = 0, len = arguments.length; i < len; i++) {
        alert(arguments[i]);
    }
};
var alertOneAndTwoFirst = Y.bind(myFunc, null, 1, 2));
alertOneAndTwoFirst(); // alert(1); alert(2);
alertOneAndTwoFirst("hello", "world"); // alert(1); alert(2); alert("hello"); alert("world");

So as you can see, it’s basically a way to enforcing that certain arguments are always populated with certain values.  You might think, this is great, but what if I want the arguments I’m passing to be at the end of the arguments list instead of at the beginning?  Well, luckily, there’s a method for that too: Y.rbind.  If you want to do more complex things, see John Resig’s article above which has more on this technique.