Just to hopefully elaborate on things a bit here to help you out Jason
-
In Ruby, since it's literally a pure Object Oriented language,
generally you'll see functions referred to instead as "methods". Same
thing basically, just a nomenclature difference that could make things
easier in the future if you know about it :)
Brian has a good suggestion in terms of design - that kind of
functionality should belong in the model. However, there are some
simpler ways to do things, but it depends largely on how you have your
application set up.
As you're probably already aware, you can update your contact model
from within your controller like this:
def update
@contact = Contact.find(params[:id])
@contact.update_attributes(params[:contact])
end
This means you can pass in the "locked" flag in your form. However,
depending on how your application is set up, this COULD pose a
security risk. In Rails, there's a way to protect certain attributes
on a model from being set by a simple form:
class Contact < ActiveRecord::Base
attr_protected :locked
end
The attr_protected method will basically refuse to assign any value to
the attributes it's protecting if those values come out of a form or a
mass update (see "mass assignment" - Railscasts.com has a screencast
on it, if memory serves).
So the question then becomes, how do you securely update the locked
attribute? One way you could do it would be by adding a controller
action called "lock" and/or "unlock", but instead of allowing the
controller to do the work, call a new method you create on your
model. Here's an example:
class ContactsController < ActionController
def index
# ...
end
def show
# ...
end
def lock
@contact = Contact.find(params[:id])
if current_user.contacts.include?(@contact)
@contact.lock
end
end
def unlock
@contact = Contact.find(params[:id])
if current_user.contacts.include?(@contact)
@contact.unlock
end
end
end
class Contact < ActiveRecord::Base
# ... all your current model stuff
def lock
self.update_attribute(:locked, true)
end
def unlock
self.update_attribute(:locked, false)
end
end
To elaborate, the controller basically implements two new "actions" -
lock and unlock. Inside each, it looks for a current_user object
(this assumes your application has some form of authentication set up)
and says, "does current_user's contacts include the contact object we
just looked up in the database?" If so, the lock or unlock method is
called on that contact. If not, nothing happens. This effectively
makes sure that your contact is only updated by the user who owns it.
I recognize that this may seem a little like "beating around the bush"
in regards to your original question, so take a look at the lock and
unlock methods that I put in the contact class above. Generally
speaking, Brian's mentioned rule of thumb, which I've always heard
stated as "skinny controller, fat model", is the way to go. The basic
idea is to push as much functionality down to the model level as
possible, and allow your controllers to be as generic and lean as
possible. This is useful for situations where you may not want to
actually go through the controller - like, for example, using the
Rails console.
Anyway, these two methods just update the locked attribute to be
either true or false. In Ruby, it's a generally accepted "design
pattern" to create lots of small, short methods to do a few basic
things at a time. It's not uncommon at all to see lots of methods
that are only a few lines like this, that just set one or more
attributes at a time, possibly performing some form of custom
validation(s) along the way.
Hopefully this example helps you wrap your head around the situation a
little better. Good luck to you!
On Nov 16, 9:41 pm, Jason Hhh <[email protected]> wrote:
> Thanks Brian!
>
> --
> Posted viahttp://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
