So, given the opinion of Rails-core regarding the it's-a-feature-not-a-bug lack of access of the session to models, what has been the "rails way" of dealing with these cases:
-- stamping records with created_by and updated_by fields with user name or id
-- writing breadcrumb logs of user actions where user-specific details must be written per record
-- I have a third case, less common, that essentially puts records on "hold" -- in an attempt to cleanup after users who abandon these holds prior to completing the work for which the hold is originally secured, I maintain a list of what records are on hold and call a cleanup function when the user visits a page that clearly is an act of abandonment (otherwise the time experation eventually results in a release). I have always used the session to store the list (which requires that models be able to store to sessions).Pushing storage off to a database doesn't solve it -- the user & data still has to be correlated, and you're right back into a scenario just like the above two.
-- I have a pessimistic locking system that has worked very well for me that's very similar in behavior to the "hold" system
All I can see are fairly lame workarounds:
-- subclass ActiveRecord so I can bury the manual passing of the session into the model a layer away from the app code
-- extend ActiveRecord to modify save and update methods (basically same approach as above)
-- pass session or user details into abstracted save/update methods that have to be written/included for every model
All these are just monkey patches IMO that fake the appearance that "the framework" is handling those details like it does for created_at and updated_at.
Sure, allowing models to read/write to a session can be abused, but so can erb in a view, or every other aspect of programming. So what. IMO, a session is a system wide bucket for dealing with state. Why there's such a rabid opinion that it is solely the domain of the controller seems rather odd. Especially when it's exactly this kind of widely used pattern (connected record transactions to users) that I would expect a framework to embrace in enabling in the name of system-level integration for the greater good which trumps MVC extremism.
created_at is handled, so why not created_by? Because of implentation details? Well, if we had this thing that stored arbitrary data about the current user that each model in a given system could deal with on its own, we could... oh, wait. We do. Sessions.
However, I recognize that debate has long lost its luster in these halls, so, enlighten a poor, ignorant soul as to god's way of handling these scenarios.
Am I really supposed to pass these details along with every model modification call, or abstract my own layer to fake appearances?
I've never considered a way other than allowing a model to access a session as a system-wide resource, so seriously... what option am I not seeing (or just not accepting as the "correct" way in an MVC extremist world).
-- gw