Forums

I am playing around with app framework in 3.5.0pr1 and so far it looks promising.

However, I seem to have run into a problem with hash-based history in browsers that don't support the html5 history api (all versions of IE).

Here's the code I am using



The code works fine for HTML5 browsers (firefox, chrome etc), I get an alert on http://localhost/site/root/testpage and then I get a new history entry for http://localhost/site/root/testtest.

The problem is that when I try the code in IE, nothing happens. There is no alert, and I don't a new history entry for http://localhost/site/root/#/testtest.

Why is this happening, and how can I fix it?

Cheers

Hi ericf,

Thanks for the very helpful reply. I have switched from using to .

After some more testing, I realized that the document did not have a valid doc-type, so it was rendering in quirks mode in IE. This explained why YUI didn't work at all there. Setting a doctype fixed it, so I don't think there's a bug.

I do however have an additional query. Let's say the site root is http://site.com/site/root and I have . If a user in an HTML4 browser visits , I would like to have the history entry replaced with . Is this possible? If so, how can I go about doing this?

Currently the code will append the hash after the current url:

• User visits http://site.com/site/root/testtest/
• User clicks a link to http://site.com/site/root/somepage/
• The app framework intercepts that, but the url is now http://site.com/site/root/testtest/#/somepage/ when it should be http://site.com/site/root/#/somepage.

Any suggestions for fixing this?

John,

This is tricky to deal with, as you are finding it to be.

`Y.App` has a `serverRouting` attribute which will help you configure your app instance on how to route requests and which form of URLs to use. The API docs outline the three acceptable values for `serverRouting`:

http://stage.yuilibrary.com/yui/docs/ap ... verRouting

When building the Photos Near Me app I wanted all "requests" to be handled by my Y.App instance, and wanted it to use the best form of URLs depending on the browser's capabilities. This sounds similar to what you're looking for.

For PNM, I left `serverRouting` as its default value of `undefined`, this way HTML5 browsers will get full-path URLs while non HTML5 browsers will get hash-based ones.

This configuration posed the same issue you're running into. To overcome this I implemented some redirect logic on the server so any request that wasn't to "/" would redirect to "/" and tack on the extra path segments to the URL's hash fragment, i.e.:



Here is the specific Node.js server code that does this: https://github.com/ericf/photosnear.me/ ... .js#L21-31

The server is now sending all browsers to a hash-based URL. To get nice full-path URLs in HTML5 browsers, I simply call Y.App's `upgrade()` method which upgrades a hash-based URL to an HTML5 URL if necessary. In non-HTML5 browsers, this method is a noop.

Let me know if this pattern will work for you.

Yes. But like the docs say, if you can, you should set `serverRouting` to `true`. The tradeoff here is a degraded experience for people using non HTML5 browsers, i.e. they will experience full page reloads, but all users will get full-path URLs and search engines can spider it.

I feel this decision is very context specific. It involves understanding the differences between a website and web application, and whether its data is for everyone or specific to users.

If you're building a website and its data is for everyone, like a blog, then the goal of using Y.App (or simply Y.Pjax) is to enhance the experience and performance when possible. In this case, setting `serverRouting` to `true` is advised. All URLs will be full-path, the server loads the initial data, and search engines can spider the site.

If you're building a web application where each user has their own data, like a todo app, then you could use Y.App to contain all of the application logic with the server just providing a data API and persistence. In this case, leaving `serverRouting` `undefined` or explicitly setting it to `false` will cause all page "requests" to be handled by Y.App. All URLs will still be bookmarkable, the back/forward buttons will always work, it will be really performant, and since the user has to login, search engines cannot spider the site anyways.

If you're building something that blurs the lines between site vs. app and data for everyone vs. per user, like Twitter, a balanced approach is probably best, and it is always good to error on the site of `serverRouting` set to `true`.

I will be adding to Y.App's User Guide over the coming weeks to better outline the best practices and tradeoffs for the different ways to configure routing and URLs.

John,

I can confirm the behavior you're seeing in IE9, however I can also reproduce this behavior on any page I visit that uses hashes in the URL. Therefore it appears to be the way IE is handling manual changes to the hash in the URL bar and how those correspond to entries in its history.

Digging into the debugger and watching the `hashchange` events, after updating the hash in the address bar manually, I see the correct new and old values for the hash fragment. But once on the URL in step 3, when I click the back button, I'm sent back to the URL in step 1.

So I'm not sure if there is a work around, but let us know if you find something.