Is Rails missing a rail-road tie?

It would be really delicious if that session store-ability aspect of AR
was available separate from AR.

It is. That's what the database is for. Create an AR object to store
your data, put the id, and only the id, in the session then load the
information you need from the database to service each request.

It sounds like you have code that tightly couples the business logic
to the view, break them apart now and save time and trouble down the
road. Then create a custom helper class that takes your database
object(s) and creates the view.

Aaron

Jeff,

I've run into problems in the past with storing objects in the
session. Inevitably you change the class and invalidate your session
objects. Then you are stuck migrating session objects or blowing them
all away (which might be ok in some cases). Whatever you want to
store in the session is data, and data can be put into a database.

That said, you can create your class in the helpers folder. Just
create a new file and put the class there (the file and class need to
have the same name - test_object.rb - class TestObject). This class
is accessible to controllers, views, and can be stored in the
session. I think the serialization method is "to_yaml" and this is
available to all objects. However, you may run into problems
serializing more complex objects.

Aaron

Aaron wrote:

It would be really delicious if that session store-ability aspect of AR
was available separate from AR.

It is. That's what the database is for. Create an AR object to store
your data, put the id, and only the id, in the session then load the
information you need from the database to service each request.

It sounds like you have code that tightly couples the business logic
to the view, break them apart now and save time and trouble down the
road. Then create a custom helper class that takes your database
object(s) and creates the view.

I agree with aaron... break it apart now... might be more work, but down the road you'll be better off. I've been coding Rails for just over a year (but 40+ hours/week) and the several times I've hit this wall and thought it really should be together after thinking it over some more I find a way around it that is better in the long run...

Suppose you were doing a web app that deals with user-created block
diagrams. The types of boxes and how they are connected and the label
for each box is all user data. That goes in the database.

Now, you write some view code that uses RMagick to draw these block
diagrams on the screen. Let's say that in different parts of the app
you are doing different things with the block diagrams. You may need to
have the labels act as ajax links that do something in one view and do
something else in another view. You might want to highlight all of the
decision points with some sort of CSS or different colored boxes in one
view and not do that in another view. And on an on. Same basic display
code in different views, but with context dependent differences.

In my implementation (analogous to the current problem), I would want to
write the display code once, and be able to configure it in various ways
in each place I use it. The question is, where does each instance of
the object keep this configuration data.

So, if I understand you right, you want this:

data object -> one view that is really smart

instead of:

data object -> many views that are mostly dumb

If I understand you correctly, you would put this configuration data in
the database. That doesn't make any sense to me. Maybe I'm just dense.

Might just be terminology... in your block diagrams above, I'd say put everything about the diagram into the database that you would need to draw it. So, boxes, the relationships b/n those boxes, what type of box, what's inside the box, etc.

Then have a variety of different views to display that diagram... one for HTML, one for RMagick, one for PDF, one for XML, etc.

Doing it this way means you can save a simple integer into the session to pull that record back out of the database.

-philip