undefined local variable or method `start_form_tag'

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

-Corey

Here's the examples from the docs

form_tag('/posts')
  # => <form action="/posts" method="post">

  form_tag('/posts/1', :method => :put)
  # => <form action="/posts/1" method="put">

  form_tag('/upload', :multipart => true)
  # => <form action="/upload" method="post" enctype="multipart/form-data">

  <% form_tag '/posts' do -%>
    <div><%= submit_tag 'Save' %></div>
  <% end -%>
  # => <form action="/posts" method="post"><div><input type="submit"
name="submit" value="Save" /></div></form>

So, if you are passing a block, it puts the end </form>

I think you should be doing more like

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

which will wrap the entirety in a <form></form>

Perhaps if you posted your code block.

-Corey

Corey,
Here's my whole form block:
[code]
<%= form_tag %>

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

<%= form_tag %>
...... ......
<%= %>

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

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

<%= %> 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.

You might want to look into form_for.

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

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.

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

Slain Wilde 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.

Frederick Cheung 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.

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.

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.

If you're that bothered just stick

def start_form_tag(*args)
  form_tag(*args)
end

def end_form_tag
  '</form'>
end

in application_helper and be done with it.

Fred

Frederick Cheung wrote:

If you're that bothered just stick

def start_form_tag(*args)
  form_tag(*args)
end

def end_form_tag
  '</form'>
end

in application_helper and be done with it.

Fred

Hey, actual help. Who knew.

I concur with Fred's earlier thoughts. This change is a big mistake.
Though I appreciate streamlining API's, the reality is that anyone who
has a starter book on Ruby that's over 9 months old is not going to be
able to get a form working without googling around and reading through
technogarble.

Ruby adaptation is going to take a big hit for this.

This was a poor design decision. If the Ruby community is looking for
buy-in from the development community, they just moved one step away.

-Geoff

Slain Wilde wrote:

I think the underlying issue for this and hundreds of similar ones is
simple:
Poor error messages.
Imagine if instead of undecipherable error messages that take hour or
days to figure out, what if (in this example) the error message said
"form_for_tag is deprecated in Rails 2.0+, please consider using
form_for instead".

Imagine the frustration that would save! I think people would be a lot
less stressed out, pissed off and bitching on blogs/forums if they
hadn't spent hours trying to figure out weird error messages. They
would see the message, fix the code in mins with a global replace and
move on.

This ignores the deprecating issue itself (on purpose). Having worked
with dozens of languages with reasonable error messages over more years
than I care to admit, the Ror error messages continue to blow me away.
I'm sure there are some who will say 'read a book, understand the
architecture and ruby better'. But for the rest of us in the real
world, that doesn't cut it.

Having said all that.... the more cryptic the better, right? That way
we can charge $100,000 for being a good RoR programmer instead of
$30,000 (or less) which is what would happen if RoR was made easier and
I think better error messages would be the biggest change.
All imho of course - what do you think?

Keys to a good programmer - humbleness, humility and honesty.

I think the underlying issue for this and hundreds of similar ones is
simple:
Poor error messages.
Imagine if instead of undecipherable error messages that take hour or
days to figure out, what if (in this example) the error message said
"form_for_tag is deprecated in Rails 2.0+, please consider using
form_for instead".

A deprecation warning was added in 1.2.0 (http://github.com/rails/
rails/blob/v1.2.0/actionpack/lib/action_view/helpers/
form_tag_helper.rb) and then that method was removed almost a year
later. What more do you want?

Fred

Seeing as you asked :wink:
You're kidding, right? Have you been (working) in the industry long?
Seriously. That sounds like a great answer from an incredibly
intelligent really good, ace rails programmer but not really related to
business needs. Ask any business person and always know that they pay
the bills :slight_smile:
I genuinely would welcome a good - business - justification as to why 12
months is deemed an appropriate length of time. Why not 36 months? Also
why not better error messages generally?
I and many others need something that is around for longer than a year.
Applications, books, references, etc. should not all just become
'invalid' after 1 year and no longer have helpful warnings. and I'm at a
loss to understand why to remove something helpful?
Changing new docs, the api, etc that's all great and I totally support
it, it's the rails/open way after all to constantly improve, but break
an old thing within a year or 2, I don't get it. 'bloated api' reason?
I think we have the space now. See above, rinse, repeat.
But again, more income for us, right?
There's no substitute for business experience, but of course you can
lead a horse to water...
Thoughts?

Michael Durrant wrote:

Seeing as you asked :wink:
You're kidding, right? Have you been (working) in the industry long?

Yes (though I can't speak for Fred). And your answer makes many
incorrect assumptions and misses the point.

[...]

I genuinely would welcome a good - business - justification as to why 12
months is deemed an appropriate length of time.

Why wouldn't it be? We're not talking about a hosted service here; you
can continue to use old versions of Rails for as long as you want.
What's the business justification for keeping 3-year-old deprecations in
the API?

A deprecation says "the next time you upgrade, this feature might be
gone, so get rid of it now". If you can't handle that, then don't
upgrade.

Why not 36 months?

What would the extra two years do, other than bloating the framework and
encouraging people not to take deprecation warnings seriously?

Also
why not better error messages generally?

That's a separate issue.

I and many others need something that is around for longer than a year.

Then you are welcome to stick with an old version of Rails. No one is
forcing you to upgrade.

The nature of upgrades is to introduce changes. If you can't deal with
those changes, don't.

Applications, books, references, etc. should not all just become
'invalid' after 1 year and no longer have helpful warnings.

Applications do not become invalid after 1 year, and I'm sure you know
this. There are still Rails 1.x apps out there that I'm sure are
working fine.

and I'm at a
loss to understand why to remove something helpful?

Because a better, more Rubyish way was found to do the same thing.

Changing new docs, the api, etc that's all great and I totally support
it, it's the rails/open way after all to constantly improve, but break
an old thing within a year or 2, I don't get it.

"Backward compatibility means never being able to say 'oops, we
goofed'."

Best,