RailsCasts Pro episodes are now free!
Learn more or hide this
GitHub User: rupert654
There is a faye-rails gem which makes integration much easier.
Just put this in your routes file:
faye_server '/faye', timeout: 25 do
and then this in your application.js
\\= require faye-browser-min
Browse to localhost:9292 and you should find everything works.
Any gem is infinitely flexible in the sense you can always monkey patch your own way of doing things on top of the gem code. The difference in flexibility between gems is in the ease of which they can be customised, not the extent.
Devise just isn't intended for massive customisation. It fulfils the most common use case for authentication systems. This is great because it means you don't have to code very much if this suits you. It is also sufficiently easy to change that you know if you need something more complex down the road, you won't have to rip it out in favour of a different system. However, I don't think you should be using it with the intention of doing all that customisation.
However, if you already know to begin with that you will need to replace the Devise views and controllers (and to be honest, I haven't yet found a situation where this isn't true), then you will have a much easier time with Sorcery.
Sorcery also has the advantage of having a very small public API meaning it is much easier and faster to learn than Devise.
Devise has much better documentation, much better guides on using it with associated gems such as CanCan and a larger community so better support. It is also older and so is more dependable.
@Dmitri @Nicolas: Firstly, I find that learning a new syntax happens with very little effort. For CS, I read a few blog posts upon encountering it and this took perhaps an hour. Then I learn the syntax as I use it and this means I might occasionally have to look up the reference when I get a compile error and can't work out what I have done wrong. Initially this does add some time to development but only a very minimal 5 minutes here and there. Consequently, I don't buy the argument that the difficulty in learning CS is so great, it overwhelms any benefits.
Secondly, I see no reason to treat myself as a human compiler. If I am repeating the same stuff again and again, it is a sign that something could be done programmatically. Unfortunately, this is not always viable in an interpreted language where speed is such an important factor. Additionally, it is difficult to update a language on the client side so where clear improvements are identified, they remain unusable to the developer. CS solves both of these problems. For example, see destructured assignment.
Thirdly, I don't like CS just because it is "prettier". I can take or leave the new function syntax for example. What I do like are the abstractions that clearly make sense and are more readable than the JS alternative. Default arguments, variable safety, splats and comprehensions are enough reason for me to use CS. However, I do like all of the more sugary stuff as well.
You could use Faye to allow live updating of the browser as you edit your code.
1) Setup watchr to watch your files (I suggest SASS and HAML) and get it to execute a curl request (crude but effective) when they change.
2) Get Faye to reload the page when it receives the message from watchr.
3) Start editing and watch the page update as you save!
@Nick: Thanks but that doesn't work for me on Chrome 10, unfortunately.
Under what circumstances will e.state be undefined? As far as I can see, on an initial page load, e.state is defined with a value of null.
If I replace //actions here with console.log('hello'), I get hello on the console under the following circumstances:
* Initial page load
* Use of back/forward buttons, after some AJAX calls
* On any other action in the controller, such as show.
Also, so far as I can see, the event from onpopstate is identical to event.originalEvent when using bind.
According to this source, http://www.splefty.com/js/popstate.html, the popstate event is supposed to fire on every page load for various reasons. This means in order to get rid of the unnecessary requests, we need to hook onto the popstate event such that our code only runs when the popstate fires AND the user has clicked the back/forward buttons.
So far it looks like the events are identical (and therefore indiscernible) unless you pass an object to the first argument of pushState. This object gets put onto the state property of the event object but only when the back/forward button is pressed and not on page load.
Unfortunately, an object only gets associated with a page when pushState is called and when you first visit a page, the state will be null. Thus if a user clicks on two links which make calls to pushState (with an object passed to state), and then clicks back twice, the first popstate event will have a state object but the second will still be null. This is because you will be back on the original page and the original page was accessed through a normal page load, not push state.
This means we still can't categorically distinguish between a page that has been reached after pushState and one that has been reached normally.
In Google Chrome 10, I'm getting a problem where an extra get request is made for every single action on my controller for a JS template. This doesn't result in any visible errors but the extra request can be seen in, for example, Firebug or Mongrel. The server returns a 500 error on every action apart from the index action. Only the JS request is made when an AJAX call is made.
The problem is that the code inside the function binded to "popstate" is being executed on page load. This can be seen more clearly if you replace the getScript with console.log('hello').
Is anybody else experiencing this behaviour? I'll post again if I find a fix.