Wes, I just re-read your reply. Sorry, mis-read it the first time. I
tried non-AR model, and the problem is that a non-AR model lacks the
magic that makes an AR model serializable. That is needed in order to
save the object in the session. Without that you just get an error
about trying to stick an unknown object type in the session.
Even if there is a relatively simple solution to that, the object would
have to be a child of Action Pack to be useful to me and also needs
access to all of the variables and methods of the conroller and view,
like a helper does.
A couple of points. One, thanks for helping me realize something that
happened to me almost a year ago. I put a non-AR object into the object
graph of an object that I was attempting to store in session and the
session marshaling failed. I always thought that it was because of the
size of that object, but now I am forced to consider/realize that it was
because AR provides that serialization for us. So thanks for that. If
you have any additional info. about how this actually works in AR, I’d
Secondly, you said “An AR model does not have (natively) any of the
Action Pack stuff that controllers and views need to get things done in
views. Something tells me that making an object that is both an AR and
an AP would be kind of
like “crossing the streams” in GhostBusters.”
I believe that your model in this case is the view configuration itself,
and therefore such a “hybrid AR/AP object” is totally valid. Think of
it as a “view model”. Your view has state and behavior that needs to be
managed, right? Just because this object isn’t like all of your other
models (i.e. “isn’t user data”) doesn’t mean that there isn’t a mini-MVC
world going on inside the “greater view,” if that makes sense.
In fact, even with relatively simple forms, we see view state issues
come up (fill in this field when that one is checked, etc.) that may
be/should be completely separate from the model behavior. In Rails, we
are encouraged to add methods to our model objects to manage this sort
of thing, but it is perfectly valid to argue for “view model” objects
whose purpose is to handle the state of the view.
As for your problem with how to persist such an object across requests,
I see three options:
Store all of this model metadata in the DB so that you can take
advantage of the session management provided by AR. I suspect that you
and I would agree if I said this feels like a “heavyweight” solution.
Determine how to emulate the session storage scheme of AR (to_yaml or
whatever needs to be done - BTW, I’d be interested in learning how to do
this myself). It seems reasonable to me that the session storage
mechanism should be unbound from the AR implementation anyhow, for just
Come up with another, custom scheme, for managing data storage that
persists across requests. I ended up doing this when I ran into this
problem (just a month into my Rails development) by implementing my own
hash and associated management.
The “right” thing to do feels like #2, but the “most possible” thing to
do feels like #3. #1 seems to be a bad choice only because you are
formally storing data that you only need for a few seconds minutes.
Having said that, you could totally do #1 and just be very strict about
how you manage those tables (lots of frequent cleanup, etc.).
I hope this helps. This is a great thread - I think it exposes some of
the (few) limitations of Rails at this point in time.