Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
Blair McKenzie schrieb: > What about situations where you want to tie history to something other > than a link click? e.g. changing the value in a select, or hitting enter > in a search text box Hi Blair, I understand that this may be desired. But the history relies on links to hashes (i.e. fragment identifiers) that are followed. I don't know of another way to do it. Creating a link with a hash on the fly may work, but you still don't have bookmark functionality (which is one goal I want to achieve). But I can think of a workaround. You could have a (dynamically created) link to an hash that also has a click event which triggers hitting enter in a search box. If an history event occures for that link the attached event is triggered anyway. By the way, I worked on the hijax concept I was talking about. Every link with a class "remote" will be hijacked: Before: After: with an click event attached that loads chapter-1.html via XHR into a defined element. IE support is on the way... -- Klaus ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
What about situations where you want to tie history to something other than a link click? e.g. changing the value in a select, or hitting enter in a search text boxBlairOn 10/19/06,
Mike Alsup <[EMAIL PROTECTED]> wrote:
Klaus,> $('a.hijax').history();>> jQuery.fn.history = function() {> return this.each(function() {> $(this).click(function(e) {> jQuery.history.setHash
('#' + this.href.split('#')[1]);> });> });> };This is looking very nice. I like this usage pattern.> Why not implement a better solution for being able to implement Hijax
> the easy way> ... snip ...> That concept would of course involve the back-end as well. There it must> be decided upon the "X-Requested-With" request header what to send back> (whole page or only the part of the page that needs to be updated.
I think this is the way to go. The original markup must have thecorrect urls so that the page degrades. I would consider that arequirement.I think it is also a requirement to make sure it is easy to change the
href that gets loaded (which you've done). That way I could achievethe desired results without X-Requested-With logic on the server.Using templates or SSI I could structure my docs so that a call to"
mydoc.html" returns the full page and a call to "mydoc-p1.html"returns paragraph one only. Using the plugin on your demo page Icould then rewire the anchor click events like:...$('#chapter').load('mydoc-p' + i '.html');
...Mike___jQuery mailing listdiscuss@jquery.comhttp://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
Klaus,
> $('a.hijax').history();
>
> jQuery.fn.history = function() {
> return this.each(function() {
> $(this).click(function(e) {
> jQuery.history.setHash('#' + this.href.split('#')[1]);
> });
> });
> };
This is looking very nice. I like this usage pattern.
> Why not implement a better solution for being able to implement Hijax
> the easy way
> ... snip ...
> That concept would of course involve the back-end as well. There it must
> be decided upon the "X-Requested-With" request header what to send back
> (whole page or only the part of the page that needs to be updated.
I think this is the way to go. The original markup must have the
correct urls so that the page degrades. I would consider that a
requirement.
I think it is also a requirement to make sure it is easy to change the
href that gets loaded (which you've done). That way I could achieve
the desired results without X-Requested-With logic on the server.
Using templates or SSI I could structure my docs so that a call to
"mydoc.html" returns the full page and a call to "mydoc-p1.html"
returns paragraph one only. Using the plugin on your demo page I
could then rewire the anchor click events like:
...
$('#chapter').load('mydoc-p' + i '.html');
...
Mike
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
> Then I intercept all these links, change the href value to hashes and > load on click the content from the URL of the initial href value via > XHR. Links that already have a hash in their URL won't load via XHR but > add to history (that is needed to stay compatible with tabs). That means you could still "abuse" the history plugin for links with meaningless hashes and have the history still working... -- Klaus ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
Paul Bakaus schrieb: > Hi Klaus, > > your idea is definitely worth trying out, sounds great to me! > By the way, I've found some (maybe?) bug in your current history > implementation. If you initalize the page for the first time, then click > a link, and then click the back button again, it will show you chapter 3 > instead of no chapters. Have you noticed the same? Hi Paul, yes, this is also related to my statement: "Also todo is to automatically show the appropriate part, if the hash in the url refers to some point in the history but I can borrow that from the tabs plugin as well." That wasn't expressed to clearly. But its actually the same bug, the initial page state has to be remembered, as well as the approbiate link has to be loaded if there's an hash in the url. Thanks for the feedback. -- Klaus ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
Hi Klaus,your idea is definitely worth trying out, sounds great to me!By the way, I've found some (maybe?) bug in your current history implementation. If you initalize the page for the first time, then click a link, and then click the back button again, it will show you chapter 3 instead of no chapters. Have you noticed the same?
2006/10/19, Klaus Hartl <[EMAIL PROTECTED]>:
Hi jQuerians,people demanded, so I started to extract the history functionality fromthe tabs plugin to make a standalone plugin out of it.Worked out so far:
http://stilbuero.de/jquery/history/http://stilbuero.de/jquery/tabs/It's still alpha, support for Firefox, Safari and Opera is there, IE notyet but will be added. Also todo is to automatically show the
appropriate part, if the hash in the url refers to some point in thehistory but I can borrow that from the tabs plugin as well.At the moment it works by hooking into links and adding an eventhandler, like (prototypical code, setHash is required by Safari):
$('a').click(function(e) { $.history.setHash('#' + this.href.split('#')[1], e);});That's ok for me, I think its important to be able to control whichlinks should be "observed" anyway. So the snippet above might become
$('a.hijax').history();withjQuery.fn.history = function() { return this.each(function() { $(this).click(function(e) { jQuery.history.setHash('#' + this.href.split
('#')[1]); }); });};Or maybe it is reasonable to use a custom event? I'd like that:$('a.hijax').bind('history', function() {...}).click(function() { $(this).trigger('history');
});Does that work?But:You all know, I'm all for unobtrusive JS and the concept of progressiveenhancement. I don't like having a link in my HTML like href="" which actually points nowhere with JS disabled.
Why not implement a better solution for being able to implement Hijaxthe easy way (like what the form module is already offering)?So the links stay as they are and point to an existing ressource:Then I intercept all these links, change the href value to hashes andload on click the content from the URL of the initial href value viaXHR. Links that already have a hash in their URL won't load via XHR but
add to history (that is needed to stay compatible with tabs).That would 1. result in history support (in most browsers) and 2. in anice gracefully degrading application with JS disabled or for browsers
not supported by jQuery. Totally unobtrusive.That concept would of course involve the back-end as well. There it mustbe decided upon the "X-Requested-With" request header what to send back(whole page or only the part of the page that needs to be updated.
What do you guys think? Feedback and ideas welcome...-- Klaus___jQuery mailing list
discuss@jquery.comhttp://jquery.com/discuss/-- Paul BakausWeb DeveloperHildastr. 35
79102 Freiburg
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
[jQuery] jQuery history plugin - from making the back button work to a more elaborate Hijax solution
Hi jQuerians,
people demanded, so I started to extract the history functionality from
the tabs plugin to make a standalone plugin out of it.
Worked out so far:
http://stilbuero.de/jquery/history/
http://stilbuero.de/jquery/tabs/
It's still alpha, support for Firefox, Safari and Opera is there, IE not
yet but will be added. Also todo is to automatically show the
appropriate part, if the hash in the url refers to some point in the
history but I can borrow that from the tabs plugin as well.
At the moment it works by hooking into links and adding an event
handler, like (prototypical code, setHash is required by Safari):
$('a').click(function(e) {
$.history.setHash('#' + this.href.split('#')[1], e);
});
That's ok for me, I think its important to be able to control which
links should be "observed" anyway. So the snippet above might become
$('a.hijax').history();
with
jQuery.fn.history = function() {
return this.each(function() {
$(this).click(function(e) {
jQuery.history.setHash('#' + this.href.split('#')[1]);
});
});
};
Or maybe it is reasonable to use a custom event? I'd like that:
$('a.hijax').bind('history', function() {...}).click(function() {
$(this).trigger('history');
});
Does that work?
But:
You all know, I'm all for unobtrusive JS and the concept of progressive
enhancement. I don't like having a link in my HTML like which actually points nowhere with JS disabled.
Why not implement a better solution for being able to implement Hijax
the easy way (like what the form module is already offering)?
So the links stay as they are and point to an existing ressource:
Then I intercept all these links, change the href value to hashes and
load on click the content from the URL of the initial href value via
XHR. Links that already have a hash in their URL won't load via XHR but
add to history (that is needed to stay compatible with tabs).
That would 1. result in history support (in most browsers) and 2. in a
nice gracefully degrading application with JS disabled or for browsers
not supported by jQuery. Totally unobtrusive.
That concept would of course involve the back-end as well. There it must
be decided upon the "X-Requested-With" request header what to send back
(whole page or only the part of the page that needs to be updated.
What do you guys think? Feedback and ideas welcome...
-- Klaus
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
