GitHub User: introspectif
Also, about Devise, it's an engine, so changing views or controllers is as simple as putting them directly in your app. With rails engines, what's in your app takes precedence over what's in the engine. If you have no view for X, the it takes it from the engine. If you do, it uses yours. I like the idea of building things from scratch (this is a great episode) and minimizing plugin bloat, but it's worth mentioning.
Since rails detects and rejects cookies that have been tampered with, could we just use the user id rather than the auth_token, and put it in a signed cookie? Or, since sessions seem to actually be signed cookies (no?), is there a way in rails to just directly extend the expiration of the session cookie (if there's nothing else we keep in the session that we want to expire sooner)?
So all assets get packaged together and sent in one file? I really hope that I didn't understand that correctly.
Let's say they all pages share the jQuery library, linked directly from Google. Normally the jQuery library would be cached and not downloaded on each page. In fact, if downloaded from Google for another site, it wouldn't be pulled for my site at all. And for any one page, only the JS necessary for that page would be downloaded (never all of it at once). Plus with separate asset files, aren't they downloaded in parallel? And if I update JS on one page, only that updated JS would get downloaded when viewing that page in Rails 3.0, but in 3.1 it seems like ALL of my JS gets pulled down again when any one JS file gets updated.
Really excellent. Related to what Bruno and Brian asked, any chance of a part III focused on authenticated apps?