You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 8, 2021. It is now read-only.
If the user submits a form to: login.php and the login is sucessfull he must be redirected to home.php
How is it possible to update the hash to home.php ? Or maybe i'm doing something wrong with php, do you expect any particular header to update the hash ?
It is a quite common practice to redirect to another page after a form submission. At the moment the hash will always adopt the original path and not the redirected one.
I might be wrong about this but unfortunately there does not seem to be a way to intercept the redirect status in ajax calls so I'm not sure how easy this would be to implement.
It would be nice to have a workaround for this however - maybe a way to explicitly set the hash in the response markup, perhaps something like this:
I like the proposed workaround. I'm working on a commit that moves all page-level ID attribute usage over to a new data-url attribute. Maybe once that's implemented, we could make it so if a page arrives with data-url already set in the markup, we use that to set the hash.
I think you're right. The currentimplementation is limited to a url change relative to the page's parent directory, so basically, whatever you pass in data-url will be tacked on to the existing baseURL, allowing you to resolve directory trailing slash issues.
We should probably make sure that the data-url attribute replaces the current hash in full though, as you expect. I'll take a look now.
I have tried to implement my own version of supporting redirects by doing the following.
As described above I always set the data-url attribute server-side for pages.
In the loadPage success handler I verify that the request url matches the data-url of the incoming page.
a. If they match then continue as normal.
b. If it does not match then I look in the DOM to see if the incoming page already exists in the dom.
1) If yes, use the existing page and do not append the incoming page.
2) If no, append the newly loaded page into the DOM and use that. Then update all of the url variables (dataUrl, fileUrl, absUrl) to reflect that you are using the response url and not the request url
Activity
medovob commentedon Dec 3, 2010
I'm with you on this.
It is a quite common practice to redirect to another page after a form submission. At the moment the hash will always adopt the original path and not the redirected one.
I might be wrong about this but unfortunately there does not seem to be a way to intercept the redirect status in ajax calls so I'm not sure how easy this would be to implement.
It would be nice to have a workaround for this however - maybe a way to explicitly set the hash in the response markup, perhaps something like this:
scottjehl commentedon Dec 6, 2010
I like the proposed workaround. I'm working on a commit that moves all page-level ID attribute usage over to a new data-url attribute. Maybe once that's implemented, we could make it so if a page arrives with data-url already set in the markup, we use that to set the hash.
medovob commentedon Dec 7, 2010
Sounds good - thanks.
integer commentedon Feb 1, 2011
Maybe I found bug in this.
When I go from http://example.com/#/action/subaction/1954791
and in target page is
I get this URI http://example.com/#/action/subaction/1954791/anotherAction
but I want this: http://example.com/#/anotherAction
Is it bug or I use it in bad way?
Tested at ae8964f
scottjehl commentedon Feb 1, 2011
I think you're right. The currentimplementation is limited to a url change relative to the page's parent directory, so basically, whatever you pass in data-url will be tacked on to the existing baseURL, allowing you to resolve directory trailing slash issues.
We should probably make sure that the data-url attribute replaces the current hash in full though, as you expect. I'll take a look now.
scottjehl commentedon Feb 1, 2011
fixed bug where a preset data-url was being prefixed by the base url, rather than replacing the whole hash. Closed by 2c99787
trainiac commentedon Jun 24, 2011
I have tried to implement my own version of supporting redirects by doing the following.
a. If they match then continue as normal.
b. If it does not match then I look in the DOM to see if the incoming page already exists in the dom.
1) If yes, use the existing page and do not append the incoming page.
2) If no, append the newly loaded page into the DOM and use that. Then update all of the url variables (dataUrl, fileUrl, absUrl) to reflect that you are using the response url and not the request url
fixed bug where a preset data-url was being prefixed by the base url,…