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
Any help would be much appreciated. Desperately trying to get this
deployed and working!!
Posted via http://www.ruby-forum.com/.
> I'm also suffering from the 'undefined local variable or method'
> 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 %>
It was deprecated in 1.2 and removed in 2.0
> What to do? If it can be at all helped I really don't want to alter
> source code as this is part of the open source package I'm using and
> 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!!
> 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 this group at http://groups.google.com/grou
The Internet's Premiere source of information about Corey Haines
Just one follow up question. What's the closing tag. I've used:
which works, but I can't believe it's right.
# => <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>
yes, I found the docs, but didn't know how to interpret them. I've just
<%= form_tag %>
...... my html form complete with fields ......
which looks odd to me - but it seems to work.
<%= 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.
> Here's my whole form block:
> <%= form_tag %>
You should do
<% form_tag do %>
<% end %>
yes, that makes sense
"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
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 ?
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.
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.
form_tag is also a non-block form of form_tag. Just don't put a do on
the end and close it with </form>.
it seems very sophomoric to constantly be rethinking these tags.
You seem to have missed the point. No one here has indicated that the
new one isn't better: it is. That does not obviate the fact that the
old form was a widely used feature, and it has serious impacts on
backward compatibility. Case in point, I had mentioned 7 months ago in
my original posts that this would be a huge effort to upgrade/test, and
guess what, none of those projects have been upgraded and they all still
are running Rails 1.2.x. Only new development that doesn't rely on any
existing code has been coded with Rails 2, and none of that is in
production in my case. These kinds of things do have serious impacts on
adoption rates, satisfaction with the language and tools, etc.
Hey, actual help. Who knew.
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.
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
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.
> A deprecation warning was added in 1.2.0 (http://github.com/rails/
> form_tag_helper.rb) and then that method was removed almost a year
> later. What more do you want?
Posted via http://www.ruby-forum.com/.
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
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
> 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?
> 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
> 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
Sent from my iPhone
Marnen Laibow-Koser wrote:
> 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
I didn't upgrade, just sought an answer.
> What would the extra two years do, other than bloating the framework and
> encouraging people not to take deprecation warnings seriously?
New to rail this in 2009, so never used 1.2 and never saw deprecation
2 extra years would give people time, let new books come out, let old
books age out, let new forum posts become the standard, let old posts
get deleted, etc. Basically i think 3 years would be much nicer to
people. I don't have any fixed idea on what time period is 'right', I
just don't get why "1 year" is deemed 'right'. If shorter is better,
how about 3 months? I think it all comes down to peoples opinion of
what time is 'reasonable'. In the end there is always gonna be a
distribution curve of time opinions there, from 'none' to 'forever',
>> why not better error messages generally?
> That's a separate issue.
I think it's the biggest one.
>> 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.
old versions missing much functionality - business reasons, hosting,
functionality and love of change certainly do pretty much force upgrades
- plus I can't simultaneously use multiple versions or my brain explodes
> The nature of upgrades is to introduce changes. If you can't deal with
> those changes, don't.
i can, but i can disagree with how they are introduced based on
experience right? that's ok right?
>> 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.
I do know that. But I can't keep developing in old and multiple versions
and know what worx in what and stay sane :) Because I do love change and
need the newer versions I... need the newer versions.
>> 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.
Sure and that's great. I'm really more concerned about the error
messages removal, not the tag removal.
>> 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
or... "Backward compatibility can mean saying 'oops, we goofed', here's
a new and better way to do it, but don't worry, your existing code base
and reference material will still be ok under the new version."
But again philosophy and see wc3 & browser standards above.
When a tag is really removed, if the 'remover' could remove all the main
threads in Rails Forums, etc., much as that might take a big effort, now
that would really stand out as a big help.
> It was deprecated in 1.2 and removed in 2.0
On the subject of error messages, with deprecations specifically in
mind, I suggest the following approach at least be considered.
Establish a deprecated_methods_index library at the top level of Rails
so that, when someone finally decides to upgrade their Rails-1.0.6 app
to Rails-whatever, instead of getting:
"undefined local variable or method `whatever'"
(which is generated by ruby itself and not by Rails)
one obtains the output from something like this:
puts("whatever method is deprecated and was removed in rails-x.y.z.")
puts("Use other_one method instead.")
If these are all kept in one place surely it would not be too difficult
to maintain? Are there any downsides to this approach, other than having
to write four lines of code for every deprecated method?
VERY much appreciated.