makandra / active_type

Make any Ruby object quack like ActiveRecord
MIT License
1.09k stars 74 forks source link

Routes for nested models #30

Closed mhenrixon closed 9 years ago

mhenrixon commented 9 years ago

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.

mhenrixon commented 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.

triskweline commented 9 years ago

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.

mhenrixon commented 9 years ago

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?

triskweline commented 9 years ago

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.

mhenrixon commented 9 years ago

Thanks for taking the time to respond to my questions even though they are slightly out of scope for the gem. Really appreciate it!

triskweline commented 9 years ago

Sure. Good luck with your project.