When dealing with resources (e.g. users) different parts of the rails app refer to them in one of several ways, some capitalized/singular, some lowercase/plural etc. At times this seems logical (e.g. a method for several resources vs. just one) but at other times it seems arbitrary...
Is there any easy way of remembering how to access them from different parts of the app?
Most of the time, you will need to access different models across the app. And you would always access them with singular name with first letter uppercase'd like User, Tweet. Regarding controllers, I don't think so you would ever to access a controller from some other controller.
Remember, if are using raw SQL, and you want to access the table of a model, that would always be in plural and all lower case, like users for User, and tweets for Tweet.
Regarding routes, they are always accessed through lowercase words, and deciding whether singular or plural -- it depends upon the context.
If you are accessing all tweets, the route method will be tweets_path, and if want one tweet, then tweet_path(1) or edit_tweet_path(1) where 1 being the id of the tweet that you want to show or edit.
And for classes: everywhere in Rails, and generally speaking in Ruby, they would always be singular, and uppercase'd.
Related
In my Rails app, I currently have a parent resource 'developments' and a child resource 'lots'.
But I need to have different types of developments now, i.e. apartments, houses, townhouses that still associate with their own lots. These different types of developments need to have different fields on their forms.
What is the simplest and easiest way to handle this?
I've currently thought of these approaches:
add a new column dev_type_id integer to developments that is associated with a development type (i.e. 1 = apartments etc.) and then have that as a condition to render different fields of the form. The trouble with this is I don't know how to practically build it and pass through the id from the index view to the form path
have multiple forms for development with different fields on them. I'm not sure how to set the routes for this approach and if it would work in practice
Multiple parent resources to single child: split the development into separate scaffolds for apartment, houses etc. and have lots belong to all of them through has_and_belongs_to_many. This just seems like it might be really messy.
Multiple parent resources to multiple children: Complete restructure so that Apartments has child Apartment_lots, Townhouses has child Townhouse_lots etc. etc. This seems like it would work as intended, but there has to be a simpler way, right? But I can see the benefit of being able to really customise each for the future if I need to.
Any suggestions spoken from experience, the rails way or anything is really appreciated.
I have user model and boat model. User has many boats. Boat belongs to user. What i wonder is that, even though i did not nest the resources i am able to create a boat to logged in user. So my url becomes ..../boats.new2 (2 as user id) and it actually saves to user with an id number 2.
But as far as i know if i have nested resources it would become something like .../user/2/boats/1. Isn't it?.
I have not tried to #edit action any of the cases so not sure which one to use and their effects, is there any other advantages using any of them, or not nesting is wrong?
Nesting routes is not necessary in Rails. You can maintain the relationship between boats and users as long as you have the active record belongs_to and has_many methods defined in the model, along with the foreign keys in the db.
In general, you should nest resources if there is an obvious relationship between the objects, such as users and posts (or boats). It just makes more sense of your users and as an API structure.
In some cases, you might want to nest the relationship under something different, like a category name. For instance, your uri pattern could look like /sailboats/boats/1 or powerboats/boat/2. Bottom line is you should structure routes in a way that logical for the project's users and developers.
I am working on a rails application and i have 3 different user types. These users are potentially very different, so i created models for each of them. Now, they should be able to login thru a single form. So basically i want to say something like 'find_by_email("some_email")', but search over all three tables. It seems, though, that Rails expect you to call 'find_by' with a specific model, like Admin.find_by(). Any suggestions?
Try something like this and assuming that that the email is unique across all the tables
[Model1, Model2, Model3].each do |model|
break if model.find_by_email("email#email.com").present?
end
Hopefully this is early in your development, but the current structure may not be the best possible route. How many different columns are NOT shared by each of the user types? You may want to use a "user role" system, and have that simply be an extra column on your user table.
Than, you can use something like CanCan to manage those roles and what/where they may access.
I have two models, Book and Chapter.
I would like chapters to be accessed by their order in the book rather that their id's
/Books/the-chapter-title/chapters/1
Would it be recommended to do this as I would like to also have the ability to reorder the chapters.
I would like the chapter numbers to move up and down the list using acts-as-list but also access them via their pecking order.
you can add a to_params method in your model if you want to use something other than id, but this usually leads to headaches
check out https://github.com/norman/friendly_id
In my app there're objects, and they belong to countries, regions, cities, types, groups, companies and other sets. Every set is rather simple - it has id, name and sometimes some pointers to other sets, and it never changes. Some sets are small and I load them in before_filter like that:
#countries = Country.all
#regions = Region.all
But then I call, for example,
offer.country.name
or
region.country.name
and my app performs a separate db query-by-id, although I've already loaded them all. After that I perform query through :include, and this case ids, generated by eager loading, do not depend on either I've already loaded this data with another query-by-id or not.
So I want some cache. For example, I may generate hashes with keys as records-ids in my before_filter and then call #countries[offer.country_id].name. This case it seems I don't need eager loading and it's easy turn on Rails.cache here. But maybe there's some smart built-in rails solution that does not require to rewrite everything?
Caching lists of models like that won't cache individual instances of that exist in other model's associations.
The Rails team has worked on implementing Identity Maps in Rails 3.1 to solve this exact problem, but it is disabled by default for now. You can enable it and see if it works for your problem.