Skip to main content

Dojo & jQuery side by side. Part 2: Animation


Posted by Christopher Imrie in Code
2 Comments
Dojo and jQuery side by side. Part 1: DOM Basics
This is the second part of our Dojo and jQuery side by side series. If you’re not following allowing with the series, do be sure to check out Part 1: Dom Basics.
As mentioned in the previous article, the aim here is to provide a simple unbiased side by side comparison of common jQuery operations and how they are achieved in Dojo.
Today, we’re looking at animation and as a quick reminder you should assume that all the calls below are called when the DOM is ready.  If you’re not sure how to do this, checkout Part 1.
Lets go!

Fading elements in and out

This tends to be the workhorse for many beginner javascript programmers.  Simply select the element you want and then the javascript library will do the rest. 
jQuery is more succinct here since it assumes you want the animation to start straight away whereas dojo assumes you will want to trigger it later using the play method.  Dojo can be told to start automatically by providing the “auto” configuration option.
As with node traversal in Part 1, the NodeList animation extension is not loaded by default, so you need to require it.  As a reminder, NodeLists are what are returned from a dojo.query(), similar to jQuery collections which are returned from calling $().
//jQuery
//With default duration (400ms)
$("#header img").fadeOut(); 

//Specifying the duration
$("#header img").fadeOut(3000);                                 // Specify the duration in milliseconds


//Dojo
dojo.require("dojo.NodeList-fx");

//With default duration (350ms)
dojo.query("#header img").fadeOut().play();         
dojo.query("#header img").fadeOut({auto:true});                 // Automatically start (notice the play method is not called)

//Specifying the duration
dojo.query("#header img").fadeOut({duration:3000}).play();      
dojo.query("#header img").fadeOut({duration:3000, auto:true});  // Automatically start and specify the duration
As you would expect each also allows you to provide some configuration options as arguments to the fadeOut method.  The “fadeIn” mechanism is exactly the same as the “fadeOut”:
//jQuery
//With default duration (400ms)
$("#header").fadeIn(); 

//Specifying the duration
$("#header").fadeIn(3000);                                 // Specify the duration in milliseconds


//Dojo
dojo.require("dojo.NodeList-fx");

//With default duration (350ms)
dojo.query("#header").fadeIn().play();         
dojo.query("#header").fadeIn({auto:true});                 // Automatically start (notice the play method is not called)

//Specifying the duration
dojo.query("#header").fadeIn({duration:3000}).play();      
dojo.query("#header").fadeIn({duration:3000, auto:true});  // Automatically start and specify the duration

Slide Up & Down

Dojo takes a different naming convention when it comes to “sliding” and element.  jQuery uses this term to specify the hiding or showing of an element by changing its height.  Dojo prefers to use the more commonly known “wipe” terminology, which to be fair, is far more accurate (if you’ve done any type of video work, you’ll know this is a common term for this effect).
As with most of the Dojo animations, you will need to load the NodeList animation extensions manually.  Take note of the different CSS properties needed in order to get each to work. 
For brevity I have omitted the Dojo “auto:true” example, but rest assured it works with all the animation methods.
//jQuery
$("div.error").slideUp();
$("div.error").slideDown();                 // Only works with elements hidden with CSS "display:none" or that were hidden with "slideUp"


//Dojo
dojo.require("dojo.NodeList-fx");

dojo.query("div.error").wipeOut().play();
dojo.query("div.error").wipeIn().play();    // Only works on elements hidden with CSS "height: 0" or that were hidden with "wipeOut"

Animate multiple properties simultaneously

The examples in the preceding two examples are convenience functions that behind the scenes call an all purpose property animation method.  Both libraries will alow you to call each this method yourself if you want to animate more than one property at a time.
Once again, remember that we could provide the “auto:true” to the dojo animateProperty configuration object if we wanted it to play automatically as opposed to calling the play method.
//jQuery
$("#target").animate({
    width: 100,
    height: 300
}, 3000);


//Dojo
dojo.require("dojo.NodeList-fx");

dojo.query("#target").animateProperty({
    properties: {
        width: 100,
        height: 300
    },
    duration: 3000
}).play()

Chaining animation

When it comes to chaining animation, we see a clear difference in how each library chooses to handle this.  jQuery opts for the incredibly convenient chaining syntax, whereas Dojo uses a special “chain” method to collect the animations and then run them in sequence.
Although the jQuery method may be more convenient for simple animation chains, the ability for the Dojo chain method to accept an array allows you to store the animation chain and push/pop effects into it over time.  This can be very useful for animation sequences that change over time based on user actions.
Both implement their chaining mechanism so that it accepts all the standard animation effects.  Hence you can use the short hand “fadeIn” methods or the more powerful “animate” method when chaining animations.
//jQuery
$("#flash").fadeOut().fadeIn()

//Dojo
dojo.require("dojo.NodeList-fx");

dojo.fx.chain([                         
    dojo.query("div p").fadeOut(),
    dojo.query("div p").fadeIn()            // I would recommended you store the dojo.query("div p") as a variable to avoid repeated DOM queries
]).play();

Callback function when animation finishes

Here we once again see a distinct difference in how each library chooses to handle callback functions.  jQuery uses a standard API pattern whereby if the last argument supplied to an animation function, it will be called when the animation finishes. 
Dojo also has a standard pattern, but it chooses to use prespecified events to which you can attach callbacks. You can register callbacks for the following events: beforeBegin, onBegin, onAnimate, onEnd, onPlay, onPause, onStop.  The most commonly used is the “onEnd”, which is called when the animation finishes.
//jQuery
$("div p").fadeOut(3000, function(){
    alert("Animation has finished")
})

//Dojo
dojo.require("dojo.NodeList-fx");

dojo.query("div p").fadeOut({
    onEnd: function(){
            console.log("animation finished");
        },
    duration: 3000
}).play();

Comments

Popular posts from this blog

Quicksort implementation by using Java

 source: http://www.algolist.net/Algorithms/Sorting/Quicksort. The divide-and-conquer strategy is used in quicksort. Below the recursion step is described: 1st: Choose a pivot value. We take the value of the middle element as pivot value, but it can be any value(e.g. some people would like to pick the first element and do the exchange in the end) 2nd: Partition. Rearrange elements in such a way, that all elements which are lesser than the pivot go to the left part of the array and all elements greater than the pivot, go to the right part of the array. Values equal to the pivot can stay in any part of the array. Apply quicksort algorithm recursively to the left and the right parts - the previous pivot element excluded! Partition algorithm in detail: There are two indices i and j and at the very beginning of the partition algorithm i points to the first element in the array and j points to the last one. Then algorithm moves i forward, until an element with value greater or equal

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know. Symptom: 1.        The JVM became Out of memory when creating big consumption report 2.        Those JRTemplateElement-instances is still there occupied even if I logged out the system Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.     The clearobjects() method in ReportThread class has not been triggered when logging out Action I tried:      About the Virtualizer: 1.     Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.     Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory        About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object        

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold  highlighted in example below) which resolve the problems.   example: <band height="20" splitType="Stretch" > <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/>