Closed mhenrixon closed 9 years ago
Another thing I don't quite get is the need for the following:
class Account < ActiveRecord::Base
class Overview < ActiveRecord::Base
self.table_name = :vw_account_overview
belongs_to :account
has_one :player, through: :account
include Monetizer
end
end
I guess the need for the < ActiveRecord::Base
on the account class might be due to in what order our files are loaded. What surprised me the most was that it isn't a problem with eager_load = false
when I try it out locally. This is probably off topic and has nothing to do with the gem itself but it would be awesome if someone could shed some light on what is going on in that situation.
The gist you posted doesn't list a player_player... route or Players::PlayerLocksController and seems to work like you intended? What did you expect differently?
As for your second comment, if you lazy-load Account::Overview
before Account
, Account::Overview
will already have defined Account
(without inheritance). You need to either use class Account::Overview
to force Rails' autoloading to look for and load Account
, or or load classes in the correct order.
Thanks! Regarding the second thing I knew there was a difference between compact style and nesting. We will update accordingly. I've run into similar problems like that coverage won't work as it is now.
Regarding the first comment and the topic of the issue I guess the only real problem is that if I do
link_to 'Lock', [@player, lock]
Rails will try and use the full model name including namespaces and my question is really do you then avoid links like that and type the full thing `player_lock_path(player, lock) or do you force the model name to be something shorter or do you handle it at the route level or would you just take a hit with a route alias or maybe something totally different?
You could write your own version of polymorphic_url
that deletes duplicate words in path segment.
I personally don't bother with Rails' automagic route inference any more since making it work in 100% of all cases causes too much damage to more important code. I'd just write player_lock_path(@player, lock)
instead.
Thanks for taking the time to respond to my questions even though they are slightly out of scope for the gem. Really appreciate it!
Sure. Good luck with your project.
Hi,
I’ve read the book over and over and love it! I’ve studied active type and the book but there is one thing that isn’t entirely clear to me that I believe is missing in the book. The book lacks examples of how to setup routing for various scenarios and I’d like to hear more about how you solved that part. Specifically interested in how to solve the following https://gist.github.com/mhenrixon/2bc135e65a0099b3fb87
It doesn’t really matter how I try I can’t make it work without Players::PlayerLocksController or player_player_lock_path etc. It’s a shame the book was released without this section. Care to shed some light on this?
I’d really like to avoid PlayersPlayerLock or player_player_lock_path but before I go mental I thought it best to ask you guys organizing your applications like this how you solve the Player::Lock type of model in a routing/controller scenario.