0

I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users

This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.

To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"

Paul Young
  • 1,489
  • 1
  • 15
  • 34

2 Answers2

0

You can turn on HTML5 History support in Spine like this:

Spine.Route.setup(history: true)

By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.

The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing

EDIT:

In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:

However, there are some things you need to be aware of when using the History API. Firstly, every URL you send to navigate() needs to have a real HTML representation. Although the browser won't request the new URL at that point, it will be requested if the page is subsequently reloaded. In other words you can't make up arbitrary URLs, like you can with hash fragments; every URL passed to the API needs to exist. One way of implementing this is with server side support.

When browsers request a URL (expecting a HTML response) you first make sure on server-side that the endpoint exists and is valid. Then you can just serve up the main application, which will read the URL, invoking the appropriate routes. For example, let's say your user navigates to http://example.com/users/1. On the server-side, you check that the URL /users/1 is valid, and that the User record with an ID of 1 exists. Then you can go ahead and just serve up the JavaScript application.

The caveat to this approach is that it doesn't give search engine crawlers any real content. If you want your application to be crawl-able, you'll have to detect crawler bot requests, and serve them a 'parallel universe of content'. That is beyond the scope of this documentation though.

It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.

fholgado
  • 390
  • 2
  • 10
  • I've read the docs so I'm aware of this already. I'm not sure that it applies in every situation since a route might not be related to a RESTful resource. In the case of Apache, what could be a potential solution? – Paul Young Apr 25 '12 at 01:50
  • You could probably come up with some sort of rewrite rule to pass the arguments of the route "/post/1" and redirect all traffic to an index page with something like ?route=/post/1. You would then have to interpret those arguments from spine and show the appropriate route. I would suggest you keep all your routing logic inside your application and stay away from doing a rewrite rule in Apache. – fholgado Apr 25 '12 at 02:57
  • Thanks, but I'm looking for a more specific answer. – Paul Young Apr 25 '12 at 13:57
  • If you can provide more details of what your stack looks like, it will make it a lot easier to get a specific way of achieving this. Knowing exactly what your stack looks like (is it a Spine app served using Rails? A self contained Spine app bundled with Hem?) will help you get a better answer. – fholgado Apr 25 '12 at 14:10
  • Right now it's a self contained app via "hem build" with Apache and a NoSQL database. – Paul Young Apr 26 '12 at 02:42
0

I used the following rewrites as explained in this article.

http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/

Paul Young
  • 1,489
  • 1
  • 15
  • 34