Routes that contain query strings are dysfunctional. I've fixed this in my branch, but as I'm quite inexperienced with the codebase I have no idea if my fix is fool-proof. In addition to ?, I allowed . character in the route pattern.

I'm just looking into a bug where if I go from a davis.js enabled page, to a normal page it correctly does a full page load, then hit back, the url changes and popstate is fired, but nothing happens. The 'normal' page does not have davis.js included, so I find it odd that it's trying to use it. Any ideas?

Capturing all clicks regardless of modifier keys breaks basic expected browser behavior, specifically allowing a new tab to be opened. Middle button mouse button still works as expected. This patch causes the davis listener to ignore ctrl+clicks on links, thereby restoring expected behavior.

Note: I am not sure if that's the correct modifier key for Mac OS. I'd appreciate if somebody with access to a Mac could verify that.

I was checking out Davis, and it looks like a really neat API. Thanks!

One thing I liked about Backbone Routing is that when a user visits http://localhost/foo/bar (or http://localhost/#/foo/bar) it will automatically discover which route it belongs to. Server side, we just render that page to the (index /) and then the JavaScript routes would call the correct listener.

Is Davis going to do something like that in the near future? The reason why I am asking, I am only using server side for RESTful / or WebSocket API, all the App runs client side, the server just spits out just the HTML5 and serves the basic JavaScript entry file. When a user visits a certain page directly, I just populate the models from the server into a JSON in the template so the models in client side will pick it up dynamically from page load.

Thanks!

It appears the parameters in request.params are already encoded. This is not what I was expecting. Is this correct behavior?

That is if I post with a request parameter /[email protected]

request.param['email'] == stuff%40crap.com 

I expect:

request.param['email'] == [email protected]

From what I gather is no wild card path support right? In other words you can't do something like the following:.

    var app = Davis(function () {
      this.get('/welcome/**', function (req) {
        alert("Hello " + req.params['name'])
      })
    })

"**" in this case means all paths and subpaths underneath '/wecome/' an example implementation in Java is here: http://static.springsource.org/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/web/util/AntPathRequestMatcher.html

I loved this plugin due to all features. but why does it call only default route when i use a bookmarked link. it works only and only with a tags like #something , is that a bug or you didnt add that feature. its crucial

This affects the latest version, 0.9.1.

A simple page showing this issue can be found here: http://goo.gl/42KGV

If I have a link with no matching route, usually it works well ... until I found that this doesn't work when the link has a query string attached.

a href="/blah.html?foo=bar"

will cause Davis to direct the browser to "/blah.html%3Ffoo=bar?foo=bar" instead of "/blah.html?foo=bar".

Maybe something changed in a recent version of chrome, but it seems this isn't working 100%.

These two situations have the exact same sequence of events as observed by the current Davis.history code, both on 64-bit Gentoo Linux:

1. This situation is in Firefox 10.0.4: -Load a page by typing in a URL (so there is no state associated) -Click a link to a route -Refresh the page -Click the back button

2. This situation is in Chrome 19.0.1084.52 -Load a page by typing in a URL (so there is no state associated) -Refresh the page

In both of these situations, onpopstate is fired, window.history.state == null and event.state == null, and they are both the first onpopstate received. It seems like the if statement at https://github.com/olivernn/davis.js/blob/master/lib/davis.history.js#L35 once may have helped differentiate this case, but it can't any more.

Was window.history.state once undefined in chrome?

The symptom of this is that in chrome, the route is fired twice on page refresh or initial load. I don't see an easy way to fix this without checking to see webkit or non-webkit. Any ideas?

Let's say I have an app with some get routes defined.

In some cases I need to manually trigger one of these routes by passing a path as string. I don't know which route it might belong to, so I need Davis to act as if a link has been clicked. I know there is state and trans methods available, but it doesn't cover my need.

How can I trigger/parse from within an app object or from outside that object?

I am using location.hash to keep track of where in a list a user is on the page.

The issue I am having is when I update location.hash it triggers the same route again.

Is this expected behavior? If so, is there a way to keep the route from being triggered if location.hash changes?

Hi,

Would it be possible to provide an official license file for davis.js? I see in the source it uses the MIT License, however the text needs to be completed with a year and author name.

https://en.wikipedia.org/wiki/MIT_License#License_terms

Thanks, Rob

In Firefox OS, We can use JS/HTML/CSS for app development.

Only difference is, it work with app:// protocol instead of http:// protocol

So, when I click on a <a href="/register"></a> then things are not working,

In normal browser setup,

Line number 1759 in Davis Router

   var route = self.lookupRoute(request.method, request.path);

here, request.path is equal to /register

But when I run the same code in FirefoxOS then

request.path is equal to app://3d97ccba-ab8c-4a3f-937f-fc894260b23c/register

So, Its a bug. I am digging more into it.

If routes are defined after the app has been instantiated, the routeCollection[] is empty, and as such forPageLoad request throws an error

To reproduce:

var router = Davis(function() {
  this.settings = {
    linkSelector: scope + ' a',
    formSelector: scope + ' form',
    generateRequestOnPageLoad: true,
    throwErrors: true,
    handleRouteNotFound: false,
  };
});

router.get('/post/:id', function());
router.start();