Rails%203%20In%20Action

Classes outside your control
Forem::TopicsController and Forem::PostsController so that RSpec doesn’t barf
when you run your tests. There are also the helpers in spec/helpers and the models in
spec/models, which need to undergo similar changes.
Did you break anything? Let’s find out with bin/rspec spec:
2 examples, 0 failures
It doesn’t look like it, and that’s a good thing! Let’s commit this change to provide
yourself with a nice little checkpoint:
git add .
git commit -m "Added the ability to reply to posts"
Users of your engine are now able to add replies to topics created by themselves or
other users.
You’ve got a nice couple of features going for your engine, but they’re very inclusive.
You haven’t yet seen how to use the application’s User model to add authorship
to your topics and posts, nor any way of integrating this engine with your Ticketee
application. But never fear! That’s what the next two sections are for.
17.7 Classes outside your control
When creating an engine such as this one, you may want to rely on classes from the
application. To relate posts and topics to users within the application, you could do
this in the models:
belongs_to :user
But what if the concept of users in the application isn’t kept within a User model at
all? Then this would break. You could store a couple of common model names, such
as User, Person, or Account and check for those, but that’s prone to breakage as well.
Here we’ll cover the theory behind configuration options, which you can use to let
your engine know the application’s User model.
17.7.1 Engine configuration
Within this engine you’re going to want to reference the User model from your application
so that you are able to attribute posts and topics to whomever has created
them. However, there’s a catch: within the application, the model that refers to the
user in the system may not be called User! Therefore, you’re going to need to create a
way to inform the engine of what this class is called from within the application.
The best way to inform the engine about the User model would be to have a file
called config/initializers/forem.rb which will run when the application loads like all
other initializers. This file would contain a single line, which would tell the engine
what class represents users within this application, like this:
Forem::Engine.user_class = User
This configuration setting will then be maintained by your engine across requests, and
you’ll be able to reference Forem::Engine.user_class wherever you need it within
497