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
on 2007-07-13 07:48
on 2007-07-13 07:57
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
on 2007-07-13 08:20
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
on 2007-07-13 10:55
It is the real way. I recommend you buy the "Agile Web Development with Rails" book to speed up your learning + understanding.
on 2007-07-13 14:12
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-cont... http://www.therailsway.com/2007/6/1/railsconf-reca... http://www.therailsway.com/2007/1/15/assetsgraphed-part-3 These gentleman explain it much better than I ever could. Good luck! -Brian Hogan
on 2007-07-13 14:52
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.
on 2007-07-13 15:57
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.