C9's paging : How does it change the URL bar? | Tech Off

turrican
Condemnation without investigation is the height of ignorance! - Albert Einstein

Going to channel9.msdn.com , if I click next page, the URL bar becomes channel9.msdn.com/#Page=2 without the page reloading. Any idéa how it's done in terms of pure code?

My guess is perhaps a <a href="#Page2" onclick"<something ajax here>">Page2</a> ?

W3bbo
The Master of Baiters

The client script appends the fragment identifier (the "#foo" bit) for the sake of bookmarking and back-button support.

After (or while) it does this, it loads the content. The DOM enables scripts to see what the current fragment identifiers are so they can alter the page based on it. So you can bookmark a link like that and it'll reload the replies for page 2.

turrican
Condemnation without investigation is the height of ignorance! - Albert Einstein

In reply to W3bbo

#Aug 14th @ 5:12 PM

Thank you. ps. Thanks for getting me into validating my sites btw. Smiley

stevo_
Casablanca != Manchester

Should also note that doing pagination with "ajax" is a pretty dodgy design.. paging data that already exists on page, sure.. I did explain this the other day regarding how URLs can become very confusing.. remember if you do paging this way you need to be unobtrusive..

Personally I don't see the point of ajax pagination.. traditional paging is just as fast and even ie6 can transition between two pages without a "flash" that was seen on older browsers.. although there are rules to ensuring the 'flash' doesn't occur.. such as placing styles in the header, and delaying page manipulation scripts to just before the body end..

Sampy
"It's my timey-wimey detector. It beeps when there's stuff."

In reply to stevo_

#Aug 15th @ 2:37 AM

I'd say our solution is pretty easy to figure out URL wise. I'm actually proud of the "hackability" of our URLs.

The reason we put the #Page=X on there is to let you rely on standard browser gestures (back, forward, copy and paste link) while still getting nice AJAX behavior.

As for how we do it: it's built into ASP .Net AJAX with 3.5 SP1. We've had it longer than that but that was due to me performing some extraction on the futures file and shoehorning it into vanilla 3.5. It's actually why we would have broken on SP1 with out a few more tweaks from me. The good thing though is that all our calls into that API still work just fine. I just had to wrap my fragment in a if block that tested the existence of the function on the Sys.Application object and set the EnableHistory property on ScriptManager via reflection.

stevo_
Casablanca != Manchester

In reply to Sampy

#Aug 15th @ 1:54 PM

Theres no doubt that if you really must do ajax pagination, then using the fragment to describe state is the least that should happen.. I posted some examples the other day where doing this unobtrusively will inevitably lead to ugly urls.. here you won't get them because theres no real non-ajax pagination to fall back to.

I do see a reason you decided to use ajax so heavily on this site, the average page on this site does around 90 http requests, most of them are etagged and cache well, but the requests stacking up to get the headers still add up (especially considering that http sys is probably only able to concurrently push x amount of requests at once). The ajax requests are around 9 requests I think (maybe less), so thats great - but personally I would of looked to lower the requests overhead, and maybe ask if it was that important to implement ajax so obtrusively.. we're still really not anymore informed about why v4 was built the way it was..

Sampy
"It's my timey-wimey detector. It beeps when there's stuff."

In reply to stevo_

#Aug 15th @ 2:48 PM

We do have non-AJAX page URLs: ?Page=X. We don't have complex state we need to pass on our site so it works out pretty good.

If you noticed, our page requests come from multiple sites. All our images are offloaded to our CDN so your browser can have multiple connections open at once to the various servers. The site that runs our code only has to send you the HTML, CSS, and JS (it still sends you some images like avatars but we're working on that). The AJAX request is only 1 request. Now there may be addtional requests that are needed to render the result (avatars, preview images, inserted pictures, etc.) but the AJAX call itself is just one HTTP request that sends much less data than a full page refresh.

Now I know we have some issues for users outside the US since our servers are located in the US but C9 is one of the fastest sites I use on the net. At home, at work, even on vacation it's lightning fast and I can move around quickly. I think that's possible due to the AJAX and perf tuning we've done. We built it this way because we think it provides a great user experience for interacting with our content. Bugs aside, I think it does just that.

stevo_
Casablanca != Manchester

In reply to Sampy

#Aug 15th @ 4:07 PM

CDN's or not its still a request, I don't have any problems with that, but this:

http://channel9.msdn.com/forums/TechOff/?Page=3#Page=5

Is a pretty likely scenario on ch9, coming from a non-ajax client to an ajax client, ie - search engine results..

turrican
Condemnation without investigation is the height of ignorance! - Albert Einstein

In reply to stevo_

#Aug 16th @ 6:35 AM

Not exactly "good looking url" with two page vars. I personally hate paging. Not sure if they still have it but Live Search used to load content dynamically as you scrolled down. If this could work in all browsers would be nice but doubtful. Anyway, it was kind'a cool.

longnightmoon
crop_circles

In reply to Sampy

#Aug 15th @ 4:07 PM

Interesting, but where and how can you validate? I noticed that plugging in invalid page numbers has some interesting results. Try replaceing the page number with -1, or 0.

Sampy
"It's my timey-wimey detector. It beeps when there's stuff."

In reply to stevo_

#Aug 16th @ 6:35 AM

Yes it's still a request but getting the HTML and JS from us and the images from a CDN will load faster because your browser caps your outbound connections to a server to 2 as per the HTTP spec. If we spread out over a few servers, you'll see a perf gain. Also the CDN is globally distributed so it's faster. We've gotten the amount of requests and the size of them down pretty low I think. I don't really see how we can get them down a significant amount more without resorting to some crazier hacks.

Yup, still some work to do on that one. We can probably redirect you to the AJAX only URL when you come in with an AJAX supported client to a query parameter page URL.

As far as validation goes, we can do it in a few places: before we call the web service, on the server, after the service returns. Now there are probably plenty of places we're not doing that now but it's not like we're taking your credit card numbers or selling you anything so it's not the end of the world if you can make the site act funky by giving it crazy URLs.