Is Rails missing a rail-road tie?

rubyonrails-talk
1

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

2

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

3

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