I spent a few hours playing around with Scriptaculous and Prototype this afternoon, working on a navigation accordion-like feature for someone in the #wordpress support channel. It proved to be quite a learning experience (particularly when we realized the example was totally broken in IE7), so I thought I’d share my example with the rest of the world.
I was provided the CSS for the example and made a few changes to the HTML I was originally handed and asked to make it accordion-like, allowing multiple or no sections to be displayed at the same time. I could have easily accomplished this with MochiKit, but we also wanted a nice smooth roll-up and roll-down effect when each section was toggled on or off. Since MochiKit doesn’t do transition effects (yet), I decided to drop back to Script.aculo.us and punt.
Using Script.aculo.us and Prototype, I was able to create this example. It took quite a bit longer than I’d planned, but that was mostly spent reading through both sets of documentation and figuring out which functions were the best to use in each situation.
Ignore the junk at the end, that’s just debugging data. All the javascript is totally dynamic, hooking each element generated on the page. Since the navigation was intended to be used on a Wordpress-powered blog, there was no telling how many “panes” there actually could end up being. All-in-all, it was a fun experiment, and it got me some real experience with two new massively popular javascript libraries.
Overall, I still prefer the amazingly flexible simplicity of MochiKit, but the visual effects of Script.aculo.us can’t be denied…
I thought the idea of an accordion was to close open sections when a new one is open? I think that’s how the Moo.fx one used to work.
Jim: Correct. Hence why I said it was ‘accordion-like’. It looks like an accordion, but it doesn’t act like one. Instead, you’re able to toggle each section on / off without regard to the others. I suppose in functionality, they’re more like simple collapsible boxes; but in idea they were spun off the accordion concept.
Oh yeah, and I was actually looking at Moo.fx when this request came up. In the end I decided on script.aculo.us instead simply because it’s so popular for visual effects, and because I wanted to get some experience with prototype. A useful example, and it got me some on-the-job training with a new JS library… Win / Win. :)
Having tried both Moo.fx and Prototype (Script.aculo.us). I have to say that although Prototype is a bit more popular. Moo.fx is a better solution. The function name of Moo library is much shorter and concise.
Also, if you notice, your animation is not nice. There is a slight jerk at the end (on my Firefox 2.? WinXP) of the transition. This will not happen in Moo.fx.
You might also want to adopt the new JS function style. Not only does your code look more 2.0 but it is shorter and you tend to write OO code instead of functions.
Using something similar to
var AccordController = Class.create();
AccordController.prototype = function(){
//JSON code here
}
I have never heard of MochiKit before so I am looking forward to learning more about it here in your blog.
Hmm, I might be crazy but I don’t understand your use of PeriodicalExecuter.
Dat: The “jerk” at the end is because of the padding of that element. Apparently scriptaculous doesn’t handle that terribly well (yet). I minimized the jerk by causing the elements only to grow to x% of their real size (basically, 100%-padding), but it’s still noticeable.
The PeriodicalExecuter was used to wait until the element has fully closed, then remove the ‘open’ styling. Unfortunately, because of the way scriptaculous spins off to do its blind-up and blind-down, you can’t simply rely upon the order of the commands to remove the class after your element has ‘hidden’. What you end up with (without the PeriodicalExecuter) is your element blinding up (‘hiding’), but suddenly losing its styling in mid-effect.
I solved the problem by starting a new timer (the PE) to wait the same amount of time the effect is supposed to last (plus 1/10th of a second longer) before removing the element’s ‘displayed’ class. That way, we’re always sure the effect has completed (and the element ‘blinded up’) before we make it ugly by removing the CSS styling of the class.
Like I said, it’s not perfect, but it gets the job done.
Also, be sure to toss jQuery into this mix now. It’s being packaged (or will be for 2.2) with Wordpress, and looks to be another suitable alternative.
I still find MochiKit’s functional programming style more comfortable. The whole “new Effect.blah(…)” thing always got on my nerves. That’s just x more characters I have to type that I don’t really need to be typing over and over again.
I also find that when I dynamically create functions bound to variables (as you advocate) to make my code significantly more difficult to read when I come back to it later. To me, slightly “messier” code that I can instantly recognize the functionality of in the future is more than worth it.
A project I’m working on now should use a good deal of javascript in the next month or so. That’ll likely mean a lot more fodder for blogging / ranting, so stay tuned! :D
I am also a bit comfortable with new Effect.blah(…) too. Good to know that I am not the only one.
I wonder if you encountered a problem with using setTimeout instead of PE?