Undefined local variable or method `start_form_tag'

[milazzo]

Greetings,

I’m also suffering from the ‘undefined local variable or method’ problem
after having update my rails version to 2.0.

All worked fine before and now I get the following error:

undefined local variable or method `start_form_tag’ in —>

<%= start_form_tag %>

What to do? If it can be at all helped I really don’t want to alter the
source code as this is part of the open source package I’m using and I’m
two days away from consignment, so don’t want it to break again if I
update later.

Any help would be much appreciated. Desperately trying to get this
deployed and working!!

[milazzo]

On 23 Dec 2007, at 15:09, dc dc wrote:

<%= start_form_tag %>

It was deprecated in 1.2 and removed in 2.0

Fred

[milazzo]

Looking at the rails docs (http://api.rubyonrails.org/), it appears
that start_form_tag has been superseded by just form_tag
(ActionView::Helpers::FormTagHelper)

-Corey

On Dec 23, 2007 10:09 AM, dc dc [email protected]
wrote:

<%= start_form_tag %>

–

Posts – Corey Haines

The Internet’s Premiere source of information about Corey H.

[milazzo]

Many thanks to both of you. That works great.

Just one follow up question. What’s the closing tag. I’ve used:

<%= %>

which works, but I can’t believe it’s right.

[milazzo]

Here’s the examples from the docs

form_tag(‘/posts’)

=>

form_tag(‘/posts/1’, :method => :put)

=>

form_tag(‘/upload’, :multipart => true)

=> <form action=“/upload” method=“post”

enctype=“multipart/form-data”>

<% form_tag ‘/posts’ do -%>

<%= submit_tag ‘Save’ %>

<% end -%>

=>

<input type=“submit”

name=“submit” value=“Save” />

So, if you are passing a block, it puts the end

On Dec 23, 2007 10:21 AM, dc dc [email protected]
wrote:

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

–

Posts – Corey Haines

The Internet’s Premiere source of information about Corey H.

[milazzo]

Thanks Corey,

yes, I found the docs, but didn’t know how to interpret them. I’ve just
got:

<%= form_tag %>

… my html form complete with fields …

<%= %>

which looks odd to me - but it seems to work.

[milazzo]

I think you should be doing more like

<%= form_tag do %>
<% … put other generating methods here %>
<% end %>

which will wrap the entirety in a

Perhaps if you posted your code block.

-Corey

On Dec 23, 2007 10:29 AM, dc dc [email protected]
wrote:

<%= %>

which looks odd to me - but it seems to work.

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

–

Posts – Corey Haines

The Internet’s Premiere source of information about Corey H.

[milazzo]

Corey,
Here’s my whole form block:

<%= form_tag %>
  <table cellpadding="0" cellspacing="5" border="0" style="width: 250px; 
display: inline-table; margin-left: auto; margin-right: auto">
    <tr>
      <td style="text-align: right; white-space: nowrap">
        <label for="email"><%= l(:login_username) %>:</label>
      </td>
      <td>
        <%= text_field_tag 'email' %></p>
      </td>
    </tr>
    <tr>
      <td style="text-align: right; white-space: nowrap">
        <label for="password"><%= l(:login_password) %>:</label>
      </td>
      <td>
        <%= password_field_tag 'password' %></p>
      </td>
    </tr>
    <tr>
      <td style="text-align: right">
      </td>
      <td style="text-align: left">
        <%= submit_tag 'Log in' %>
      </td>
    </tr>
  </table>
<%=  %>

[milazzo]

On 23 Dec 2007, at 15:56, dc dc wrote:

Corey,
Here’s my whole form block:

[code]
<%= form_tag %>

You should do
<% form_tag do %>
…
<% end %>

[milazzo]

Many thanks indeed Frederick C…

yes, that makes sense

[milazzo]

<%= form_tag %>
… …
<%= %>

what is the difference between the two? they seem to be doing the
same thing

<% form_tag do %>
…
<% end %>

On Dec 23 2007, 7:29 am, dc dc [email protected]

[milazzo]

You might want to look into form_for.

http://api.rubyonrails.com/classes/ActionView/Helpers/FormHelper.html#M000920

[milazzo]

I would really like to know the motivation behind getting rid of
start_form_tag and end_form_tag. It seems asinine to me.

My interpretation:
“Let’s make everyone change hundreds of lines of code in dozens of
projects, which all need to be tested now because someone thought there
was a better way to do it.”

I hope that one person just decided to do this by fiat, because if a
committee of people thought this was a good idea, then some of the more
acerbic comments I’ve seen about the Rails gurus starts making a little
more sense.

I won’t argue that it isn’t better: I’m sure you get better ‘forgot to
close the form’ error detection, or form within a form warnings, or
something. But there is really no good reason for it to break every
application out there that uses the old method. Progress for the sake
of progress isn’t.

[milazzo]

<%= %> is an output block, which will output anything inside of them,
usually. In the case of form_tag the = is extraneous.

<% %> is an evaluation block, anything inside of it will be processed,
but
if it had any output it will not be shown on the screen.

On Jan 10, 2008 9:41 AM, anti [email protected] wrote:

<% end %>

<%= form_tag %>

… my html form complete with fields …

<%= %>

which looks odd to me - but it seems to work.

Posted viahttp://www.ruby-forum.com/.

–
Ryan B.

frozenplague.net

Feel free to add me to MSN and/or GTalk as this email.

[milazzo]

On 27 Jan 2008, at 00:11, Slain W. wrote:

I would really like to know the motivation behind getting rid of
start_form_tag and end_form_tag. It seems asinine to me.

Because bloating the api isn’t in general a good thing ?

Fred

[milazzo]

Slain W. wrote:

I would really like to know the motivation behind getting rid of
start_form_tag and end_form_tag. It seems asinine to me.

start_form_tag is still available as the non_block version of form_tag.
This is the only way to do it when the form straddles an erb block,
such as a cache block.

–
We develop, watch us RoR, in numbers too big to ignore.

[milazzo]

Frederick C. wrote:

On 27 Jan 2008, at 00:11, Slain W. wrote:

I would really like to know the motivation behind getting rid of
start_form_tag and end_form_tag. It seems asinine to me.

Because bloating the api isn’t in general a good thing ?

Fred

Which is I think is a pretty lame reason in this instance. I would
think that any reasonable analysis would show that effort required to
maintain a ‘bloated’ api is far and away less than the effort required
fix and test all of the existing code that uses the old method. Leave
it deprecated, so people don’t use it.

Or, make a script that goes in the script folder that automatically
updates the code seemlessly for all deprecated features. If you can’t
do that safely, then don’t drop support. Cause I’m sitting here looking
at 40 rails sites I need to update now, with 500+ start/end_form_tag’s
that I’ve got to go through and update and test. And while freezing
rails may let me put off the pain for some of the sites, at some point
it will have to be done.

And while functional testing, etc. might help automate some of this, the
reality is there are never enough test cases to find everything.

[milazzo]

Mark Reginald J. wrote:

Slain W. wrote:

I would really like to know the motivation behind getting rid of
start_form_tag and end_form_tag. It seems asinine to me.

start_form_tag is still available as the non_block version of form_tag.
This is the only way to do it when the form straddles an erb block,
such as a cache block.

–
We develop, watch us RoR, in numbers too big to ignore.

form_tag is also a non-block form of form_tag. Just don’t put a do on
the end and close it with .

[milazzo]

i totally agree, this is a ridiculous change. it’s a lot of work for
people for very little gain. i understand that the rails developers want
to have the best framework but at some point they need to realize that
you can spend too much time learning how to be productive, rather than
being productive.

it seems very sophomoric to constantly be rethinking these tags.

[milazzo]

It was one change, once. Please get over it. I find the new syntax is
shorter (form_tag vs start_form_tag and end vs end_form_tag) and makes
more sense.