I'd like to have a drop down in my Rails form where users can select an area of a city, e.g. "Marchmont", "New Town", "Baberton" etc, when adding an order. I'd like that once they have made a selection, this will then be the default selection for the following times they use the form to add an order (so that they don't have to keep selecting it) but also that they can change their selection at any time. Hope that makes sense. I'm using the Simple Form gem. Thanks in advance! :)
#Steve
I will make a couple of assumptions.
1.) you know how to create forms within the rails templating engine.
2.) you understand how to create a dropdown menu using the Simple Form gem
So you have a couple of options based on what you actually want to accomplish. Based on what you are briefly describing, it sounds like you have some kind of an e-commerce/checkout situation that you want auto-completion to make it easier for a user.
there are a couple of approaches to storing this data.
Saving the user Data.
1.) Save it right on the user model under district_of_last_order
2.) Save it right on the order model that a user has_many orders. Then you can pull the first order's city district and select that
Personally I would lean on #2 as you probably want to be able to tightly couple the order with the user and saving that information twice is redundant since you can always do something like current_user.orders.first.district or whatever,
in your ERB where you build the form you can then do something along these lines:
<%= simple_form_for(#order) do |f| %>
... other input fields
<% if current_user.orders.first %>
<%= f.input as: :select selected: current_user.orders.first.district %>
<% else %>
<%= ... your regular dropdown menu here without the default %>
<% end %>
... rest of your form
If you have the option of using gems, I have had good results with select2-rails.
I want for every users to have only one row of data in a table named business. He can edit it for the second time.
Also i want to submit each column value separately using form_for but when i do like this when submitting the form for the second time for a different column entry, it goes to the second row making the previous row empty.
How can i achieve this?
Here is my code...
<%= form_for #new_business do |f| %>
<%= f.text_area :first_problem %>
<%= f.submit %>
<% end %>
A screenshot of the data table
Table data screenshot
Any help is appreciated as i am new to rails. Thanks.
One user can only have one business, you need to set relationship between them
In user.rb model
has_one :business
In business.rb model
belongs_to :user
For your second problem, i think you are not passing row id for which you want to update columns, so everytime it is creating a new entry for that column
It looks like your code snippet is from your new template (i.e. "app/views/businesses/new.html.erb"). This should only be used when you want a new object created. Your controller probably says something like
def new
#new_business = Business.new
end
When the form is submitted, the :create action in your controller gets called, which should create a new record in the database.
When you want to edit that object, you use an edit action in your controller that corresponds to an edit.html.erb view. Something like this in the controller:
def edit
#business = Business.find(params[:id])
end
with a similar form to the one you listed above in the view. When that form is submitted, it should route to an :update action in your controller, that updates the existing record in the database.
The tricky part about what you are trying to accomplish is limiting each user to only being able to create one record in the database. There are many ways to go about doing this, but the general idea would be to restrict the user's access to the new and create actions in the controller once they have already created a record. You can do that by using before_action (if using Rails 4.0 or greater) or before_filter (if using Rails < 4.0) to call a method that checks if a user has already created a record.
I've set in my model('Bambino') a multi-select field to assign a value to the string attribute 'status'. Find the code below from my form partial:
<%= f.select(:status, options_for_select([['segnalato','segnalato'],
['inserito','inserito'],['drop','drop'],['concluso','concluso']])) %>
When I want to edit my record the edit form does not give me back the previous stored value but sets automatically the default value to 'segnalato' (E.g.:if I create a new record setting the status to 'inserito' and after I want to edit the record I get the edit form with the default value of 'segnalato' while I am expecting to see in the field 'inserito').
In this way when you edit a record chances to make a data entry mistake are very high. Why so? Is there a way to retrieve the proper 'status' value that was assigned when the record was created? Thanks
Are you sure that #your_record.status is equal to one of those values? Check it out before any further debugging.
Whilst Andrey Deineko's answer is probably the one you want, there is a better way to achieve what you're doing: enum.
#app/models/bambino.rb
class Bambino < ActiveRecord::Base
enum status: ['segnalato', 'inserito', 'drop', 'concluso']
end
This will give you the ability to use the following:
<%= f.select :color, Banbino.status.to_a.map { |w| [w.humanize, w] } %>
This will store a number for the status, whilst allowing you to define what each number means. It won't do anything about loading a pre-selected object (that's what Andrey's answer will do), but will give you the ability to make your application & select more succinct.
I have a pretty standard use-case. I have a parent object and a list of child objects. I want to have a tabular form where I can edit all the children at once, as rows in the table. I also want to be able to insert one or more new rows, and on submit have them be created as new records.
When I use a fields_for to render a series of sub-forms for nested records related by has-many, rails generates field names e.g. parent[children_attributes][0][fieldname], parent[children_attributes][1][fieldname] and so on.
This causes Rack to parse a params hash that looks like:
{ "parent" => {
"children" => {
"0" => { ... },
"1" => { ... } } }
When passed a new (un-persisted) object, the same fields_for will generate a field name that looks like:
parent[children_attributes][][fieldname]
Note the [] with no index in it.
This cannot be posted in the same form with the fields containing [0], [1], etc. because Rack gets confused and raises
TypeError: expected Array (got Rack::Utils::KeySpaceConstrainedParams)
"OK", thinks I. "I'll just make sure all the fields use the [] form instead of the [index] form. But I can't figure out how to convince fields_for to do this consistently. Even if I give it an explicit field name prefix and object:
fields_for 'parent[children_attributes][]', child do |f| ...
So long as child is persisted, it will automatically modify the fieldnames so that they become e.g. parent[children_attributes][0][fieldname], while leaving fieldnames for new records as parent[children_attributes][][fieldname]. Once again, Rack barfs.
I'm at a loss. How the heck do I use standard Rails helpers like fields_for to submit multiple new records, along with existing records, have them be parsed as an array in the params, and have all the records lacking IDs be created as new records in the DB? Am I out of luck and I just have to generate all the field names manually?
As others have mentioned, the [] should contain a key for new records because otherwise it is mixing a hash with an array type. You can set this with the child_index option on fields_for.
f.fields_for :items, Item.new, child_index: "NEW_ITEM" # ...
I usually do this using the object_id instead to ensure it is unique in case there are multiple new items.
item = Item.new
f.fields_for :items, item, child_index: item.object_id # ...
Here's an abstract helper method that does this. This assumes there is a partial with the name of item_fields which it will render.
def link_to_add_fields(name, f, association)
new_object = f.object.send(association).klass.new
id = new_object.object_id
fields = f.fields_for(association, new_object, child_index: id) do |builder|
render(association.to_s.singularize + "_fields", f: builder)
end
link_to(name, '#', class: "add_fields", data: {id: id, fields: fields.gsub("\n", "")})
end
You can use it like this. The arguments are: the name of the link, the parent's form builder, and the name of the association on the parent model.
<%= link_to_add_fields "Add Item", f, :items %>
And here is some CoffeeScript to listen to the click event of that link, insert the fields, and update the object id with the current time to give it a unique key.
jQuery ->
$('form').on 'click', '.add_fields', (event) ->
time = new Date().getTime()
regexp = new RegExp($(this).data('id'), 'g')
$(this).before($(this).data('fields').replace(regexp, time))
event.preventDefault()
That code is taken from this RailsCasts Pro episode which requires a paid subscription. However, there is a full working example freely available on GitHub.
Update: I want to point out that inserting a child_index placeholder is not always necessary. If you do not want to use JavaScript to insert new records dynamically, you can build them up ahead of time:
def new
#project = Project.new
3.times { #project.items.build }
end
<%= f.fields_for :items do |builder| %>
Rails will automatically insert an index for the new records so it should just work.
So, I was not happy with the solution I saw most often, which was to generate a pseudo-index for new elements, either on the server or in client-side JS. This feels like a kludge, especially in light of the fact that Rails/Rack is perfectly capable of parsing lists of items so long as they all use empty brackets ([]) as the index. Here's an approximation of the code I wound up with:
# note that this is NOT f.fields_for.
fields_for 'parent[children_attributes][]', child, index: nil do |f|
f.label :name
f.text_field :name
# ...
end
Ending the field name prefix with [], coupled with the index: nil option, disables the index generation Rails so helpfully tries to provide for persisted objects. This snippet works for both new and saved objects. The resulting form parameters, since they consistently use [], are parsed into an array in the params:
params[:parent][:children_attributes] # => [{"name" => "..."}, {...}]
The Parent#children_attributes= method generated by accepts_nested_attributes_for :children deals with this array just fine, updating changed records, adding new ones (ones lacking an "id" key), and removing the ones with the "_destroy" key set.
I'm still bothered that Rails makes this so difficult, and that I had to revert to a hardcoded field name prefix string instead of using e.g. f.fields_for :children, index: nil. For the record, even doing the following:
f.fields_for :children, index: nil, child_index: nil do |f| ...
...fails to disable field index generation.
I'm considering writing a Rails patch to make this easier, but I don't know if enough people care or if it would even be accepted.
EDIT: User #Macario has clued me in to why Rails prefers explicit indices in field names: once you get into three layers of nested models, there needs to be a way to discriminate which second-level model a third-level attribute belongs to.
The common solution is to add a placeholder into [], and replace it with a unique number on inserting the snippet to the form. Timestamp works most of the time.
Maybe you should just cheat. Put the new records in a different faux attribute that is a decorator for the actual one.
parent[children_attributes][0][fieldname]
parent[new_children_attributes][][fieldname]
It's not pretty, but it should work. It might take some extra effort to support round-trips to the form for validation errors.
I've came across this user case in all my last proyects, and I expect this to continue, as julian7 pointed, it is necesary to provide a unique id inside the []. In my opinion this is better done via js. I've been dragging and improving a jquery plugin for dealing with this situations. It works with existing records and for adding new records but expects a certain markup and it degrades gracefully, heres the code and an example:
https://gist.github.com/3096634
Caveats for using the plugin:
The fields_for call should be wrapped in a <fieldset> with data-association attribute equal to the pluralized name of the model, and a class 'nested_models'.
an object should be built in the view just before calling fields_for.
the object fields perse should be wrapped in a <fieldset> with class "new" but only if the record is new (cant remember if I removed this requirement).
A checkbox for the '_destroy' attribute inside a label must exist, the plugin will use the label text to create a destroy link.
A link with class 'add_record' should exist within the fieldset.nested_models but outside the fieldset enclosing the model fields.
Appart from this nuisances its been working wonders for me.
After checking the gist this requirements must be clearer.
Please let me know if you improve on the code or if you use it :).
BTW, I was inspired by Ryan Bates first nested models screencast.
long post deleted
Ryan has an episode on this:
http://railscasts.com/episodes/196-nested-model-form-revised
It looks like you need to generate the unique index manually. Ryan uses the object_id for this.
I think you can make it work by including the id of the record as a hidden field
There is a gem called cocoon for doing this, I would go for a leaner mor DIY aproach but it was specifically built for this cases.
I'm working on a Rails form that will allow the user to edit the attributes of many objects of a class with a single submission. My initial instinct was to create an outer form_for block and then iterate through the items within it using fields_for.
However, there is no object that bears a one-many relation to the objects the form will modify, and so it seems to me that there is no object that would be correct to pass into form_for.
In any case, what I'd like to see is an example of a form that modifies multiple objects simultaneously without appealing to a "parent" object. Perhaps this will involve form_tag?
(Note: I'm working in haml, so answers in haml would be awesome though unnecessary.)
Well, having a parent object will make it easier.
For bulk updates of many objects, the key is to use the right input name so that rails will parse the params as a array, i.e.
#posts.each do |post|
fields_for "posts[#{post.id}]", post do |p|
p.text_field :name
p.hidden_field :id
end
end
Have a look at the generated html source to see what name attribute the text input gets. If this is done right, params[:posts] will now be a hash in the controller which you can then update.
http://railscasts.com/episodes/165-edit-multiple should be relevant too
There are some extra wrinkles to my actual situation, but here's some pseudocode that I hope will illustrate the approach I've taken:
= form_tag url_for(:controller => "the_controller",
:action => "update") do
#objects_to_be_updated.each do |object|
= check_box_tag "[desired_path][through_the][parameters_hash]", true, object.boolean_attibute
= text_field_tag "[another_path][through_the][parameters_hash]", object.text_attribute
end
end
And so on.
Using the _tag variants of the form helpers, which don't require association with an Active Record model, is a bit of a pain but also seems to give you more control over structure of the resulting parameters.