olivernn / davis.js Goto Github PK

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?

When application code throws an exception, Davis catches and rethrows the exception. The Chrome console reports the exception as coming from Davis which it technically does, it would be more useful if the original stack trace was used.

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!

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".

Scope isn't applied to before and after methods in Davis.Router, making it confusing for path specific calls.

This works:

app = Davis(function(){
    this.scope('/myapp');

    this.before('/myapp', function(req){
        console.log('before /', req);
    });
    this.get('/', function(req){
        console.log('get /', req);
    });
});

While this should work:

app = Davis(function(){
    this.scope('/myapp');

    this.before('/', function(req){
        console.log('before /', req);
    });
    this.get('/', function(req){
        console.log('get /', req);
    });
});

The issue can be solved by changing filter method of Davis.Router to add scope to the path when there is 2 arguments.

It looks like linking an image instead of text breaks davis. Of course it degrades gracefully, but an error message briefly shows, and then the normal link is activated. I tried to trace the error message, but could not find it, even with a breakpoint. Have you seen this behavior?

As per docs, returning false in a matching before filter should stop the navigation. Matching routes are not executed, but the URL in the location bar is still changed.

Looking at the source code of the handleRequest function, the only thing that happens when a request is halted is that a requestHalted event is sent. Since handleRequest is called when Davis.location.onChange is triggered, the URL location change should be "undone" in some way.

Hi

I'm trying to be successful with Davis.js. Two things are not clear to me:

1. How to disable the default behavior?
   If I only write Davis() all links are being changed. E.g. when I click on one with href="about.html", it goes no longer to http://example.org/app/about.html, but instead happily goes to http://example.org/about.html.
2. Is it possible to use Davis.js without jQuery?

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?

You state that davis will currently fail hard in a browser that doesn't support HTML5 push state. Is it possible for davis to initially check the browser for support of push state, and if it doesn't support it just fallback to treating all links just normal links (exactly like what would happen without javascript enabled)?

It seems to me this would be very much preferable to failing hard in browsers without good HTML5 support, assuming testing for this capability is even possible. If this is crazy talk, please just let me know.

When using twitter bootstrap dropdowns (http://twitter.github.com/bootstrap/javascript.html#dropdowns) I've found that local links which are in menu section ignore davis completely.
After some not very deep searching I've found that changing binding to document.body helps to solve the problem:

...
Davis.$(document.body).delegate(this.settings.linkSelector, 'click', clickHandler)
...

I'm not a javascript guru to say why selector fails, but it behaves like that on all browsers that I've tested.

Thanks for the great library!

A common technique to avoid multiple submissions of a form by multiple clicks to the submit button is to disable the submit button when it's clicked, something like this:

  <button type="submit" onclick="this.disabled=true;">Submit</button>

This works fine in Firefox, both with and without Davis.js. But in Chrome and other browsers, it doesn't work at all because disabling the button halts form submission. A workaround to that is to do something like:

  <button type="submit" onclick="this.disabled=true; this.form.submit();">Submit</button>

That typically works fine without davis.js. However, when I'm using davis.js, it doesn't seem to handle the form submission, and instead a full page reload is triggered.

Is this a bug, or am I doing something wrong?

Is there an easy way to accomplish this without reusing the code in the prototype.run function? It doesn't seem like it, but I could be blind! I'm trying to programmatically redirect something, but change a parameter.

Lets say I have a form with method=post and action=/welcome

If I register the URL like:

    var app = Davis(function () {
      this.post('/welcome', function (req) {
        console.log(req.params);
      })
    })

I will get all the input parameters from the form (req.params). Which is nice degrading behavior.

However if use the ":pattern" I will only get the patterns matched as parameters. That is below I will only have the 'name' parameter as a request parameter.

    var app = Davis(function () {
      this.post('/welcome/:name', function (req) {
        console.log(req.params)
      })
    })

This seems like a bug.

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 /blah?email=[email protected]

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

I expect:

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

http://davisjs.com/plugins

1. Syntax error

var Davis.greeter = function () { // you can't have "var" there
    [...]
}

2. Looks like a constructor (it's capitalized), but there is no new.

var app = Davis(function () {
    [...]
}

Does it work with new?

3. Link to davis.fblike.js is labeled "Davis.noIOS".

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 have a case where it's taking me a little while to do something in the .before() request handler. Express.js's method for handling this kind of behavior is to either send a response or to call next(); I realize this might be a major feature request, but .before() is misleading because it doesn't actually wait to run any routes. It just does stuff sequentially, without any pause.

My example:

this.before(function (req) {
    // send a request to the server to see if user is authenticated
    // if user is authenticated, allow the route to continue (next())
    // if user is not authenticated, reroute them
});

The problem is, since it takes a split second to ping the server for this information (in my case, there's a reason to not just use local storage), IT ACTUALLY RENDERS THE ADMIN PAGE before rerouting. It's only a split second, but this is unfortunate. :(

Basically, 1) is there a next() concept in Davis.js, and 2) if not, why, and 3) can there be something like next() added?

When I include jquery.validation (http://bassistance.de/jquery-plugins/jquery-plugin-validation/) I find that davis.js no longer works. The routing code is not hit. No errors are raised.

I realize this is probably not an issue with davis.js, but I'm unsure how to resolve this. Any ideas?

Would be nice to have Component support built into davis.js. For now I went ahead and forked davis.js to enable support, but it we be best if it was directly supported. More info on Component:

https://github.com/component

Hi,
i use default demo with 2 links, and alert, now i included hash and title plugin. and my code is:

    <script type="text/javascript">
        Davis.extend(Davis.hashRouting({ prefix: "!"}));

        var app = Davis(function () {
            this.use(Davis.title);

            this.configure(function () {
                this.generateRequestOnPageLoad = true
            });
            this.get('/welcome/:name', function (req) {
                alert("Hello " + req.params['name']);
                this.setTitle(req.params['name']);
            });
        });

        app.start();

    </script>

        <a href="#!/welcome/oliver">greet oliver</a> //link 1
        <a href="#!/welcome/bob">greet bob</a> //link 1

now problem is when i click on link, it redirect me to: http://localhost/%23!/welcome/bob#!/welcome/bob
What is the problem ? :(

For example, if the user clicks a link or submits a form, maybe a "target" property of the Request Object would be that DOM element (i.e. the <form> or the <a href> element that triggered the route.

1. Assume there's an <input type="search" name="query"> inside a form that submits a GET request.
2. Set the value of the field to foo bar &zoo=goo.
3. Submit the form.
4. See the query part of the URL change to ?query=foo%20bar%20&zoo=goo instead of to
   ?query=foo+bar+%26zoo%3Dgoo (%20 instead of + would be fine as well, but the & and = characters need to be escaped).

Currently there are a couple of issues in the hashRouting extension, need to change the wrapper method to something like this:

var wrapper = function(request, setter) {
    setter("#" + options.prefix + request.location());
    lastPolledLocation = getLocation();
    invokeCallbacks(request);
};

I recently backported all of my custom hash location handling into the Davis.hashRouting extension.

https://github.com/jbaudanza/davis.js/blob/86e75bd1cd5b1e2219c5e3989e1a0bcea4035f1d/src/extensions/davis.hashRouting.js

I added the following functionality:

• Browsers that don't support the onhashchange event will poll for changes
• Implemented location.replace
• Created an optional location prefix, so you can do things like, "#!/foobar"
• On initialization, the current window.location value will be normalized to the correct scheme (if necessary)

I've also included some tests. Let me know what you think.

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

Links with href="?someparam=somevalue" aren't routed.

For instance in the Greeter application replacing the <input type="text" name="name"> with <input type="file" name="name"> causes the routing for this.post('/person', ...) not to get fired at all. All other types of inputs work as expected.

[This is not a bug]

How are people handling redirects?

My app for non pushstate browsers makes a request and gets back HTML. For pushstate it gets back the model as JSON and renders it with Mustache.

Now the only issue is that traditional FORMS you want to do a redirect after the POST. Although it sort of works my AJAX request for the JSON model will follow the redirect after POST (and then get served JSON) but strange things happen. Firebug for one gets screwed up. I also still have to manually tell the browser to redirect for pushstate.

So I'm thinking of just serving the form POST for pushstate browsers as JSON object that says redirect with out actually doing the redirect. Then do the redirect with the Davis (ie manually do the redirect).

Is that sound good? What do others do.

In Davis 0.6.0 the post routing seems somehow dysfunctional. In my fork of notepad using Davis 0.6.0 when saving the note, the this.post('/notes', ...) does not get fired but a POST request to server is made instead. In the current version using Davis 0.5.1 the POSTs work as intended.

In Internet Explorer 8, when using the html5 doctype and not specifying a document compatibility mode (by using the "X-UA-Compatible" header or meta-tag), hashRouting does not work. This is because in this situation, IE renders the page in Quirks mode and therefore does not support the hashChange event, even though the browser reports that it does. Explanation: http://stackoverflow.com/a/4029796

In the extension, the check whether the onhashchange is supported (davis.hashRouting.js, line 87), should be extended with the a check whether the Document Compatibility mode if IE is at least 8 (Document compatibility modes: http://msdn.microsoft.com/en-us/library/cc196988.aspx) so that it falls back to polling if it isn't.

Sample code to determine the Document Compatibility mode can be found here: http://msdn.microsoft.com/en-us/library/cc288325.aspx#GetMode

Of course, you could also tell people to specify the document compatibility mode when using the html5 doctype ;-)

Hey!

After playing around with Davis in one of your other projects I decided to use it on a new project from the outset, however I am experiencing a problem with iOS devices. I've tested this on iPhone 4 and iPad 3.

Davis correctly runs and attaches itself to links, when I click a routed link, the push state happens and all is well, however all subsequent links do not fire and no change of state happens.

It's relatively barebones so far so this is really all the code I can provide :)

var app = Davis(function() {

    this.use(Davis.googleAnalytics);

    this.get('/game/:game_id', function (req) {
        console.log("@ section " + req.params['game_id']);
    });

});

app.start();

As the originCheck checks against the host property of the hyperlink, (in some cases) the port number is included whereas it is not included in the host property of window.location.

I've fixed this by using the hostname property of the hyperlink in stead of the host property.

Also, I think the protocols should match so that linking to and from the https-secured site will result in a page refresh.

This would result in the following for line 220 of davis.js
return elem.hostname !== window.location.host || elem.protocol !== window.location.protocol

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.

Is there a way to reset or remove all routes that have been registered with Davis? Fanks!

• Daniel

In particular, this piece of router.js code fails to load:

var verbs = ['get', 'post', 'put'];
verbs.forEach(function (verb) {
  self[verb] = function (path, handler) {
    self._routeCollection.push(new Davis.Route (verb, path, handler));
  }
})

This generates a Object doesn't support this property or method error when the script loads.

forEach is a recent addition to ECMAscript, so this is probably an issue in other browsers as well.

There's a few ways to handle this. Let me know what you think. I'd be happy to put together a pull request.

Problem:
Fired duplication events on Android OS(Galaxy S2).

I test a simple way that is only 2 links on HTML.
Load JavaScripts are jQuery, Davis, Davis.hashRouting.

iOS and Desktop browser(based webkit) has not a problem.
Android OS only.

Uploaded the example source code to dropbox.
please put those files the document root at server. and access to index.html.
click a link home or job. fired duplication events on Android OS.

http://dl.dropbox.com/u/298712/external/sample.zip

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?

Hi,

The example fails to load the davis.js file with github returning a 404.

Thanks,

Iain

I've been seeing some error reports from inside of Davis.Request:

Uncaught TypeError: Cannot call method 'split' of undefined

which corresponds to this line:

this.queryString = raw.fullPath.split("?")[1];

I've only seen these errors come from Hoptoad. I haven't been able to reproduce locally from inside my app.

The only code path I can imagine this happening is when a Davis.Request object is constructed from event.state on a popstate event.

I've noticed this exact error happening in the test suite inside of the "binding and triggering the pop state event" test. Davis.Request doesn't know how to rebuild itself from "foo".

In general, I don't like writing defensive code, but I wonder if it makes sense to do some sanity checking on the data inside of event.state.

Chrome fires on initial popstate event, causing the page to render twice.

The logic uses an && when it should be an ||. As such it turns it off for all iOS

return uber() && (!match && majorVersionNumber > 4)

should be

return uber() && (!match || majorVersionNumber > 4)

Another one with back button. I've upgraded to davis 0.9.2, and applied my fixes. I'm finding that when I load the page, navigate to another page via html 5, hit back, then because history.state is null, it is not doing anything. I have debugged it and it appears my adjustments are not the cause. Any ideas?

Hello,

I am attempting to add a new route after I've started davis. I do this by adding davis to a parent object which is in the global scope, then later on in my application I called the following code:

var me = this;
Core.davis.get('/retread_templates/view/:id', function(){
    me.view(req.params['id']);
})

But when I click a link that looks like /retread_templates/view/40 the browser natively navigates to that location. Am I not supposed to be doing this? Should I define all routes when I create the initial instance? What is the best practice here?

Great library by the way.

The Davis.Request object doesn't seem to handle full URLs with hostnames.

For example, this is OK:

var req = new Davis.Request({ fullPath: '/hello', method: 'get' });
Davis.location.assign(req);

but this causes routing errors:

var req = new Davis.Request({ fullPath: 'http://www.example.com/hello', method: 'get' });
Davis.location.assign(req);

This is only an issue for me in IE7, which unfortunately translates all hrefs into non-relative URLs. For example:

>> document.write('<a href="/hello"> my link </a>')
>> $('a').attr('href')
http://www.example.com/hello

I solved this for myself by using a RegExp in my davis click handler to remove the http://hostname/ part.

It is conceivable that someone might have a legitimate href link with a full URL in it. It would be nice if Davis.Request would handle this gracefully. Let me know if you have any thoughts on this. I'd be happy to put together a pull request.

If you're interested, there is more information on the IE7 issue on this blog post. http://www.glennjones.net/2006/02/getattribute-href-bug/ He presents a workaround, but it doesn't work on dynamically created elements.

Currently when checking the origin of a link or form, to make sure it is for the current page location, there is an inconsitency in the check which means that if you are running on a port other than 80 it will assume the links are from a different origin.

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?

generateRequestOnPageLoad = true isn't working for me when using hash routing, likely because fullPath in Request.forPageLoad is set to Davis.location.current() which doesn't include the hash part.

Not a solution but a workaround for those stumbling on the same issue:

var app = Davis(function () {
    Davis.extend(Davis.hashRouting());

    this.bind('start', function() {
        var fullPath = document.location.pathname + document.location.hash;
        this.lookupRoute('get', fullPath).run(new Davis.Request({
            method: 'get',
            fullPath: fullPath,
            title: document.title,
            forPageLoad: true
        }));
    });

    this.get('/#/foo/bar', function(req) { ... });
}

Hi there,

Starting and stopping the app straight away doesn't actually stop it, this line still get executed:
Davis.$(function () { app.start() })

var app = Davis();
app.start();
app.stop(); // doesn't stop the app

Romu