In the Railscast dealing with Editing Multiple, Ryan shows how to edit multiple objects in batch with form_tag. Is there a good way to do this using simple_form?
The base-case for using form_for or simple_form_for helpers are to hand them an ActiveRecord model...
<%= form_for #zebra do |f| %>
...which doesn't work in this case because you're not creating a form for one single instance of an ActiveRecord model. In the RailsCast, this is why Ryan uses form_tag.
There isn't a simple_form_tag, but you can hand simple_form a :symbol instead. Check out this SO post to see how some folks approached a similar problem. Know that at that point, you're writing a lot of extra code for simple_form to do what the RailsCast code does instead, and you lose a lot of the built-in niceties of simple_form.
There might be really good reasons why you'd battle with simple_form in this non-ideal scenario. If it were me, I'd start with the RailsCast code, get it working, and worry about niceties second. :)
Related
I'm new to Ruby on Rails. In my erb files, is there any reason to use the div_for helper over just typing out the <div> tags and setting the properties as HTML? What advantage is there to using div_for, and is there a recommended best practice?
I think the main reason people use the div_for helper is because it can accept an array of ActiveRecord objects as an argument. That way it becomes a short-hand combination of a loop iterator and a tag generator.
<%= div_for(#people, :class => "foo") do |person| %>
<%= person.name %>
<% end %>
div_for does some "magic" for you, in that it sets the class and ID of the element it generates.
There is no reason to choose it over a simple <div> tag if you don't intend to use those properties, or intent to use different values for them.
There is no strong convention either way. I've been writing Rails code for years and have literally never used it, put it out of your mind, it doesn't matter. There are far, far more important decisions to make, like choosing erb or haml or slim, or deciding whether to adpot CoffeeScript. Decisions that will fundamentally alter the way you write Rails code.
In many cases, rails 'helpers' are like training wheels on a bicycle. They help when you are just starting out, but at some point, you jettison the training wheels and start doing wheelies, sliding skids, and jumping homemade ramps.
But helpers vary, some are so helpful you never get rid of them, others get in the way when you want to start doing wheelies.
If you find using any particular 'helper' is cramping your style, stop using it!
I'm creating a rails gem that adds functionality to Rails' fields_for method, and I'd like it to be callable from any form builder. To keep things concise, inheritable (from form_for, nested_fields_for, etc), and backwards-compatible, I'm beginning to think overriding the fields_for method is the best way to go about it.
I've not done this before though, and I can envision some ugly problems. Specifically:
I need to call the original fields_for method (via alias_method) in the new one. If Rails changes how that method works in the future, I'm guessing my gem will break all fields_for functionality(?)
If another gem overrides fields_for, I suspect either my or the other gems' fields_for method will be ignored(?)
In general, the idea of overwriting an existing rails method just seems pretty shifty.
I'm sure this is something other developers face, and I'm just wondering - what's the standard approach to overwriting rails methods? Is it a big taboo amongst better developers? Is there another approach to this sort of issue? Should I just sod my attempt for a concise, elegant solution and do it up with a different method name after all?
Any suggestions appreciated.
Rather than overriding your methods, I would take a page from simple_form and formtastic. Both of which effectively change the form_for method, but they create a new method on top.
<%= simple_form_for #model do |f| %>
<% end %>
This way you can delate out to form_for for everything you don't respond to, and stay insulated from method signature changes.
My form is nested so that a Cart has Products, which can have Features. I wish to be able to add features to products via checkboxes.
Upon submit, rails is creating the Cart record, but failing to use "accepts_nested_attributes_for" to complete the addition of nested records.
My form is very straight forward, and I'm not receiving any errors, it's just ignoring the fields. My fields look like this (within the form helper)
= f.fields_for :feature_line_items do |builder|
= builder.check_box :id
= builder.label :id, "Feature Label"
Thanks in advance, I'm kind of doubting this is even possible, and probably need to rethink my data architecture.
Try this episode in railscasts. Also I suggest using simple_form gem, it makes forms programming very simple and straight forward.
I hope that helped.
Take a look :
http://asciicasts.com/episodes/17-habtm-checkboxes
http://ramblings.gibberishcode.net/archives/rails-has-and-belongs-to-many-habtm-demystified/17
How am I supposed to write the forms for my models where I'm using globalize3 for translations. I cannot find any examples and I don't find any helpers in the code.
The idea would be to have everything in one form like
text_field :title
text_field :title_fr
text_field :title_en
etc....
Thanks for pointing me to some code examples.
It looks like everything I need is in batch_translations fork adapted to Rails3/Globalize3:
https://github.com/fidel/batch_translations
I don't know if I supposed to delete this question or leave it for the future. Moderators please decide :)
I'm pretty much a Rails beginner, at the moment developing a rather complex webapp in Rails 2.2.
So, in this webapp, there are "factories". Not the design pattern, mind you, actual factories (it's a game).
For each factory in a player's team, there are a bunch of options he can take.
Level of maintenance for the machinery
Rewards for workers
etc.
I have two problems with this:
These are all checkboxes, and the checkbox needs to be defaulted with the answer already stored in the db. What I mean is the check must be already in the box if the player already checked it (sorry if this passage is confusing).
This information is stored in multiple tables. The level of maintenance in a factory is saved in one table, while the performance bonus given to workers is in another one.
Can anyone help me with this? This is all way over my head.
Thanks all.
To understand question 1, keep it simple and pretend the attributes you want to access are in the factories table. The design pattern then is pretty simple:
Database schema:
create_table :factories do |t|
t.boolean :now_operating, :default => true, :null => false
...
Controller:
def edit
#factory = Factory.find(params[:id])
if request.post?
#factory.update_attributes(params[:factory])
end
end
View:
<% form_for :factory, #factory, :url => { :action => "edit" } do |f| %>
<%= f.checkbox :now_operating %>
...
You can do this with less code, in fact with none at all if you use RESTful resources and follow naming conventions, but this is a little too much magic to start off, because it conceals what rails is doing for you.
Namely: when the :get action loads an object matching the object name passed to form_for, rails will populate the form fields with that object's attribute values from the database. Then, when the client submits the form, rails encodes those fields into the request as params for that object, which you can then update in the :post action. See the official Rails Guide for a more detailed treatment.
I apologize if that was a little too basic, but it's important to get the basic pattern because the general approach to solving problem 2 is the same:
Load the objects in your :get action.
Render a form with the objects enclosed.
Save the params for each object.
There are several ways of actually doing this for forms with multiple objects. I suggest you see the various tutorials listed under Item 8, Building Complex Forms, in the Rails Guide.
Two last points to consider:
Do you really need those extra tables? If each maintenance row
contains attributes for a single
factory, it may make more sense to
just put the attributes in the
factory table and simplify your forms
and actions.
Attributes such as :maintenance_level might be more
appropriately represented as a
:string type with a radio_button in
the form to set the level.
if the child entities (level of maintenance, performace, etc) are linked to the Factory, then you can use nested model forms.
You can check some info about nested forms here, or just google "rails nested forms" and you'll get plenty of blog posts and tutorials.
--EDIT
Seeing that you added that you're using rails 2.2, you could try to use simple_forms or formtastic to create the nested forms (this is just a suggestion as I have no idea if it works). And I can only thing of setting the values manually to update the models.