lazylester's Profile

I totally agree, Igor.
I would have a ProductCollection model (not an AR model, but more of a form object wrapping the collection of Product objects) and a ProductCollectionController. It's much cleaner than forcing collection behaviour into the Product and ProductsController classes.

I use RSpec to test this in a standalone engine. See https://github.com/lazylester/error_pages_engine. This way I can run the tests in a production environment just for testing the engine, and my application's test suite runs as usual in test environment.
Also since this functionality comprises a controller and views, is unrelated to the application's main functionality, and may be included in multiple apps, it seems to be a perfect place to use the Rails engine concept.

@Bharat Ruparal
https://github.com/lazylester/error_pages_engine

In order to test the dynamic generation of error pages, you need to be in production environment, which is incompatible with running your entire test suite, normally in test environment.

Similarly hacking the config.consider_all_requests_local parameter may is not viable except as a short-term hack to see dynamic error pages operating in dev or test environment.

So I found it best to move the ErrorsController and associated views into a Rails engine... that way it can have a test suite of its own, running the tests in production environment.

What do I mean? Well the screencast is titled "Authentication in Rails 3.1", and yes, authentication means proving you are who you claim to be. But the sign-up procedure doesn't do that. (Does it? How?)

You say, Sean, that authentication means that you can modify your own resources and not other peoples. That's authorization, not authentication.

I'm not seeing how sign-up supports authentication. But I can be a bit dense sometimes! So be gentle!

I'm probably missing something obvious here. But what is the use case for the "sign up" authentication method?

If anyone can sign up and set up a password, isn't the site just as unprotected as a site with no password?

(sorry 'bout my weird sign-in ID.. not sure how to change it!)

Since engines are intended to be 'portable' between applications, the suggested strategy for handling the engine's migration files by copying may pose problems, as it'll always carry the encoded timestamp of the date/time when it was created.

Maybe the the timestamp prefix should be changed when copying to the 'current' (at the time of copying) timestamp prefix. Do you see any issues with that?

it seems as if another (malicious) user could revert an action by poking around using different (guessed) :ids, couldn't they?