2010-11-25 11:13:51 +00:00
/ *
2010-12-13 10:21:02 +00:00
* jQuery Mobile Framework : core utilities for auto ajax navigation , base tag mgmt ,
2010-11-25 11:13:51 +00:00
* Copyright ( c ) jQuery Project
* Dual licensed under the MIT or GPL Version 2 licenses .
* http : //jquery.org/license
2010-12-13 10:21:02 +00:00
* /
2011-04-29 01:12:01 +00:00
( function ( $ , undefined ) {
2010-11-25 11:13:51 +00:00
//define vars for interal use
2011-04-29 01:12:01 +00:00
var $window = $ ( window ) ,
$html = $ ( "html" ) ,
$head = $ ( "head" ) ,
2010-11-25 11:13:51 +00:00
//url path helpers for use in relative url management
path = {
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//get path from current hash, or from a file path
2011-04-29 12:22:03 +00:00
get : function ( newPath ) {
if ( newPath === undefined ) {
2010-11-25 11:13:51 +00:00
newPath = location . hash ;
}
2011-04-29 01:12:01 +00:00
return path . stripHash ( newPath ) . replace ( /[^\/]*\.[^\/*]+$/ , "" ) ;
2010-11-25 11:13:51 +00:00
} ,
2010-12-13 10:21:02 +00:00
//return the substring of a filepath before the sub-page key, for making a server request
2011-04-29 12:22:03 +00:00
getFilePath : function ( path ) {
2011-04-29 01:12:01 +00:00
var splitkey = "&" + $ . mobile . subPageUrlKey ;
2011-01-26 19:38:17 +00:00
return path && path . split ( splitkey ) [ 0 ] . split ( dialogHashKey ) [ 0 ] ;
2010-11-25 11:13:51 +00:00
} ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//set location hash to path
2011-04-29 12:22:03 +00:00
set : function ( path ) {
2010-11-25 11:13:51 +00:00
location . hash = path ;
} ,
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//location pathname from intial directory request
2011-04-29 01:12:01 +00:00
origin : "" ,
2010-12-13 10:21:02 +00:00
2011-04-29 12:22:03 +00:00
setOrigin : function ( ) {
2011-04-29 01:12:01 +00:00
path . origin = path . get ( location . protocol + "//" + location . host + location . pathname ) ;
2011-01-22 22:42:07 +00:00
} ,
2011-01-31 06:03:30 +00:00
2011-04-19 05:35:13 +00:00
// prefix a relative url with the current path
// TODO force old relative deeplinks into new absolute path
2011-04-29 12:22:03 +00:00
makeAbsolute : function ( url ) {
2011-04-19 04:45:23 +00:00
var isHashPath = path . isPath ( location . hash ) ;
2011-04-12 06:40:53 +00:00
2011-04-29 12:22:03 +00:00
if ( path . isQuery ( url ) ) {
2011-04-12 06:40:53 +00:00
// if the path is a list of query params and the hash is a path
2011-04-19 04:45:23 +00:00
// append the query params to the hash (without params or dialog keys).
2011-04-12 07:58:24 +00:00
// otherwise use the pathname and append the query params
2011-04-19 04:45:23 +00:00
return ( isHashPath ? path . cleanHash ( location . hash ) : location . pathname ) + url ;
2011-04-12 06:40:53 +00:00
}
2011-04-19 04:45:23 +00:00
// If the hash is a path, even if its not absolute, use it to prepend to the url
// otherwise use the path with the trailing segement removed
return ( isHashPath ? path . get ( ) : path . get ( location . pathname ) ) + url ;
2011-03-30 07:56:34 +00:00
} ,
// test if a given url (string) is a path
// NOTE might be exceptionally naive
2011-04-29 12:22:03 +00:00
isPath : function ( url ) {
2011-04-29 01:12:01 +00:00
return ( /\// ) . test ( url ) ;
2011-01-22 22:42:07 +00:00
} ,
2011-01-31 06:03:30 +00:00
2011-04-29 12:22:03 +00:00
isQuery : function ( url ) {
2011-04-29 01:12:01 +00:00
return ( /^\?/ ) . test ( url ) ;
2011-04-12 06:40:53 +00:00
} ,
2011-03-12 21:12:42 +00:00
//return a url path with the window's location protocol/hostname/pathname removed
2011-04-29 12:22:03 +00:00
clean : function ( url ) {
2011-04-19 05:35:13 +00:00
// Replace the protocol host only once at the beginning of the url to avoid
2011-03-12 21:57:46 +00:00
// problems when it's included as a part of a param
2011-04-29 01:12:01 +00:00
var leadingUrlRootRegex = new RegExp ( "^" + location . protocol + "//" + location . host ) ;
return url . replace ( leadingUrlRootRegex , "" ) ;
2011-01-22 22:42:07 +00:00
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//just return the url without an initial #
2011-04-29 12:22:03 +00:00
stripHash : function ( url ) {
2011-01-22 22:42:07 +00:00
return url . replace ( /^#/ , "" ) ;
} ,
2011-01-31 06:03:30 +00:00
2011-04-15 04:48:53 +00:00
//remove the preceding hash, any query params, and dialog notations
2011-04-29 12:22:03 +00:00
cleanHash : function ( hash ) {
2011-04-29 01:12:01 +00:00
return path . stripHash ( hash . replace ( /\?.*$/ , "" ) . replace ( dialogHashKey , "" ) ) ;
2011-04-12 07:58:24 +00:00
} ,
2011-01-22 22:42:07 +00:00
//check whether a url is referencing the same domain, or an external domain or different protocol
//could be mailto, etc
2011-04-29 12:22:03 +00:00
isExternal : function ( url ) {
2011-01-22 22:42:07 +00:00
return path . hasProtocol ( path . clean ( url ) ) ;
} ,
2011-01-31 06:03:30 +00:00
2011-04-29 12:22:03 +00:00
hasProtocol : function ( url ) {
2011-04-29 01:12:01 +00:00
return ( /^(:?\w+:)/ ) . test ( url ) ;
2011-01-22 22:42:07 +00:00
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//check if the url is relative
2011-04-29 12:22:03 +00:00
isRelative : function ( url ) {
2011-04-29 01:12:01 +00:00
return ( /^[^\/|#]/ ) . test ( url ) && ! path . hasProtocol ( url ) ;
2011-01-31 07:43:53 +00:00
} ,
2011-04-29 12:22:03 +00:00
isEmbeddedPage : function ( url ) {
2011-04-29 01:12:01 +00:00
return ( /^#/ ) . test ( url ) ;
2010-11-25 11:13:51 +00:00
}
} ,
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//will be defined when a link is clicked and given an active class
$activeClickedLink = null ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//urlHistory is purely here to make guesses at whether the back or forward button was clicked
//and provide an appropriate transition
urlHistory = {
//array of pages that are visited during a single page load. each has a url and optional transition
stack : [ ] ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//maintain an index number for the active page in the stack
activeIndex : 0 ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//get active
2011-04-29 12:22:03 +00:00
getActive : function ( ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
return urlHistory . stack [ urlHistory . activeIndex ] ;
} ,
2011-01-31 06:03:30 +00:00
2011-04-29 12:22:03 +00:00
getPrev : function ( ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
return urlHistory . stack [ urlHistory . activeIndex - 1 ] ;
} ,
2011-01-31 06:03:30 +00:00
2011-04-29 12:22:03 +00:00
getNext : function ( ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
return urlHistory . stack [ urlHistory . activeIndex + 1 ] ;
} ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
// addNew is used whenever a new page is added
2011-04-29 12:22:03 +00:00
addNew : function ( url , transition , title , storedTo ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//if there's forward history, wipe it
2011-04-29 12:22:03 +00:00
if ( urlHistory . getNext ( ) ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
urlHistory . clearForward ( ) ;
}
2011-01-31 06:03:30 +00:00
2011-04-29 01:12:01 +00:00
urlHistory . stack . push (
{
url : url ,
transition : transition ,
title : title ,
page : storedTo
}
) ;
2011-04-01 08:48:38 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
urlHistory . activeIndex = urlHistory . stack . length - 1 ;
} ,
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//wipe urls ahead of active index
2011-04-29 12:22:03 +00:00
clearForward : function ( ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
urlHistory . stack = urlHistory . stack . slice ( 0 , urlHistory . activeIndex + 1 ) ;
} ,
2011-02-15 01:23:25 +00:00
2011-04-29 12:22:03 +00:00
directHashChange : function ( opts ) {
2011-03-10 07:27:59 +00:00
var back , forward , newActiveIndex ;
2011-03-08 00:49:53 +00:00
2011-03-08 01:04:42 +00:00
// check if url isp in history and if it's ahead or behind current page
2011-04-29 12:22:03 +00:00
$ . each ( urlHistory . stack , function ( i , historyEntry ) {
2011-03-08 00:49:53 +00:00
//if the url is in the stack, it's a forward or a back
2011-04-29 12:22:03 +00:00
if ( opts . currentUrl === historyEntry . url ) {
2011-03-08 00:49:53 +00:00
//define back and forward by whether url is older or newer than current page
back = i < urlHistory . activeIndex ;
forward = ! back ;
newActiveIndex = i ;
}
} ) ;
2011-03-08 22:59:23 +00:00
// save new page index, null check to prevent falsey 0 result
2011-03-10 07:27:59 +00:00
this . activeIndex = newActiveIndex !== undefined ? newActiveIndex : this . activeIndex ;
2011-03-08 00:49:53 +00:00
2011-04-29 12:22:03 +00:00
if ( back ) {
2011-03-08 00:49:53 +00:00
opts . isBack ( ) ;
2011-04-29 12:22:03 +00:00
} else if ( forward ) {
2011-03-08 00:49:53 +00:00
opts . isForward ( ) ;
}
} ,
2011-02-01 04:56:56 +00:00
//disable hashchange event listener internally to ignore one change
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//toggled internally when location.hash is updated to match the url of a successful page load
2011-02-01 04:56:56 +00:00
ignoreNextHashChange : true
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
} ,
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//define first selector to receive focus when a page is shown
focusable = "[tabindex],a,button:visible,select:visible,input" ,
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//contains role for next page, if defined on clicked link via data-rel
2011-01-26 19:38:17 +00:00
nextPageRole = null ,
2011-01-31 06:03:30 +00:00
2011-02-01 19:52:15 +00:00
//queue to hold simultanious page transitions
pageTransitionQueue = [ ] ,
// indicates whether or not page is in process of transitioning
isPageTransitioning = false ,
2011-01-26 19:38:17 +00:00
//nonsense hash change key for dialogs, so they create a history entry
2011-02-17 03:55:01 +00:00
dialogHashKey = "&ui-state=dialog" ,
2010-12-13 10:21:02 +00:00
2011-01-18 17:18:22 +00:00
//existing base tag?
2011-04-29 01:12:01 +00:00
$base = $head . children ( "base" ) ,
2011-05-06 13:37:41 +00:00
//get domain path
//(note: use explicit protocol here, protocol-relative urls won't work as expected on localhost)
docBase = location . protocol + "//" + location . host ,
//initialPath for first page load without hash. pathname (href - search)
initialPath = docBase + location . pathname ;
//already a base element?
2011-04-29 12:22:03 +00:00
if ( $base . length ) {
2011-04-29 01:12:01 +00:00
var href = $base . attr ( "href" ) ;
2011-04-29 12:22:03 +00:00
if ( href ) {
if ( href . search ( /^[^:\/]+:\/\/[^\/]+\/?/ ) === - 1 ) {
2011-01-18 17:18:22 +00:00
//the href is not absolute, we need to turn it into one
2011-05-06 13:37:41 +00:00
docBase = docBase + href ;
2011-01-18 17:18:22 +00:00
}
else {
//the href is an absolute url
docBase = href ;
}
}
2011-05-06 13:37:41 +00:00
2011-01-18 17:18:22 +00:00
//make sure docBase ends with a slash
2011-04-29 01:12:01 +00:00
docBase = docBase + ( docBase . charAt ( docBase . length - 1 ) === "/" ? " " : "/" ) ;
2011-01-18 17:18:22 +00:00
}
//base element management, defined depending on dynamic base tag support
2011-02-16 22:22:28 +00:00
var base = $ . support . dynamicBaseTag ? {
2011-01-18 17:18:22 +00:00
//define base element, for use in routing asset urls that are referenced in Ajax-requested markup
2011-05-06 13:37:41 +00:00
element : ( $base . length ? $base : $ ( "<base>" , { href : initialPath } ) . prependTo ( $head ) ) ,
2011-01-18 17:18:22 +00:00
//set the generated BASE element's href attribute to a new page's base path
2011-04-29 12:22:03 +00:00
set : function ( href ) {
base . element . attr ( "href" , docBase + path . get ( href ) ) ;
2011-01-18 17:18:22 +00:00
} ,
//set the generated BASE element's href attribute to a new page's base path
2011-04-29 12:22:03 +00:00
reset : function ( ) {
2011-05-06 17:28:31 +00:00
base . element . attr ( "href" , initialPath ) ;
2011-01-18 17:18:22 +00:00
}
} : undefined ;
2010-11-25 11:13:51 +00:00
//set location pathname from intial directory request
path . setOrigin ( ) ;
2010-12-13 10:21:02 +00:00
/ *
2010-11-25 11:13:51 +00:00
internal utility functions
2010-12-13 10:21:02 +00:00
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- * /
2010-11-25 11:13:51 +00:00
//direct focus to the page title, or otherwise first focusable element
2011-04-29 12:22:03 +00:00
function reFocus ( page ) {
2011-04-07 20:50:10 +00:00
var lastClicked = page . jqmData ( "lastClicked" ) ;
2011-04-11 05:58:21 +00:00
2011-04-29 12:22:03 +00:00
if ( lastClicked && lastClicked . length ) {
2011-04-07 20:27:32 +00:00
lastClicked . focus ( ) ;
}
2011-04-07 20:50:10 +00:00
else {
var pageTitle = page . find ( ".ui-title:eq(0)" ) ;
2011-04-11 05:58:21 +00:00
2011-04-29 12:22:03 +00:00
if ( pageTitle . length ) {
2011-04-07 20:50:10 +00:00
pageTitle . focus ( ) ;
}
else {
2011-04-29 01:12:01 +00:00
page . find ( focusable ) . eq ( 0 ) . focus ( ) ;
2011-04-07 20:50:10 +00:00
}
2010-11-25 11:13:51 +00:00
}
2011-02-08 21:13:59 +00:00
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//remove active classes after page transition or error
2011-04-29 12:22:03 +00:00
function removeActiveLinkClass ( forceRemoval ) {
if ( ! ! $activeClickedLink && ( ! $activeClickedLink . closest ( ".ui-page-active" ) . length || forceRemoval ) ) {
2010-11-25 11:13:51 +00:00
$activeClickedLink . removeClass ( $ . mobile . activeBtnClass ) ;
}
$activeClickedLink = null ;
2011-02-08 21:13:59 +00:00
}
2010-11-25 11:13:51 +00:00
//animation complete callback
2011-04-29 12:22:03 +00:00
$ . fn . animationComplete = function ( callback ) {
if ( $ . support . cssTransitions ) {
2011-04-29 01:12:01 +00:00
return $ ( this ) . one ( "webkitAnimationEnd" , callback ) ;
2010-11-25 11:13:51 +00:00
}
else {
2011-01-30 23:06:33 +00:00
// defer execution for consistency between webkit/non webkit
2011-04-29 01:12:01 +00:00
setTimeout ( callback , 0 ) ;
return $ ( this ) ;
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
} ;
2010-11-25 11:13:51 +00:00
/* exposed $.mobile methods */
//update location.hash, with or without triggering hashchange event
2011-01-24 00:03:35 +00:00
//TODO - deprecate this one at 1.0
2010-11-25 11:13:51 +00:00
$ . mobile . updateHash = path . set ;
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//expose path object on $.mobile
$ . mobile . path = path ;
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//expose base object on $.mobile
$ . mobile . base = base ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//url stack, useful when plugins need to be aware of previous pages viewed
2011-01-24 00:03:35 +00:00
//TODO: deprecate this one at 1.0
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
$ . mobile . urlstack = urlHistory . stack ;
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
//history stack
$ . mobile . urlHistory = urlHistory ;
2011-01-20 07:48:30 +00:00
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
//default non-animation transition handler
2011-04-29 12:22:03 +00:00
$ . mobile . noneTransitionHandler = function ( name , reverse , $to , $from ) {
if ( $from ) {
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
$from . removeClass ( $ . mobile . activePageClass ) ;
}
$to . addClass ( $ . mobile . activePageClass ) ;
2011-04-29 01:12:01 +00:00
return $ . Deferred ( ) . resolve ( name , reverse , $to , $from ) . promise ( ) ;
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
} ;
//default handler for unknown transitions
$ . mobile . defaultTransitionHandler = $ . mobile . noneTransitionHandler ;
//transition handler dictionary for 3rd party transitions
$ . mobile . transitionHandlers = {
none : $ . mobile . defaultTransitionHandler
} ;
2011-03-19 00:53:06 +00:00
//enable cross-domain page support
$ . mobile . allowCrossDomainPages = false ;
2010-12-13 10:21:02 +00:00
// changepage function
2011-04-29 12:22:03 +00:00
$ . mobile . changePage = function ( to , transition , reverse , changeHash , fromHashChange ) {
2010-11-25 11:13:51 +00:00
//from is always the currently viewed page
2011-04-29 01:12:01 +00:00
var toType = $ . type ( to ) ,
toIsArray = toType === "array" ,
toIsObject = toType === "object" ,
from = toIsArray ? to [ 0 ] : $ . mobile . activePage ;
2011-02-08 21:13:59 +00:00
to = toIsArray ? to [ 1 ] : to ;
2011-02-15 01:23:25 +00:00
2011-04-29 01:12:01 +00:00
var url = $ . type ( to ) === "string" ? path . stripHash ( to ) : "" ,
2011-02-08 21:13:59 +00:00
fileUrl = url ,
data ,
2011-04-29 01:12:01 +00:00
type = "get" ,
2010-11-25 11:13:51 +00:00
isFormRequest = false ,
duplicateCachedPage = null ,
2011-04-14 06:33:29 +00:00
active = urlHistory . getActive ( ) ,
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
back = false ,
2011-04-01 21:05:46 +00:00
forward = false ,
2011-03-31 16:48:46 +00:00
pageTitle = document . title ;
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
// If we are trying to transition to the same page that we are currently on ignore the request.
// an illegal same page request is defined by the current page being the same as the url, as long as there's history
// and to is not an array or object (those are allowed to be "same")
2011-04-14 06:33:29 +00:00
if ( urlHistory . stack . length > 0
2011-04-29 01:12:01 +00:00
&& active . page . jqmData ( "url" ) === url
2011-04-14 06:33:29 +00:00
&& ! toIsArray && ! toIsObject ) {
2010-12-03 22:07:39 +00:00
return ;
2011-01-31 06:03:30 +00:00
}
2011-04-29 01:12:01 +00:00
else if ( isPageTransitioning ) {
pageTransitionQueue . unshift ( arguments ) ;
2011-02-01 19:52:15 +00:00
return ;
}
2011-02-15 01:23:25 +00:00
2011-02-01 19:52:15 +00:00
isPageTransitioning = true ;
2011-01-31 06:03:30 +00:00
2011-03-08 00:49:53 +00:00
// if the changePage was sent from a hashChange event guess if it came from the history menu
// and match the transition accordingly
2011-04-29 12:22:03 +00:00
if ( fromHashChange ) {
2011-04-29 01:12:01 +00:00
urlHistory . directHashChange ( {
2011-03-08 00:49:53 +00:00
currentUrl : url ,
2011-04-29 12:22:03 +00:00
isBack : function ( ) {
2011-04-29 01:12:01 +00:00
forward = ! ( back = true ) ;
2011-03-08 00:49:53 +00:00
reverse = true ;
2011-04-14 06:33:29 +00:00
transition = transition || active . transition ;
2011-03-08 00:49:53 +00:00
} ,
2011-04-29 12:22:03 +00:00
isForward : function ( ) {
2011-04-29 01:12:01 +00:00
forward = ! ( back = false ) ;
2011-03-08 00:49:53 +00:00
transition = transition || urlHistory . getActive ( ) . transition ;
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
}
} ) ;
2011-01-31 06:03:30 +00:00
2011-03-10 07:27:59 +00:00
//TODO forward = !back was breaking for some reason
2010-12-03 22:07:39 +00:00
}
2011-01-31 06:03:30 +00:00
2011-04-29 12:22:03 +00:00
if ( toIsObject && to . url ) {
2011-02-08 21:13:59 +00:00
url = to . url ;
data = to . data ;
type = to . type ;
2010-11-25 11:13:51 +00:00
isFormRequest = true ;
//make get requests bookmarkable
2011-04-29 12:22:03 +00:00
if ( data && type === "get" ) {
if ( $ . type ( data ) === "object" ) {
2011-04-29 01:12:01 +00:00
data = $ . param ( data ) ;
2011-01-27 03:04:36 +00:00
}
2011-01-31 06:03:30 +00:00
2010-11-25 11:13:51 +00:00
url += "?" + data ;
data = undefined ;
}
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//reset base to pathname for new request
2011-04-29 12:22:03 +00:00
if ( base ) { base . reset ( ) ; }
2010-12-13 10:21:02 +00:00
2010-12-04 19:46:41 +00:00
//kill the keyboard
2011-04-11 05:59:06 +00:00
$ ( window . document . activeElement || "" ) . add ( "input:focus, textarea:focus, select:focus" ) . blur ( ) ;
2010-12-13 10:21:02 +00:00
2011-04-29 12:22:03 +00:00
function defaultTransition ( ) {
if ( transition === undefined ) {
2011-04-29 01:12:01 +00:00
transition = ( nextPageRole && nextPageRole === "dialog" ) ? "pop" : $ . mobile . defaultTransition ;
2010-12-17 03:12:47 +00:00
}
}
2011-04-29 12:22:03 +00:00
function releasePageTransitionLock ( ) {
2011-02-05 20:00:31 +00:00
isPageTransitioning = false ;
2011-04-29 01:12:01 +00:00
if ( pageTransitionQueue . length > 0 ) {
2011-04-29 12:22:03 +00:00
$ . mobile . changePage . apply ( $ . mobile , pageTransitionQueue . pop ( ) ) ;
2011-02-05 20:00:31 +00:00
}
}
2011-02-15 01:23:25 +00:00
2010-11-25 11:13:51 +00:00
//function for transitioning between two existing pages
function transitionPages ( ) {
2011-01-27 01:41:30 +00:00
$ . mobile . silentScroll ( ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//get current scroll distance
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
var currScroll = $window . scrollTop ( ) ;
2011-01-31 06:03:30 +00:00
//support deep-links to generated sub-pages
2011-04-29 12:22:03 +00:00
if ( url . indexOf ( "&" + $ . mobile . subPageUrlKey ) > - 1 ) {
2011-03-25 21:50:40 +00:00
to = $ ( ":jqmData(url='" + url + "')" ) ;
2011-01-26 00:36:42 +00:00
}
2011-02-15 01:23:25 +00:00
2011-04-29 12:22:03 +00:00
if ( from ) {
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//set as data for returning to that spot
2011-04-07 20:27:32 +00:00
from
2011-04-29 01:12:01 +00:00
. jqmData ( "lastScroll" , currScroll )
. jqmData ( "lastClicked" , $activeClickedLink ) ;
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//trigger before show/hide events
2011-03-04 17:55:22 +00:00
from . data ( "page" ) . _trigger ( "beforehide" , null , { nextPage : to } ) ;
2011-02-15 01:23:25 +00:00
}
2011-04-29 01:12:01 +00:00
to . data ( "page" ) . _trigger ( "beforeshow" , null , { prevPage : from || $ ( "" ) } ) ;
2010-12-13 10:21:02 +00:00
2011-04-29 12:22:03 +00:00
function pageChangeComplete ( ) {
2010-12-13 10:21:02 +00:00
2011-04-29 12:22:03 +00:00
if ( changeHash !== false && url ) {
2011-02-01 04:47:01 +00:00
//disable hash listening temporarily
2011-02-01 04:56:56 +00:00
urlHistory . ignoreNextHashChange = false ;
2011-02-01 04:47:01 +00:00
//update hash and history
2011-01-26 00:36:42 +00:00
path . set ( url ) ;
2010-11-25 11:13:51 +00:00
}
2011-04-01 08:48:38 +00:00
2011-03-31 13:46:56 +00:00
//if title element wasn't found, try the page div data attr too
2011-05-05 21:26:41 +00:00
var newPageTitle = to . jqmData ( "title" ) || to . find ( ":jqmData(role='header') .ui-title" ) . text ( ) ;
2011-04-29 12:22:03 +00:00
if ( ! ! newPageTitle && pageTitle === document . title ) {
2011-03-31 16:48:46 +00:00
pageTitle = newPageTitle ;
}
2011-01-26 19:38:17 +00:00
//add page to history stack if it's not back or forward
2011-04-29 12:22:03 +00:00
if ( ! back && ! forward ) {
2011-03-31 16:48:46 +00:00
urlHistory . addNew ( url , transition , pageTitle , to ) ;
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
}
2011-04-01 08:48:38 +00:00
2011-03-31 16:48:46 +00:00
//set page title
document . title = urlHistory . getActive ( ) . title ;
2011-01-31 06:03:30 +00:00
2010-11-25 11:13:51 +00:00
removeActiveLinkClass ( ) ;
2010-12-13 10:21:02 +00:00
2011-01-27 01:41:30 +00:00
//jump to top or prev scroll, sometimes on iOS the page has not rendered yet. I could only get by this with a setTimeout, but would like to avoid that.
2011-03-25 21:50:40 +00:00
$ . mobile . silentScroll ( to . jqmData ( "lastScroll" ) ) ;
2011-04-29 12:22:03 +00:00
$ ( document ) . one ( "silentscroll" , function ( ) { reFocus ( to ) ; } ) ;
2010-12-13 10:21:02 +00:00
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//trigger show/hide events
2011-04-29 12:22:03 +00:00
if ( from ) {
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
from . data ( "page" ) . _trigger ( "hide" , null , { nextPage : to } ) ;
2010-12-01 14:52:01 +00:00
}
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//trigger pageshow, define prevPage as either from or empty jQuery obj
2011-04-29 01:12:01 +00:00
to . data ( "page" ) . _trigger ( "show" , null , { prevPage : from || $ ( "" ) } ) ;
2011-02-15 01:23:25 +00:00
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//set "to" as activePage
$ . mobile . activePage = to ;
2010-12-10 12:27:14 +00:00
//if there's a duplicateCachedPage, remove it from the DOM now that it's hidden
2011-04-29 01:12:01 +00:00
if ( duplicateCachedPage !== null ) {
2010-12-10 12:27:14 +00:00
duplicateCachedPage . remove ( ) ;
}
2011-02-15 01:23:25 +00:00
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//remove initial build class (only present on first pageshow)
$html . removeClass ( "ui-mobile-rendering" ) ;
2011-02-01 19:52:15 +00:00
2011-02-05 20:00:31 +00:00
releasePageTransitionLock ( ) ;
2011-02-08 21:13:59 +00:00
}
2010-12-13 10:21:02 +00:00
2011-04-17 21:24:47 +00:00
//clear page loader
$ . mobile . pageLoading ( true ) ;
2011-04-19 05:35:13 +00:00
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
//find the transition handler for the specified transition. If there
//isn't one in our transitionHandlers dictionary, use the default one.
//call the handler immediately to kick-off the transition.
var th = $ . mobile . transitionHandlers [ transition || "none" ] || $ . mobile . defaultTransitionHandler ,
2011-04-29 01:12:01 +00:00
deferred = th ( transition , reverse , to , from ) ;
2010-12-13 10:21:02 +00:00
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
//register a done callback on the transition so we can do some book-keeping cleanup.
2011-04-29 12:22:03 +00:00
deferred . done ( function ( ) {
2011-04-07 15:33:04 +00:00
pageChangeComplete ( ) ;
Changes to allow 3rd party transitions. Developers can now register a custom transition by adding their transition handler to the $.mobile.transitionHandlers dictionary. The name of the custom transition is used as the key within the transtionsHandlers dictionary, and should be the same name used within the @data-transtion attribute.
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
2011-04-26 21:06:10 +00:00
} ) ;
2011-02-08 21:13:59 +00:00
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//shared page enhancements
2011-04-29 12:22:03 +00:00
function enhancePage ( ) {
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//set next page role, if defined
2011-04-29 01:12:01 +00:00
if ( nextPageRole || to . jqmData ( "role" ) === "dialog" ) {
2011-01-26 19:38:17 +00:00
url = urlHistory . getActive ( ) . url + dialogHashKey ;
2011-04-29 12:22:03 +00:00
if ( nextPageRole ) {
2011-02-20 17:12:01 +00:00
to . attr ( "data-" + $ . mobile . ns + "role" , nextPageRole ) ;
2010-12-07 17:05:10 +00:00
nextPageRole = null ;
}
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
//run page plugin
2010-11-25 11:13:51 +00:00
to . page ( ) ;
2011-02-08 21:13:59 +00:00
}
2010-11-25 11:13:51 +00:00
//if url is a string
2011-04-29 12:22:03 +00:00
if ( url ) {
2011-03-25 21:50:40 +00:00
to = $ ( ":jqmData(url='" + url + "')" ) ;
2011-04-29 01:12:01 +00:00
fileUrl = path . getFilePath ( url ) ;
2010-11-25 11:13:51 +00:00
}
else { //find base url of element, if avail
2011-02-20 18:43:02 +00:00
var toID = to . attr ( "data-" + $ . mobile . ns + "url" ) ,
2011-04-29 01:12:01 +00:00
toIDfileurl = path . getFilePath ( toID ) ;
2010-12-13 10:21:02 +00:00
2011-04-29 12:22:03 +00:00
if ( toID !== toIDfileurl ) {
2010-11-25 11:13:51 +00:00
fileUrl = toIDfileurl ;
2010-12-13 10:21:02 +00:00
}
2010-11-25 11:13:51 +00:00
}
2011-01-31 06:03:30 +00:00
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
// ensure a transition has been set where pop is undefined
defaultTransition ( ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
// find the "to" page, either locally existing in the dom or by creating it through ajax
if ( to . length && ! isFormRequest ) {
2011-04-29 12:22:03 +00:00
if ( fileUrl && base ) {
2010-11-25 11:13:51 +00:00
base . set ( fileUrl ) ;
2011-02-15 01:23:25 +00:00
}
2010-11-25 11:13:51 +00:00
enhancePage ( ) ;
transitionPages ( ) ;
2010-12-13 10:21:02 +00:00
} else {
2010-11-25 11:13:51 +00:00
//if to exists in DOM, save a reference to it in duplicateCachedPage for removal after page change
2011-04-29 12:22:03 +00:00
if ( to . length ) {
2010-11-25 11:13:51 +00:00
duplicateCachedPage = to ;
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
$ . mobile . pageLoading ( ) ;
$ . ajax ( {
url : fileUrl ,
type : type ,
data : data ,
2011-04-01 20:37:18 +00:00
dataType : "html" ,
2010-11-25 11:13:51 +00:00
success : function ( html ) {
2011-01-31 06:03:30 +00:00
//pre-parse html to check for a data-url,
2011-01-25 05:29:19 +00:00
//use it as the new fileUrl, base path, etc
2011-04-29 01:12:01 +00:00
var all = $ ( "<div></div>" ) ,
2011-02-16 06:24:15 +00:00
redirectLoc ,
2011-04-01 08:48:38 +00:00
2011-03-31 16:48:46 +00:00
//page title regexp
newPageTitle = html . match ( /<title[^>]*>([^<]*)/ ) && RegExp . $1 ,
2011-04-01 08:48:38 +00:00
2011-02-16 06:24:15 +00:00
// TODO handle dialogs again
2011-05-02 22:48:06 +00:00
pageElemRegex = new RegExp ( "(<[^>]+\\bdata-" + $ . mobile . ns + "role=[\"']?page[\"']?[^>]*>)" ) ,
2011-04-29 01:12:01 +00:00
dataUrlRegex = new RegExp ( "\\bdata-" + $ . mobile . ns + "url=[\"']?([^\"'>]*)[\"']?" ) ;
2011-04-01 08:48:38 +00:00
2011-02-16 06:24:15 +00:00
// data-url must be provided for the base tag so resource requests can be directed to the
// correct url. loading into a temprorary element makes these requests immediately
2011-04-29 01:12:01 +00:00
if ( pageElemRegex . test ( html ) && RegExp . $1 && dataUrlRegex . test ( RegExp . $1 ) && RegExp . $1 ) {
2011-02-16 06:24:15 +00:00
redirectLoc = RegExp . $1 ;
}
2011-01-25 00:35:45 +00:00
2011-04-29 12:22:03 +00:00
if ( redirectLoc ) {
if ( base ) {
2011-01-25 04:56:53 +00:00
base . set ( redirectLoc ) ;
2011-01-31 06:03:30 +00:00
}
2011-02-01 17:32:02 +00:00
url = fileUrl = path . getFilePath ( redirectLoc ) ;
2011-01-25 00:35:45 +00:00
}
else {
2011-04-29 12:22:03 +00:00
if ( base ) {
2011-04-29 01:12:01 +00:00
base . set ( fileUrl ) ;
2011-01-31 06:03:30 +00:00
}
2011-01-25 00:35:45 +00:00
}
2011-01-31 06:03:30 +00:00
2011-02-16 06:24:15 +00:00
//workaround to allow scripts to execute when included in page divs
2011-04-29 01:12:01 +00:00
all . get ( 0 ) . innerHTML = html ;
2011-03-25 21:50:40 +00:00
to = all . find ( ":jqmData(role='page'), :jqmData(role='dialog')" ) . first ( ) ;
2011-04-01 08:48:38 +00:00
2011-03-31 16:48:46 +00:00
//finally, if it's defined now, set the page title for storage in urlHistory
2011-04-29 12:22:03 +00:00
if ( newPageTitle ) {
2011-03-31 16:48:46 +00:00
pageTitle = newPageTitle ;
2011-04-01 08:48:38 +00:00
}
2011-02-16 06:24:15 +00:00
2010-11-25 11:13:51 +00:00
//rewrite src and href attrs to use a base url
2011-04-29 12:22:03 +00:00
if ( ! $ . support . dynamicBaseTag ) {
2010-11-25 11:13:51 +00:00
var newPath = path . get ( fileUrl ) ;
2011-04-29 12:22:03 +00:00
to . find ( "[src], link[href], a[rel='external'], :jqmData(ajax='false'), a[target]" ) . each ( function ( ) {
2011-05-06 20:05:56 +00:00
var attrs = [ "href" , "src" , "action" ] ,
thisAttr = undefined ,
thisUrl = undefined ;
for ( var i = 0 ; i < attrs . length ; i ++ ) {
var a = attrs [ i ] ,
v = $ ( this ) . attr ( a ) ;
if ( v ) {
thisAttr = a ;
thisUrl = v ;
break ;
}
}
2010-12-13 10:21:02 +00:00
2011-05-06 20:05:56 +00:00
if ( thisAttr && thisUrl ) {
//if full path exists and is same, chop it - helps IE out
thisUrl = thisUrl . replace ( location . protocol + "//" + location . host + location . pathname , "" ) ;
if ( ! /^(\w+:|#|\/)/ . test ( thisUrl ) ) {
$ ( this ) . attr ( thisAttr , newPath + thisUrl ) ;
}
2010-11-25 11:13:51 +00:00
}
} ) ;
}
2011-01-31 06:03:30 +00:00
2011-01-25 00:35:45 +00:00
//append to page and enhance
2011-01-25 05:29:19 +00:00
to
2011-02-20 18:43:02 +00:00
. attr ( "data-" + $ . mobile . ns + "url" , fileUrl )
2011-01-25 05:29:19 +00:00
. appendTo ( $ . mobile . pageContainer ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
enhancePage ( ) ;
2011-04-29 01:12:01 +00:00
setTimeout ( function ( ) { transitionPages ( ) ; } , 0 ) ;
2010-11-25 11:13:51 +00:00
} ,
error : function ( ) {
2011-03-30 07:42:42 +00:00
2011-03-27 16:27:50 +00:00
//remove loading message
2010-11-25 11:13:51 +00:00
$ . mobile . pageLoading ( true ) ;
2011-03-30 07:42:42 +00:00
2011-03-27 16:27:50 +00:00
//clear out the active button state
2011-04-29 01:12:01 +00:00
removeActiveLinkClass ( true ) ;
2011-03-30 07:42:42 +00:00
2011-03-27 16:27:50 +00:00
//set base back to current path
2011-04-29 12:22:03 +00:00
if ( base ) {
2011-03-27 16:27:50 +00:00
base . set ( path . get ( ) ) ;
2011-02-02 19:10:40 +00:00
}
2011-03-30 07:42:42 +00:00
2011-03-27 16:27:50 +00:00
//release transition lock so navigation is free again
releasePageTransitionLock ( ) ;
2011-03-30 07:42:42 +00:00
2011-03-27 16:27:50 +00:00
//show error message
2011-04-29 01:12:01 +00:00
$ ( "<div class='ui-loader ui-overlay-shadow ui-body-e ui-corner-all'><h1>" + $ . mobile . pageLoadErrorMessage + "</h1></div>" )
. css ( { "display" : "block" , "opacity" : 0.96 , "top" : $ ( window ) . scrollTop ( ) + 100 } )
2010-11-25 11:13:51 +00:00
. appendTo ( $ . mobile . pageContainer )
. delay ( 800 )
2011-04-29 12:22:03 +00:00
. fadeOut ( 400 , function ( ) {
2011-04-29 01:12:01 +00:00
$ ( this ) . remove ( ) ;
2010-11-25 11:13:51 +00:00
} ) ;
}
} ) ;
}
} ;
2010-12-13 10:21:02 +00:00
/* Event Bindings - hashchange, submit, and click */
2010-11-25 11:13:51 +00:00
//bind to form submit events, handle with Ajax
2011-04-29 12:22:03 +00:00
$ ( "form" ) . live ( "submit" , function ( event ) {
2011-01-24 00:03:35 +00:00
if ( ! $ . mobile . ajaxEnabled ||
2011-04-29 12:22:03 +00:00
//TODO: deprecated - remove at 1.0
! $ . mobile . ajaxFormsEnabled ||
$ ( this ) . is ( ":jqmData(ajax='false')" ) ) {
return ;
}
2010-12-13 10:21:02 +00:00
2011-04-29 01:12:01 +00:00
var type = $ ( this ) . attr ( "method" ) ,
url = path . clean ( $ ( this ) . attr ( "action" ) ) ,
target = $ ( this ) . attr ( "target" ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//external submits use regular HTTP
2011-04-29 12:22:03 +00:00
if ( path . isExternal ( url ) || target ) {
2010-11-25 11:13:51 +00:00
return ;
2010-12-13 10:21:02 +00:00
}
2010-11-25 11:13:51 +00:00
//if it's a relative href, prefix href with base url
2011-04-29 12:22:03 +00:00
if ( path . isRelative ( url ) ) {
2011-01-22 22:42:07 +00:00
url = path . makeAbsolute ( url ) ;
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
$ . mobile . changePage ( {
2011-03-24 04:36:24 +00:00
url : url . length && url || path . get ( ) ,
2011-03-24 04:33:59 +00:00
type : type . length && type . toLowerCase ( ) || "get" ,
2011-04-29 01:12:01 +00:00
data : $ ( this ) . serialize ( )
2010-11-25 11:13:51 +00:00
} ,
2011-04-29 01:12:01 +00:00
$ ( this ) . jqmData ( "transition" ) ,
$ ( this ) . jqmData ( "direction" ) ,
2010-11-25 11:13:51 +00:00
true
) ;
event . preventDefault ( ) ;
2010-12-13 10:21:02 +00:00
} ) ;
2011-04-11 05:58:21 +00:00
2011-04-29 12:22:03 +00:00
function findClosestLink ( ele ) {
while ( ele ) {
if ( ele . nodeName . toLowerCase ( ) === "a" ) {
2011-04-18 23:13:50 +00:00
break ;
}
ele = ele . parentNode ;
}
return ele ;
}
2011-04-07 19:28:52 +00:00
//add active state on vclick
2011-04-29 12:22:03 +00:00
$ ( document ) . bind ( "vclick" , function ( event ) {
2011-04-29 01:12:01 +00:00
var link = findClosestLink ( event . target ) ;
2011-04-29 12:22:03 +00:00
if ( link ) {
2011-04-29 01:12:01 +00:00
var url = path . clean ( link . getAttribute ( "href" ) || "#" ) ;
2011-04-29 12:22:03 +00:00
if ( url !== "#" && url . replace ( path . get ( ) , "" ) !== "#" ) {
2011-04-29 01:12:01 +00:00
$ ( link ) . closest ( ".ui-btn" ) . not ( ".ui-disabled" ) . addClass ( $ . mobile . activeBtnClass ) ;
2011-04-22 17:53:24 +00:00
}
2011-04-18 23:13:50 +00:00
}
2011-04-07 19:28:52 +00:00
} ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//click routing - direct to HTTP or Ajax, accordingly
2011-04-29 01:12:01 +00:00
$ ( document ) . bind ( "click" , function ( event ) {
var link = findClosestLink ( event . target ) ;
2011-04-29 12:22:03 +00:00
if ( ! link ) {
2011-04-18 23:13:50 +00:00
return ;
}
2011-01-31 06:03:30 +00:00
2011-04-29 01:12:01 +00:00
var $link = $ ( link ) ,
2011-02-15 01:23:25 +00:00
2011-02-01 06:01:41 +00:00
//get href, if defined, otherwise fall to null #
2011-04-18 23:13:50 +00:00
href = $link . attr ( "href" ) || "#" ,
2011-02-15 01:23:25 +00:00
2011-03-12 19:18:46 +00:00
//cache a check for whether the link had a protocol
//if this is true and the link was same domain, we won't want
//to prefix the url with a base (esp helpful in IE, where every
//url is absolute
hadProtocol = path . hasProtocol ( href ) ,
2011-02-15 01:23:25 +00:00
2010-11-25 11:13:51 +00:00
//get href, remove same-domain protocol and host
2011-02-01 06:01:41 +00:00
url = path . clean ( href ) ,
2011-01-31 06:03:30 +00:00
2011-01-31 07:43:53 +00:00
//rel set to external
2011-04-18 23:13:50 +00:00
isRelExternal = $link . is ( "[rel='external']" ) ,
2011-01-31 07:43:53 +00:00
//rel set to external
isEmbeddedPage = path . isEmbeddedPage ( url ) ,
2011-03-19 00:53:06 +00:00
// Some embedded browsers, like the web view in Phone Gap, allow cross-domain XHR
// requests if the document doing the request was loaded via the file:// protocol.
// This is usually to allow the application to "phone home" and fetch app specific
// data. We normally let the browser handle external/cross-domain urls, but if the
// allowCrossDomainPages option is true, we will allow cross-domain http/https
// requests to go through our page loading logic.
2011-04-29 01:12:01 +00:00
isCrossDomainPageLoad = ( $ . mobile . allowCrossDomainPages && location . protocol === "file:" && url . search ( /^https?:/ ) !== - 1 ) ,
2011-03-21 17:32:24 +00:00
2011-01-31 07:43:53 +00:00
//check for protocol or rel and its not an embedded page
//TODO overlap in logic from isExternal, rel=external check should be
// moved into more comprehensive isExternalLink
2011-04-29 01:12:01 +00:00
isExternal = ( path . isExternal ( url ) && ! isCrossDomainPageLoad ) || ( isRelExternal && ! isEmbeddedPage ) ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//if target attr is specified we mimic _blank... for now
2011-04-18 23:13:50 +00:00
hasTarget = $link . is ( "[target]" ) ,
2011-01-31 10:04:13 +00:00
//if data-ajax attr is set to false, use the default behavior of a link
2011-04-18 23:13:50 +00:00
hasAjaxDisabled = $link . is ( ":jqmData(ajax='false')" ) ;
2011-01-31 06:03:30 +00:00
2011-01-26 00:36:42 +00:00
//if there's a data-rel=back attr, go back in history
2011-04-29 12:22:03 +00:00
if ( $link . is ( ":jqmData(rel='back')" ) ) {
2011-03-07 07:47:40 +00:00
window . history . back ( ) ;
2011-04-04 17:00:24 +00:00
return false ;
2011-01-31 06:03:30 +00:00
}
2011-01-22 22:42:07 +00:00
2011-03-12 21:12:42 +00:00
//prevent # urls from bubbling
//path.get() is replaced to combat abs url prefixing in IE
2011-04-29 12:22:03 +00:00
if ( url . replace ( path . get ( ) , "" ) === "#" ) {
2010-11-25 11:13:51 +00:00
//for links created purely for interaction - ignore
2011-04-04 17:00:24 +00:00
event . preventDefault ( ) ;
2011-02-18 21:46:28 +00:00
return ;
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
2011-04-18 23:13:50 +00:00
$activeClickedLink = $link . closest ( ".ui-btn" ) ;
2010-12-13 10:21:02 +00:00
2011-01-31 10:04:13 +00:00
if ( isExternal || hasAjaxDisabled || hasTarget || ! $ . mobile . ajaxEnabled ||
2011-01-24 00:03:35 +00:00
// TODO: deprecated - remove at 1.0
2011-04-29 12:22:03 +00:00
! $ . mobile . ajaxLinksEnabled ) {
2011-01-22 22:42:07 +00:00
//remove active link class if external (then it won't be there if you come back)
2011-04-29 01:12:01 +00:00
window . setTimeout ( function ( ) { removeActiveLinkClass ( true ) ; } , 200 ) ;
2010-12-13 10:21:02 +00:00
2011-03-25 23:22:31 +00:00
//use default click handling
return ;
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
2011-03-31 19:38:36 +00:00
//use ajax
2011-04-18 23:13:50 +00:00
var transition = $link . jqmData ( "transition" ) ,
2011-04-29 01:12:01 +00:00
direction = $link . jqmData ( "direction" ) ,
reverse = ( direction && direction === "reverse" ) ||
2011-03-31 19:38:36 +00:00
// deprecated - remove by 1.0
2011-04-18 23:13:50 +00:00
$link . jqmData ( "back" ) ;
2011-03-31 19:38:36 +00:00
//this may need to be more specific as we use data-rel more
2011-04-18 23:13:50 +00:00
nextPageRole = $link . attr ( "data-" + $ . mobile . ns + "rel" ) ;
2010-12-13 10:21:02 +00:00
2011-03-31 19:38:36 +00:00
//if it's a relative href, prefix href with base url
2011-04-29 12:22:03 +00:00
if ( path . isRelative ( url ) && ! hadProtocol ) {
2011-03-31 19:38:36 +00:00
url = path . makeAbsolute ( url ) ;
2010-11-25 11:13:51 +00:00
}
2011-03-31 19:38:36 +00:00
url = path . stripHash ( url ) ;
2011-04-19 04:45:23 +00:00
$ . mobile . changePage ( url , transition , reverse ) ;
2011-04-04 17:00:24 +00:00
event . preventDefault ( ) ;
2011-03-31 19:38:36 +00:00
} ) ;
2010-12-13 10:21:02 +00:00
//hashchange event handler
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
$window . bind ( "hashchange" , function ( e , triggered ) {
//find first page via hash
2011-01-26 00:36:42 +00:00
var to = path . stripHash ( location . hash ) ,
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//transition is false if it's the first page, undefined otherwise (and may be overridden by default)
transition = $ . mobile . urlHistory . stack . length === 0 ? false : undefined ;
2011-02-15 01:23:25 +00:00
2011-02-01 04:25:36 +00:00
//if listening is disabled (either globally or temporarily), or it's a dialog hash
2011-04-29 12:22:03 +00:00
if ( ! $ . mobile . hashListeningEnabled || ! urlHistory . ignoreNextHashChange ) {
if ( ! urlHistory . ignoreNextHashChange ) {
2011-02-01 04:56:56 +00:00
urlHistory . ignoreNextHashChange = true ;
2011-02-01 04:47:01 +00:00
}
2011-03-08 01:23:44 +00:00
return ;
}
2011-03-07 07:47:40 +00:00
2011-03-28 06:59:28 +00:00
// special case for dialogs
2011-04-29 12:22:03 +00:00
if ( urlHistory . stack . length > 1 && to . indexOf ( dialogHashKey ) > - 1 ) {
2011-03-28 06:59:28 +00:00
// If current active page is not a dialog skip the dialog and continue
// in the same direction
2011-04-29 01:12:01 +00:00
if ( ! $ . mobile . activePage . is ( ".ui-dialog" ) ) {
2011-03-28 06:59:28 +00:00
//determine if we're heading forward or backward and continue accordingly past
//the current dialog
urlHistory . directHashChange ( {
currentUrl : to ,
2011-04-29 12:22:03 +00:00
isBack : function ( ) {
window . history . back ( ) ;
} ,
isForward : function ( ) {
window . history . forward ( ) ;
}
2011-03-28 06:59:28 +00:00
} ) ;
2011-03-07 07:47:40 +00:00
2011-03-28 06:59:28 +00:00
// prevent changepage
return ;
} else {
2011-04-29 12:22:03 +00:00
var setTo = function ( ) {
2011-04-29 01:12:01 +00:00
to = $ . mobile . urlHistory . getActive ( ) . page ;
} ;
2011-03-28 06:59:28 +00:00
// if the current active page is a dialog and we're navigating
// to a dialog use the dialog objected saved in the stack
2011-04-29 01:12:01 +00:00
urlHistory . directHashChange ( {
currentUrl : to ,
isBack : setTo ,
isForward : setTo
} ) ;
2011-03-28 06:59:28 +00:00
}
2011-02-01 04:47:01 +00:00
}
2010-12-13 10:21:02 +00:00
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//if to is defined, load it
2011-04-29 12:22:03 +00:00
if ( to ) {
Refactored urlStack and updated dialog and page plugins to match. jQuery Mobile's internal history now attempts to follow the history menu when urls change from hashchange, even for changes that go multiple steps forward or back. The internal history stack is now pruned based on whether a user goes back and then changes direction, whereas before a back-button click would result in a pop off the history. Instead we now maintain an active index number in the history stack, which allows us to maintain references to transitions that are saved on pages reached through clicking the forward button as well. This fixes #636.
In the process, some other small changes should be noted:
urlStack is now urlHistory, a hash of methods and properties used for history stack management (stack, activeIndex, getActive, getPrev, getNext, addNew, clearForward, and listening Enabled). All these are documented inline and exposed on $.mobile.urlHistory (I'm not sure these will be publicly documented, but just exposed internally for plugins for now).
$.changePage has two argument changes: the "back" argument is now called "reverse"; this results in no change from an end-user standpoint, but reflects the fact that it only reverses the direction of a transition without affecting the internal history stack, and second, a new argument at the end defines whether changePage was called from a hashChange which makes that url open to history menu guessing.
2011-01-23 22:33:36 +00:00
$ . mobile . changePage ( to , transition , undefined , false , true ) ;
2011-04-29 01:12:01 +00:00
} else {
This commit includes simplifications to the hashchange event handling & changePage logic, which results in a few bug fixes and removal of some previous limitations. Details:
- jquery.mobile.core.js no longer creates pages from every page and dialog in the DOM automatically at domready. Instead, pages are created as they are referenced via changePage, which can speed up pageload in multi-page documents, and means local "dialogs" referenced via data-rel="dialog" no longer need a data-role="dialog" attribute when served.
- in changePage, "from" is now allowed to be undefined. This simplifies the logic involved in showing the first page, which never had a "from" page, and previously needed a custom pageChange workaround to accommodate that.
- The pageshow event is no longer used as a callback for returning false and preventing the $.mobile.activePage from being set to the newly shown page. In other words, a page always becomes $.mobile.activePage once its shown now (the only reason this was optional before was because of a dialog restriction that's no longer true)
- the hashchange event logic for showing a particular page is now greatly simplified. It either shows the page referenced in location.hash, or if there's no hash it changes to the first page in the dom. This means every pageshow (including the first one) now uses pageChange internally.
- the hashchange event listener is no longer disabled when ajaxEnabled == false. Doing this before prevented local non-ajax page navigation from working properly. To disable hashchange listening, use $.mobile.urlHistory.listeningEnabled. We might consider defining (or moving) this on the $.mobile hash later as well for easier access.
- The internal var $.mobile.startPage is now $.mobile.firstPage, because it's not necessarily the page you started on, but merely a reference to the first "page" in the dom.
- Back buttons are auto-added to every page after the first one you first visit (this includes generated pages, such as those in a multipage document or nested listviews). Keep in mind that a "back" button does not take the place of a standard "home" link, and when building an app with jQuery Mobile, it's good to make use of both (particularly on deep-linked pages). Fixes #908
2011-01-31 22:05:57 +00:00
//there's no hash, go to the first page in the dom
$ . mobile . changePage ( $ . mobile . firstPage , transition , true , false , true ) ;
2010-11-25 11:13:51 +00:00
}
2011-04-29 01:12:01 +00:00
} ) ;
2011-03-31 16:19:05 +00:00
2011-05-06 17:28:31 +00:00
} ) ( jQuery ) ;