Forum: Ruby on Rails How do I alter posted data before it is saved in a controlle

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
summea (Guest)
on 2007-07-13 09:48
(Received via mailing list)
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

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 ( all
afternoon today... but still can't figure out why I can't alter a
posted variable.  Thanks for any help.

Kates Gasis (Guest)
on 2007-07-13 09:57
(Received via mailing list)
Use before_save filter in your model.

before_save :convert_to_lower

def convert_to_lower
#do you stuff here

summea (Guest)
on 2007-07-13 10:20
(Received via mailing list)
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,

Chris R. (Guest)
on 2007-07-13 12:55
It is the real way.

I recommend you buy the "Agile Web D. with Rails" book to speed
up your learning + understanding.
Brian H. (Guest)
on 2007-07-13 16:12
(Received via mailing list)
If the lower-casing of input from a web form is part of your business
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
your views and controllers as possible, pushing all logic back into the

This makes it easier to re-use your logic.  Say for example that you
developed another method to add posts, one that requires a new
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

Take a look at

These gentleman explain it much better than I ever could.

Good luck!

-Brian H.
Chris H. (Guest)
on 2007-07-13 16:52
(Received via mailing list)
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.
Tom A. (Guest)
on 2007-07-13 17:57
(Received via mailing list)
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.

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

@post =[:post)

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

@post =[:post])

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.
This topic is locked and can not be replied to.