How do I alter posted data before it is saved in a controlle

Rails
1

Hi everyone,

I’m still new to Ruby and Ruby on Rails. I’ve worked with CakePHP for
quite a while though, so I’m happy to see that most of what I’ve
learned about CakePHP translates over (more or less,) in using Ruby on
Rails.

But I’m stuck. After reading numerous tutorials I still can’t find an
answer. My question is (like the title suggests,) “How do I alter
posted data before it is saved in a controller?”

For example, say I have a simple blog program using Ruby on Rails. I
understand how make a blog form (where one fills in a blog post…)
and then post (save) the blog post. What I don’t understand how to do
in Ruby is… how does one alter a value from a View that has been
posted to a Controller?

Why would I want to do this? Simple; what if I want to make a form
field all lowercase after it has been submitted by a user? Does
anyone know of a method I need to be using to make this happen? I’ve
been searching around the API (http://api.rubyonrails.org/) all
afternoon today… but still can’t figure out why I can’t alter a
posted variable. Thanks for any help.

Andy

2

Use before_save filter in your model.

before_save :convert_to_lower

def convert_to_lower
#do you stuff here
self.title.downcase!
end

Kates

3

Thanks for the quick reply!

And I’m just making sure… but is this the “real” way to do it? (Not
a hack, etc.)
Thanks again,

Andy

4

It is the real way.

I recommend you buy the “Agile Web D. with Rails” book to speed
up your learning + understanding.

5

If the lower-casing of input from a web form is part of your business
logic,
then it belongs in the model, thus the below method is correct. If you
follow the MVC design pattern strictly, you would have as little logic
in
your views and controllers as possible, pushing all logic back into the
models.

This makes it easier to re-use your logic. Say for example that you
have
developed another method to add posts, one that requires a new
controller.
By pushing this logic into the model, you avoid having to duplicate the
lower-casing of your field. Trivial I know, but it’s a good habit to
get
into.

Take a look at

http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers
http://www.therailsway.com/2007/1/15/assetsgraphed-part-3

These gentleman explain it much better than I ever could.

Good luck!

-Brian H.

6

if all you want to do is manipulate form or query data from the client
(not necessarily always model data), just modify the data in the
params hash

ex: title = params[:title].downcase

then do with it what you will.

however, if, as others have suggested, you want to manipulate the data
as part of your model’s business logic, the best place to do that is
in the model itself, as the previous example shows.

7

Andy -

all the form variables are available as part of the params hash;
depending on how your form is coded, either directly (eg
params[:title]) or nested under the key for the appropriate model (eg.
params[:post][:title]).

These are passed into your constructor when you make a new instance of
a class, prior to saving et, eg:

@post = Post.new(params[:post)
post.save

so, either, you can do as Chris said, to create a modified variable,
and then pass that into your new object. Or you can modify the object
directly:

@post = Post.new(params[:post])
@post.title.downcase!
post.save

or, you can as described above, use a filter in the model to run
code as an ActiveRecord callback.

The latter is correct, as mentioned, if that’s part of the behaviour
of that object (eg: a particular field should ALWAYS be downcase). If
it’s specific to the controller, you can probably get away with doing
it in the controller, but it probably isn’t.

The PHP frameworks I’ve looked at tend to have slightly more bloated
controllers than Rails; you want to be aiming for a skinny,
logic-light controller, if possible. But sometimes this isn’t always
possible, and if you’re having trouble making it that way, consider a
refactoring later on down the line.