I was wandering why in books like Agile Web Development with Rails there's no mention to validates_whatever_of way of validating, all validation examples are done using validates :attr, :whatever => true ? I've just started learning Rails and this made me confused!
In Rails 2.x, where you would have said something like:
validates_presence_of :user_name
in 3.x, you now do:
validates :username, :presence => true
The old way is still supported, I think, but it is deprecated.
It's really just a different way of expressing the same thing. While older books and tutorials will use the former, it should be fairly simple to translate that to 3.x style. See http://api.rubyonrails.org/classes/ActiveModel/Validations/ClassMethods.html#method-i-validates for example.
The validates syntax is just a new shortcut for the same thing. It's especially useful when you're validating a bunch of attributes with similar limits. So this:
validates_presence_of :one
validates_presence_of :two
validates_presence_of :three
validates_presence_of :four
can be reduced to
validates :one, :two, :three, :four, :presence => true
It's also a nice, consistent interface to custom validators.
Related
I am building an accommodation booking website on rails and I am confused about one aspect of the models. So normally the way I know of building it is by having a Room model that has many Reservations and the Reservation model belongs to the Room model. Problem is that this time I want the visitor to be able to book multiple rooms on one reservation. Is the Room has many Reservations association correct for that usage? Can anyone help me find a way of building that, do I have to use a single form that makes multiple records? I am sorry for my ignorance, it's the first time a concept like this fall into my hands.
Thank you all very much
You essentially need to have a many-to-many relationship defined and rails has a couple options to do so.
One option is the has_and_belongs_to_many relationship, which you can read up on here. However, my preferred option is the has_many, through: [model] approach as such:
class Room
has_many :room_reservations
has_many :reservations, through: :room_reservations
end
class Reservation
has_many :room_reservations
has_many :rooms, through: :room_reservations
end
class RoomReservation
belongs_to :room
belongs_to :reservation
end
essentially you have an intermediate table to create the many-to-many join.
I am new to rails and unclear about how to efficiently display breadcrumbs on a multi model tree hierarchy. My app tree is 7 models/levels deep but I will illustrate with 3.
class One
has_many :twos
class Two
belongs_to :one
has_many :threes
class Three
belongs_to :two
For example, say I want breadcrumbs on a show three view (linking to the parent instances of two and one). I am currently using AR associations in the controller:
add breadcrumb #three.two
add breadcrumb #three.two.one
This works fine except two additional SQL queries are run (to retrieve the two and one ancestors).
How can I have breadcrumbs more efficiently?
[Unfortunately, the Ancestry gem only seems to work with one model but is the idea of serialising the breadcrumb into a column worth pursuing? This is such a basic requirement that I suspect I am over complicating this out of ignorance.]
If it is, what's its defence? And if it isn't, why isn't it?
I think it is declaring new neighbor, akin to delegation. OTOH, if it were possible, it might be getting a bit bad to do multiple :through levels... (Do I remember correctly that they made this possible lately?)
This is more of a conceptual question...
I'm starting on an app that will have a few roles (e.g. employee, manager, store_manager). Each role will view/edit/destroy in different ways from each other. When a manager is editing an employee the view will be very different than when a store_manager is editing.
My thinking was to namespace many of the models with the role. Like:
namespace :store_manger do
resources :users
resources :widgets
end
namespace :manager do
resources :users
resources :widgets
end
This seems to be a much cleaner method than creating all the if can? :update, #article all over the controllers and views.
So, is my thinking on track?
Are there any pitfalls to using this method that I need to be aware of?
Or, is there a better way to organize this?
You're correct, grouping different roles into the same view/controllers doesn't make much sense in this case since the views are all different. Even if you need to share views later on, you can just render the same layout.
Trying to use the will_paginate gem in rails 3, and I want to move as much of this business into the model as possible, however it seems difficult, and I haven't seen much on it. Usually, you would do something like:
Resource.where(:foo => :bar).paginate(:page => params[:page], :per_page => 10)
Is there anyway to get that params[:page] into the model? params isn't accessible there. My ideal would be to somehow work this into a scope.
The params are available in a method of a model if the method takes the params as a parameter and the params are passed to the model by the controller. However, it would be better to pass only the params[:page], because the model should not know anything about the params. See, for instance, this example.
Pagination is mostly not business logic: it's about how you present the data. Hence most code involved does not belong in a model. However, will_paginate provides convenience methods to obtain results 0-15, 15-30, ... of a model and coughing up those lists is simply an ability of an activerecord model, which is why it does belong there.