can split form_for into two parts?

[Soichi Ishida]

Rails 3.1.3

Is it possible to split form_for block into two parts?

More specifically, I want to create and save a model after filling
required fields.
But some of the fields are not required and unnecessary for the model.

<%= form_for(@foo) do |f| %>
f.field A
<% end %>

and form_tag updates the following select fields in form_for block with
JavaScript

<%= form_tag do %>
...
<% end %>

<%= form_for(@foo) do |f| %>
f.field B
<% end %>

Apparently if I hit the save button, it needs to save both field A and
B.

Thanks in advance.

soichi

--
Posted via http://www.ruby-forum.com/.

[Walter Lee Davis]

On Nov 15, 2012, at 1:15 AM, Soichi Ishida wrote:

> Rails 3.1.3
>
> Is it possible to split form_for block into two parts?
>
> More specifically, I want to create and save a model after filling
> required fields.
> But some of the fields are not required and unnecessary for the model.
>
> <%= form_for(@foo) do |f| %>
> f.field A
> <% end %>
>
> and form_tag updates the following select fields in form_for block with
> JavaScript
>
> <%= form_tag do %>
> ...
> <% end %>
>
> <%= form_for(@foo) do |f| %>
> f.field B
> <% end %>
>
> Apparently if I hit the save button, it needs to save both field A and
> B.

Are you sure they need to be two separate forms? If your view pseudocode is accurate, these would both post to the same controller method. You can simply hide the non-essential fields with JavaScript, and show them conditionally. If the field is submitted empty, that would not change your model, right? Likewise if there's a default value, that would also be present in the view, just not shown to the visitor.

<button id="show_options">Show Options</button>

f.field A

f.field B, :class => 'optional'

<script type="text/javascript">
var hidden_fields = $$('.optional').invoke('hide');
$('show_options').observe('click',
function(evt){
hidden_fields.invoke('toggle');
}
);
</script>

Walter

>
> Thanks in advance.
>
> soichi
>
> --
> Posted via http://www.ruby-forum.com/.
>

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Soichi Ishida]

> <button id="show_options">Show Options</button>
>
> f.field A
>
> f.field B, :class => 'optional'
>
> <script type="text/javascript">
> var hidden_fields = $$('.optional').invoke('hide');
> $('show_options').observe('click',
> function(evt){
> hidden_fields.invoke('toggle');
> }
> );
> </script>
>
> Walter

Oh, thanks. Simpler than I thought.

[Soichi Ishida]

Is there anyway to manipulate form_tag from controllers?

Like, in order to edit, _form.html.erb must to be filled with the values
for the model.
At the same time, there are some checkbox or radio buttons related to
the form, but they are not needed for the model directly.

I want to choose the values and fill those form_tag fields as well when
users click edit action.

[Colin Law]

On 16 November 2012 07:37, Soichi Ishida <li...@ruby-forum.com> wrote:
> Is there anyway to manipulate form_tag from controllers?
>
> Like, in order to edit, _form.html.erb must to be filled with the values
> for the model.
> At the same time, there are some checkbox or radio buttons related to
> the form, but they are not needed for the model directly.
>
> I want to choose the values and fill those form_tag fields as well when
> users click edit action.

You can put data in @variables in the controller and then access those
in the view to put whatever you like in the fields.

Colin

[Tony Thompson]

I think what you are looking for is fields_for. This let's you put data in a different part the params hash. This allows you to either get those fields out of the fields for a given model or allows you to update more than one model or a nest model cleanly.

While the Javascript example is clever, I would caution against as it breaks your MVC design pattern putting logic in your view. Doing inline programming as a matter of course will leave the application difficult to maintain over time. 

For this case, the Javascript does not sound necessary.