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
* /
2010-11-25 11:13:51 +00:00
( function ( $ , undefined ) {
//define vars for interal use
var $window = $ ( window ) ,
$html = $ ( 'html' ) ,
$head = $ ( 'head' ) ,
//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
get : function ( newPath ) {
if ( newPath == undefined ) {
newPath = location . hash ;
}
2011-01-22 22:42:07 +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
2010-11-25 11:13:51 +00:00
getFilePath : function ( path ) {
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
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
2010-12-07 17:05:10 +00:00
origin : '' ,
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
setOrigin : function ( ) {
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-01-22 22:42:07 +00:00
//prefix a relative url with the current path
makeAbsolute : function ( url ) {
return path . get ( ) + url ;
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//return a url path with the window's location protocol/hostname removed
clean : function ( url ) {
return url . replace ( location . protocol + "//" + location . host , "" ) ;
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//just return the url without an initial #
stripHash : function ( url ) {
return url . replace ( /^#/ , "" ) ;
} ,
2011-01-31 06:03:30 +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
isExternal : function ( url ) {
return path . hasProtocol ( path . clean ( url ) ) ;
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
hasProtocol : function ( url ) {
return /^(:?\w+:)/ . test ( url ) ;
} ,
2011-01-31 06:03:30 +00:00
2011-01-22 22:42:07 +00:00
//check if the url is relative
isRelative : function ( url ) {
return /^[^\/|#]/ . test ( url ) && ! path . hasProtocol ( url ) ;
2011-01-31 07:43:53 +00:00
} ,
isEmbeddedPage : function ( url ) {
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
getActive : function ( ) {
return urlHistory . stack [ urlHistory . activeIndex ] ;
} ,
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
getPrev : function ( ) {
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
getNext : function ( ) {
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
addNew : function ( url , transition ) {
//if there's forward history, wipe it
if ( urlHistory . getNext ( ) ) {
urlHistory . clearForward ( ) ;
}
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 . stack . push ( { url : url , transition : transition } ) ;
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 . 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
clearForward : function ( ) {
urlHistory . stack = urlHistory . stack . slice ( 0 , urlHistory . activeIndex + 1 ) ;
} ,
2011-02-01 19:59:03 +00:00
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
dialogHashKey = "&ui-state=dialog" ;
2010-12-13 10:21:02 +00:00
2011-01-18 17:18:22 +00:00
//existing base tag?
var $base = $head . children ( "base" ) ,
hostURL = location . protocol + '//' + location . host ,
docLocation = path . get ( hostURL + location . pathname ) ,
docBase = docLocation ;
if ( $base . length ) {
var href = $base . attr ( "href" ) ;
if ( href ) {
if ( href . search ( /^[^:/]+:\/\/[^/]+\/?/ ) == - 1 ) {
//the href is not absolute, we need to turn it into one
//so that we can turn paths stored in our location hash into
//relative paths.
if ( href . charAt ( 0 ) == '/' ) {
//site relative url
docBase = hostURL + href ;
}
else {
//the href is a document relative url
docBase = docLocation + href ;
//XXX: we need some code here to calculate the final path
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
// just in case the docBase contains up-level (../) references.
2011-01-18 17:18:22 +00:00
}
}
else {
//the href is an absolute url
docBase = href ;
}
}
//make sure docBase ends with a slash
docBase = docBase + ( docBase . charAt ( docBase . length - 1 ) == '/' ? ' ' : '/' ) ;
}
//base element management, defined depending on dynamic base tag support
base = $ . support . dynamicBaseTag ? {
//define base element, for use in routing asset urls that are referenced in Ajax-requested markup
element : ( $base . length ? $base : $ ( "<base>" , { href : docBase } ) . prependTo ( $head ) ) ,
//set the generated BASE element's href attribute to a new page's base path
set : function ( href ) {
base . element . attr ( 'href' , docBase + path . get ( href ) ) ;
} ,
//set the generated BASE element's href attribute to a new page's base path
reset : function ( ) {
base . element . attr ( 'href' , docBase ) ;
}
} : 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
function reFocus ( page ) {
var pageTitle = page . find ( ".ui-title:eq(0)" ) ;
if ( pageTitle . length ) {
pageTitle . focus ( ) ;
}
else {
page . find ( focusable ) . eq ( 0 ) . focus ( ) ;
}
} ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//remove active classes after page transition or error
function removeActiveLinkClass ( forceRemoval ) {
if ( ! ! $activeClickedLink && ( ! $activeClickedLink . closest ( '.ui-page-active' ) . length || forceRemoval ) ) {
$activeClickedLink . removeClass ( $ . mobile . activeBtnClass ) ;
}
$activeClickedLink = null ;
} ;
//animation complete callback
$ . fn . animationComplete = function ( callback ) {
if ( $ . support . cssTransitions ) {
return $ ( this ) . one ( 'webkitAnimationEnd' , callback ) ;
}
else {
2011-01-30 23:06:33 +00:00
// defer execution for consistency between webkit/non webkit
2011-01-31 06:03:30 +00:00
setTimeout ( callback , 0 ) ;
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
2010-12-13 10:21:02 +00:00
// changepage 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
// TODO : consider moving args to an object hash
$ . mobile . changePage = function ( to , transition , reverse , changeHash , fromHashChange ) {
2010-11-25 11:13:51 +00:00
//from is always the currently viewed page
var toIsArray = $ . type ( to ) === "array" ,
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
toIsObject = $ . type ( to ) === "object" ,
2010-11-25 11:13:51 +00:00
from = toIsArray ? to [ 0 ] : $ . mobile . activePage ,
to = toIsArray ? to [ 1 ] : 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
url = fileUrl = $ . type ( to ) === "string" ? path . stripHash ( to ) : "" ,
2010-11-25 11:13:51 +00:00
data = undefined ,
type = 'get' ,
isFormRequest = false ,
duplicateCachedPage = null ,
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
currPage = urlHistory . getActive ( ) ,
back = false ,
forward = false ;
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")
if ( currPage && urlHistory . stack . length > 1 && currPage . url === url && ! toIsArray && ! toIsObject ) {
2010-12-03 22:07:39 +00:00
return ;
2011-01-31 06:03:30 +00:00
}
2011-02-01 19:52:15 +00:00
else if ( isPageTransitioning ) {
pageTransitionQueue . unshift ( arguments ) ;
return ;
}
isPageTransitioning = true ;
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 the changePage was sent from a hashChange event
// guess if it came from the history menu
if ( fromHashChange ) {
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
// check if url is in history and if it's ahead or behind current page
$ . each ( urlHistory . stack , function ( i ) {
//if the url is in the stack, it's a forward or a back
if ( this . url == url ) {
urlIndex = i ;
//define back and forward by whether url is older or newer than current page
back = i < urlHistory . activeIndex ;
//forward set to opposite of back
forward = ! back ;
//reset activeIndex to this one
urlHistory . activeIndex = i ;
}
} ) ;
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 it's a back, use reverse animation
if ( back ) {
reverse = true ;
transition = transition || currPage . transition ;
}
else if ( forward ) {
transition = transition || urlHistory . getActive ( ) . transition ;
}
2010-12-03 22:07:39 +00:00
}
2011-01-31 06:03:30 +00:00
2010-12-13 10:21:02 +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 ( toIsObject && to . url ) {
2010-11-25 11:13:51 +00:00
url = to . url ,
data = to . data ,
type = to . type ,
isFormRequest = true ;
//make get requests bookmarkable
if ( data && type == 'get' ) {
2011-01-27 03:04:36 +00:00
if ( $ . type ( data ) == "object" ) {
data = $ . param ( data ) ;
}
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
if ( base ) { base . reset ( ) ; }
2010-12-13 10:21:02 +00:00
2010-12-04 19:46:41 +00:00
//kill the keyboard
2011-02-02 05:11:16 +00:00
$ ( window . document . activeElement ) . add ( "input:focus, textarea:focus, select:focus" ) . blur ( ) ;
2010-12-13 10:21:02 +00:00
2010-12-17 03:12:47 +00:00
function defaultTransition ( ) {
if ( transition === undefined ) {
transition = $ . mobile . defaultTransition ;
}
}
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
2010-12-13 10:21:02 +00:00
var currScroll = $window . scrollTop ( ) ,
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
perspectiveTransitions = [ "flip" ] ,
2010-12-16 07:06:32 +00:00
pageContainerClasses = [ ] ;
2011-01-31 06:03:30 +00:00
//support deep-links to generated sub-pages
2011-01-26 19:38:17 +00:00
if ( url . indexOf ( "&" + $ . mobile . subPageUrlKey ) > - 1 ) {
2011-01-26 00:36:42 +00:00
to = $ ( "[data-url='" + url + "']" ) ;
}
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 ( from ) {
//set as data for returning to that spot
from . data ( "lastScroll" , currScroll ) ;
//trigger before show/hide events
from . data ( "page" ) . _trigger ( "beforehide" , { nextPage : to } ) ;
}
to . data ( "page" ) . _trigger ( "beforeshow" , { prevPage : from || $ ( "" ) } ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
function loadComplete ( ) {
2010-12-13 10:21:02 +00:00
2011-01-26 00:36:42 +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-01-31 06:03:30 +00:00
2011-01-26 19:38:17 +00:00
//add page to history stack if it's not back or forward
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 ( ! back && ! forward ) {
2011-01-26 00:36:42 +00:00
urlHistory . addNew ( url , 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
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.
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
$ . mobile . silentScroll ( to . data ( "lastScroll" ) ) ;
2011-01-31 22:33:25 +00:00
2011-01-27 01:41:30 +00:00
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
if ( from ) {
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
to . data ( "page" ) . _trigger ( "show" , null , { prevPage : from || $ ( "" ) } ) ;
//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
if ( duplicateCachedPage != null ) {
duplicateCachedPage . remove ( ) ;
}
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
isPageTransitioning = false
if ( pageTransitionQueue . length > 0 ) {
$ . mobile . changePage . apply ( $ . mobile , pageTransitionQueue . pop ( ) ) ;
}
2010-11-25 11:13:51 +00:00
} ;
2010-12-13 10:21:02 +00:00
function addContainerClass ( className ) {
$ . mobile . pageContainer . addClass ( className ) ;
pageContainerClasses . push ( className ) ;
} ;
function removeContainerClasses ( ) {
$ . mobile
. pageContainer
. removeClass ( pageContainerClasses . join ( " " ) ) ;
pageContainerClasses = [ ] ;
} ;
2011-01-31 06:03:30 +00:00
2010-12-13 10:21:02 +00:00
if ( transition && ( transition !== 'none' ) ) {
2011-01-27 01:41:30 +00:00
$ . mobile . pageLoading ( true ) ;
2011-01-22 19:04:04 +00:00
if ( $ . inArray ( transition , perspectiveTransitions ) >= 0 ) {
2010-12-13 10:21:02 +00:00
addContainerClass ( 'ui-mobile-viewport-perspective' ) ;
}
addContainerClass ( 'ui-mobile-viewport-transitioning' ) ;
2011-02-02 02:42:13 +00:00
if ( from ) {
from . addClass ( transition + " out " + ( reverse ? "reverse" : "" ) ) ;
}
to . addClass ( $ . mobile . activePageClass + " " + transition +
" in " + ( reverse ? "reverse" : "" ) ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
// callback - remove classes, etc
to . animationComplete ( function ( ) {
from . add ( to ) . removeClass ( "out in reverse " + transition ) ;
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 ( from ) {
from . removeClass ( $ . mobile . activePageClass ) ;
}
2010-11-25 11:13:51 +00:00
loadComplete ( ) ;
2010-12-13 10:21:02 +00:00
removeContainerClasses ( ) ;
2010-11-25 11:13:51 +00:00
} ) ;
}
else {
2011-01-27 01:41:30 +00:00
$ . mobile . pageLoading ( true ) ;
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 ( from ) {
from . removeClass ( $ . mobile . activePageClass ) ;
}
2010-11-25 11:13:51 +00:00
to . addClass ( $ . mobile . activePageClass ) ;
loadComplete ( ) ;
}
} ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//shared page enhancements
function enhancePage ( ) {
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//set next page role, if defined
2010-12-07 17:05:10 +00:00
if ( nextPageRole || to . data ( 'role' ) == 'dialog' ) {
2011-01-26 19:38:17 +00:00
url = urlHistory . getActive ( ) . url + dialogHashKey ;
2010-12-07 17:05:10 +00:00
if ( nextPageRole ) {
to . attr ( "data-role" , nextPageRole ) ;
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 ( ) ;
} ;
//if url is a string
if ( url ) {
2010-12-07 17:05:10 +00:00
to = $ ( "[data-url='" + url + "']" ) ;
2010-11-25 11:13:51 +00:00
fileUrl = path . getFilePath ( url ) ;
}
else { //find base url of element, if avail
2010-12-07 17:05:10 +00:00
var toID = to . attr ( 'data-url' ) ,
2010-11-25 11:13:51 +00:00
toIDfileurl = path . getFilePath ( toID ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
if ( toID != toIDfileurl ) {
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 ) {
if ( fileUrl && base ) {
base . set ( fileUrl ) ;
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
}
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
if ( to . length ) {
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 ,
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
var redirectLoc = / data-url="(.*)"/ . test ( html ) && RegExp . $1 ;
2011-01-25 00:35:45 +00:00
if ( redirectLoc ) {
2011-01-25 04:56:53 +00:00
if ( base ) {
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-01-25 04:56:53 +00:00
if ( base ) {
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-01-25 05:29:19 +00:00
var all = $ ( "<div></div>" ) ;
//workaround to allow scripts to execute when included in page divs
all . get ( 0 ) . innerHTML = html ;
to = all . find ( '[data-role="page"], [data-role="dialog"]' ) . first ( ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//rewrite src and href attrs to use a base url
if ( ! $ . support . dynamicBaseTag ) {
var newPath = path . get ( fileUrl ) ;
to . find ( '[src],link[href]' ) . each ( function ( ) {
var thisAttr = $ ( this ) . is ( '[href]' ) ? 'href' : 'src' ,
thisUrl = $ ( this ) . attr ( thisAttr ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//if full path exists and is same, chop it - helps IE out
thisUrl . replace ( location . protocol + '//' + location . host + location . pathname , '' ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
if ( ! /^(\w+:|#|\/)/ . test ( thisUrl ) ) {
$ ( this ) . attr ( thisAttr , newPath + thisUrl ) ;
}
} ) ;
}
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
. attr ( "data-url" , fileUrl )
. appendTo ( $ . mobile . pageContainer ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
enhancePage ( ) ;
2011-02-02 02:42:13 +00:00
setTimeout ( function ( ) { transitionPages ( ) } , 0 ) ;
2010-11-25 11:13:51 +00:00
} ,
error : function ( ) {
$ . mobile . pageLoading ( true ) ;
removeActiveLinkClass ( true ) ;
2011-02-02 19:10:40 +00:00
if ( base ) {
base . set ( path . get ( ) ) ;
}
2010-11-25 11:13:51 +00:00
$ ( "<div class='ui-loader ui-overlay-shadow ui-body-e ui-corner-all'><h1>Error Loading Page</h1></div>" )
. css ( { "display" : "block" , "opacity" : 0.96 , "top" : $ ( window ) . scrollTop ( ) + 100 } )
. appendTo ( $ . mobile . pageContainer )
. delay ( 800 )
. fadeOut ( 400 , function ( ) {
$ ( this ) . remove ( ) ;
} ) ;
}
} ) ;
}
} ;
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-01-22 22:42:07 +00:00
$ ( "form[data-ajax!='false']" ) . live ( 'submit' , function ( event ) {
2011-01-24 00:03:35 +00:00
if ( ! $ . mobile . ajaxEnabled ||
//TODO: deprecated - remove at 1.0
! $ . mobile . ajaxFormsEnabled ) { return ; }
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
var type = $ ( this ) . attr ( "method" ) ,
2011-01-22 22:42:07 +00:00
url = path . clean ( $ ( this ) . attr ( "action" ) ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//external submits use regular HTTP
2011-01-22 22:42:07 +00:00
if ( path . isExternal ( url ) ) {
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-01-22 22:42:07 +00:00
if ( path . isRelative ( url ) ) {
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 ( {
url : url ,
type : type ,
data : $ ( this ) . serialize ( )
} ,
undefined ,
undefined ,
true
) ;
event . preventDefault ( ) ;
2010-12-13 10:21:02 +00:00
} ) ;
2010-11-25 11:13:51 +00:00
//click routing - direct to HTTP or Ajax, accordingly
$ ( "a" ) . live ( "click" , function ( event ) {
2011-01-31 06:03:30 +00:00
2010-11-25 11:13:51 +00:00
var $this = $ ( this ) ,
2011-02-01 06:01:41 +00:00
//get href, if defined, otherwise fall to null #
href = $this . attr ( "href" ) || "#" ,
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
isRelExternal = $this . is ( "[rel='external']" ) ,
//rel set to external
isEmbeddedPage = path . isEmbeddedPage ( url ) ,
//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-01-31 08:13:01 +00:00
isExternal = path . isExternal ( url ) || 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-01-31 10:04:13 +00:00
hasTarget = $this . is ( "[target]" ) ,
//if data-ajax attr is set to false, use the default behavior of a link
hasAjaxDisabled = $this . is ( "[data-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
if ( $this . is ( "[data-rel='back']" ) ) {
window . history . back ( ) ;
return false ;
2011-01-31 06:03:30 +00:00
}
2011-01-22 22:42:07 +00:00
if ( url === "#" ) {
2010-11-25 11:13:51 +00:00
//for links created purely for interaction - ignore
return false ;
}
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
$activeClickedLink = $this . closest ( ".ui-btn" ) . addClass ( $ . mobile . activeBtnClass ) ;
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
! $ . 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)
2010-11-25 11:13:51 +00:00
removeActiveLinkClass ( true ) ;
2010-12-13 10:21:02 +00:00
2010-11-25 11:13:51 +00:00
//deliberately redirect, in case click was triggered
2011-01-22 22:42:07 +00:00
if ( hasTarget ) {
window . open ( url ) ;
2010-11-25 11:13:51 +00:00
}
2011-01-31 10:04:13 +00:00
else if ( hasAjaxDisabled ) {
return ;
}
2010-11-25 11:13:51 +00:00
else {
2011-01-22 22:42:07 +00:00
location . href = url ;
2010-11-25 11:13:51 +00:00
}
}
2010-12-13 10:21:02 +00:00
else {
2010-11-25 11:13:51 +00:00
//use ajax
var transition = $this . data ( "transition" ) ,
2011-01-23 23:12:46 +00:00
direction = $this . data ( "direction" ) ,
2011-01-31 06:03:30 +00:00
reverse = direction && direction == "reverse" ||
2011-01-23 23:12:46 +00:00
// deprecated - remove by 1.0
$this . data ( "back" ) ;
2011-01-31 06:03:30 +00:00
//this may need to be more specific as we use data-rel more
2010-12-13 10:21:02 +00:00
nextPageRole = $this . attr ( "data-rel" ) ;
2010-11-25 11:13:51 +00:00
//if it's a relative href, prefix href with base url
2011-01-22 22:42:07 +00:00
if ( path . isRelative ( url ) ) {
url = path . makeAbsolute ( url ) ;
2010-11-25 11:13:51 +00:00
}
2010-12-13 10:21:02 +00:00
2011-01-22 22:42:07 +00:00
url = path . stripHash ( url ) ;
2010-12-13 10:21:02 +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
$ . mobile . changePage ( url , transition , reverse ) ;
2010-11-25 11:13:51 +00:00
}
event . preventDefault ( ) ;
} ) ;
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-01 04:25:36 +00:00
//if listening is disabled (either globally or temporarily), or it's a dialog hash
2011-02-01 04:56:56 +00:00
if ( ! $ . mobile . hashListeningEnabled || ! urlHistory . ignoreNextHashChange ||
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
urlHistory . stack . length > 1 && to . indexOf ( dialogHashKey ) > - 1 && ! $ . mobile . activePage . is ( ".ui-dialog" )
2011-02-01 04:47:01 +00:00
) {
2011-02-01 04:56:56 +00:00
if ( ! urlHistory . ignoreNextHashChange ) {
urlHistory . ignoreNextHashChange = true ;
2011-02-01 04:47:01 +00:00
}
return ;
}
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
2010-11-25 11:13:51 +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 ) ;
2010-11-25 11:13:51 +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
//there's no hash, go to the first page in the dom
else {
$ . mobile . changePage ( $ . mobile . firstPage , transition , true , false , true ) ;
2010-11-25 11:13:51 +00:00
}
} ) ;
2011-01-11 22:12:07 +00:00
} ) ( jQuery ) ;
