alternate display of records

rubyonrails-talk
1

What is the current best practice for displaying records in alternate ways?

This relates to an internal scheduling app I'm trying to get off the ground for our photo studio. I have a model: Assignment I'd like the office manager to be able to get a sense of what time slots are available in the coming week when booking a new assignment. I hope to use Dan McGrady's WeeklyBuilder plugin. This plugin's index controller constrains the returned data to a five day range, and the index view presents it nicely in a week format using a specific stylesheet.

However, I can also see the need to just present a list of assignments, newest to oldest, using the app's generic application layout and stylesheet. (And maybe, if I get really ambitions, a month view.)

I don't object to having the default display of assignments be the weekly presentation because I feel that's likely to be the most used feature. But what would be the best practice to alternatively find all assignments and render them to a condensed list-like view using the application layout and stylesheet?

Thanks.

Steve

2

Have a look at the SearchLogic gem that will do all of what you ask.

3

Thank you for the tip heimdull. I'm clearly being dense here. I understand SearchLogic provides powerful search capabilities. I could use it to "search for all" and "search for a date range." I am still not clear on how best to then render results to alternate layouts?

4

You could use a parameter in the index url to specify which mode you want, then render a different view or use logic in the view to show it appropriately. Use partials for the common bits. Or is that not the question you are asking?

Colin

5

Thanks Colin;

Uh - I *think* that's the answer to the question I was asking. I guess more specifically, since you gave me two options, which is considered (current) best practice? Or are they both about equal and it's personal choice? Then I've got to figure out how to do what you suggested, but that's my problem, not yours. :wink: Thanks again. Steve

6

If you end up with any significant logic in the view then use a separate view. Of course there is yet another possibility which is to use a different controller for the alternative view, maybe with only the index action, and accessing the same model(s) as the original controller. If you think of this as a different view of the same data then this may not be the right route, but if you think of it as a different something_you_want_to_look_at that just happens to have the same underlying data as the first view then maybe this is the way to go.

If you can't decide on which way then pick on one of them and code it (don't forget to write the tests first or at least as you go), then try one of the alternatives. It should not be much work re-coding as the fundamental building blocks of the view will not change. Use a version control system to keep track of your code (I prefer git, as do most people now I think) so it is easy to backtrack to the original if you decide it is not working out nicely. You will know which solution is the best one when you get there, it will feel right.

Colin

7

Colin;

This one of the best answers I ever got from a question: "if you think of it as a different something_you_want_to_look_at that just happens to have the same underlying data as the first view" :smiley: I'm leaning toward the "different controller with only an index view" approach. I think it will be easiest if the calendar is rendered with a layout and stylesheet that is exclusive to that purpose rather than trying to shoehorn everything into a common layout/stylesheet. Thanks, and thanks for patiently outlining some strategy for getting there. I REALLY appreciate your time.

Steve

8

Glad to be of help

Colin