Form_tag not producing output

I’ve got two servers, both with Rails 1.1.6 on them. I’m trying to
remove some of the newly-deprecated stuff in my app, and I’ve run into
a problem. My login page used to look like this:

Please Sign In

<%= start_form_tag :action => ‘login’ %>

<label for="user_login">Login:</label><br/>
<input type="text" name="user_login" id="user_login" size="30"

value=""/>

<label for="user_password">Password:</label><br/>
<input type="password" name="user_password" id="user_password" 

size=“30”/>

<br/>
<input type="submit" name="login" value="Login &#187;" 

class=“primary” />
<%= end_form_tag %>

When I change to this :

<% form_tag :action => ‘login’ do %>
(…same form fields…)
<% end %>

then on my production machine, I get no HTML output at ALL. No errors
in the log file, nothing. The layout renders, and the HTML produced
looks like this:

Please Sign In

...

So the output of the whole <% form_tag :action… do %> … <% end %>
is just AWOL.

Now, on my development machine, these produce identical HTML output;
the form shows up and works fine whether I use the old deprecated <%=
start_form_tag …%> or the new-and-hotness <% form_tag … do %>.

Can someone shed some light on where I might look to find the problem?
It seems perhaps I don’t have the proper version of something on
one of the servers, but frankly, I don’t know how to determine that.

Thanks for any suggestions!

Ryan W. wrote:

I’ve got two servers, both with Rails 1.1.6 on them. I’m trying to
remove some of the newly-deprecated stuff in my app, and I’ve run into
a problem. My login page used to look like this:

[snip]

When I change to this :

<% form_tag :action => ‘login’ do %>
(…same form fields…)
<% end %>

The difference might be <%= instead of <%

Use <%= if you want the output rendered.

Long
www.edgesoft.ca/blog/read/2

On 12/7/06, Long [email protected] wrote:

Use <%= if you want the output rendered.
No, that’s for the old-style usage; this is the new block-style usage
of form_tag (see http://www.loudthinking.com/arc/000601.html ). Not
only does <%= not help, it actually generates a Rails error.

Well, as is so often the case, by finally giving up and posting to a
public list, within minutes I was able to finally figure out what was
wrong.

I was tripped up by the fact that the 1.2 RC1 is still numbered as a
1.1.6 branch (1.1.6.5618 at the moment), and I had NOT installed Rails
from gems.rubyonrails.org. Thought I had. Duh.

If I weren’t so happy to have this working now, I’d be embarrassed. :slight_smile:
Move along, nothing to see here. :slight_smile:

Ryan W. wrote:

Use <%= if you want the output rendered.

No, that’s for the old-style usage; this is the new block-style usage
of form_tag (see http://www.loudthinking.com/arc/000601.html ). Not
only does <%= not help, it actually generates a Rails error.

My bad. So is this what is new in 1.2?

Regardless of version, are there advantages to using the form_tag…
construct
instead of plain HTML (e.g. <form …>…)?

Long
www.edgesoft.ca/blog/read/2

On 12/7/06, Long [email protected] wrote:

Ryan W. wrote:
[snip]

No, that’s for the old-style usage; this is the new block-style usage
of form_tag (see http://www.loudthinking.com/arc/000601.html ). Not

My bad. So is this what is new in 1.2?

This is one of several things coming in 1.2. You can find much more
at http://weblog.rubyonrails.org/2006/11/26/1-2-new-in-activerecord
and
http://weblog.rubyonrails.org/2006/11/23/rails-1-2-release-candidate-1
and all over the place.

Regardless of version, are there advantages to using the form_tag… construct
instead of plain HTML (e.g. <form …>…)?

Well, one notable advantage is that you can let Rails properly build
the URL to which you want to POST your form by indicating the
controller and action and other such things by symbol or by name. I
would hate to have to build those things manually everywhere. <%
form_tag :controller=>‘notes’, :action=>‘list’, :[email protected] do %>…<%
end %> is so much easier.

There are lots of reasons that form_tag is your friend. You just have
to match up the version of it that you’re using with the version of
Rails that you actually installed on your server. :slight_smile:

Ryan W. wrote:

Well, as is so often the case, by finally giving up and posting to a
public list, within minutes I was able to finally figure out what was
wrong.

I was tripped up by the fact that the 1.2 RC1 is still numbered as a
1.1.6 branch (1.1.6.5618 at the moment), and I had NOT installed Rails
from gems.rubyonrails.org. Thought I had. Duh.

If I weren’t so happy to have this working now, I’d be embarrassed. :slight_smile:
Move along, nothing to see here. :slight_smile:

Hi,

I’m glad you found a solution for yourself. Sadly, for me,I’m
experiencing the same problem, (no output from form_tag).

I’ve upgraded to rails 1.2.2 via gem update on OSX in this manner:

sudo gem update rails --include-dependencies --source
gems.rubyonrails.org
Password:
Updating installed gems…
Bulk updating Gem source index for: http://gems.rubyonrails.org
Attempting remote update of rails
Successfully installed rails-1.2.2
Gems: [rails] updated

My code:

<% form_tag( {:action=>‘create’}, :multipart=>true ) do %>
…stuff…
<% end %>

All the ‘stuff’ is nowhere to be found.

Any ideas?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs