On Thursday, September 13, 2012 5:26:29 PM UTC-4, Xavier Noria wrote: > Constant autoloading in Rails does *not* emulate the constant name > resolution algorithm. But in this case it behaves as Ruby. > > Thanks! All of that was a great summary and I appreciate your time for making it so clear.
How I went down that bad road: Imagine a world where Rails constant resolution took the current module of the class that is referring to the class into account when def load_missing_constant(from_mod, const_name) was doing its thing, such that if you refer to a class from a controller that was in a module or a model that was in a module, it would get the one in the same module if it existed, if not then its parent module, etc. up to root. To refer to a class in the root module, a module call Root could exist to do Root::SomeClass. In this roller coaster ride through fantasyland... the following could happen (even though it won't, this is 200 proof unicorns and rainbows): * in the controller when it refers to a model class, it would look in its module then its parent, etc. on to the root (no) module * the would allow you to define a module with model behavior and then include it in both a root level model and maybe some other module, such that you could cherry pick models to override and put in a module directory that could have slight changes in the module version of the model. * by changing the standard serialization to just look at mass assignment attributes and associations to define what is serializable/deserializable/persistable with a few additions, you could have different views and not even have to define which models you are using in the controller, because the module would define those * this could get rid of the need for strong_parameters, activemodel:serializers, etc. to some extent similar to Roar, but using existing models in a very DRY way Anyway. Instead of this, I'm trying out roar-rails, and am in-process of creating default representers so that representers are only needed when the user doesn't want to use what they've defined via mass assignment security, etc. The only problem so far is that I had functionality to allow the user to specify some fields to be serialized into json (or limit them) via the request itself. That worked before when I was using as_json directly, but now to do that I would have to create new representer classes each time, which is not good because they would need to be new classes, and I was going to dup a default representer, change the name and use that, but that would build up classes that wouldn't go away. Will figure it out though... This is under development/may change/go away later and untested, but: https://github.com/garysweaver/restful_json/blob/3.0.0/lib/restful_json/roar/entity_representer.rb Right now there is no difference between default entity and collection representer. The reason I'm using roar/roar-rails vs. something else is to try to both persist JSON and (de)serialize json and support different views of the same model in a DRY way. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/Pod_QrUetwsJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
