Undefined local variable or method `start_form_tag'

Ryan B. wrote:

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.

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.

On Aug 14, 7:33 am, Slain W. [email protected]
wrote:

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.

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 C. 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 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 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 W. wrote:

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

On Sep 15, 2:39 pm, Michael D. [email protected] 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”.

A deprecation warning was added in 1.2.0 (Ruby on Rails · GitHub
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?

A deprecation warning was added in 1.2.0 (Ruby on Rails · GitHub
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

Michael D. 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,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

Good answers, thank you. i really do want & need to use the newer
versions and features & I DO love change, I don’t think using old
versions are the answer and my boss doesn’t understand ‘bloated
frameworks’. I told him, well, it’s not DRY and can mean duplicate code
and encourage people not to change to the new, etc, etc. but he said ‘so
what?, point one thing to the other or something [which actually is
shown in the thread as a temp solution, very helpful!], just don’t break
it’. The new way is much better, I agree 100%, though I still disagree
with it as a reason to allow the old way to become invalid in the
fashion that it did.
But I also think it’s more philosophical in nature and there will always
be differences, not rights & wrongs (though not implied by you or
anyone). I certainly respect your opinion and experience and will take
them into account going forward. btw my live app actually is on a
hosted service and it does get tricky using lower versions with them,
wish I was in a big org and didn’t need to worry!
For me the main item is - If all the ‘old’ books and posts could be
immediately destroyed this would be awesome and would certainly address
a great many of the issues, but they can’t and folks are gonna keep
searching and spending ages chasing ghosts. I feel for my fellow
developers who seek answers. I think the philosophical difference is
also best exemplified by XHTML and WC3 and the browser wars for how
standards compliance can pan out, e.g. if
's (not
's) were
really enforced and pages broke. Similarly old browser versions were
not the answer there. Though I sure miss my Netscape! They voted, but
the vote was 11-8 againt the strict. So the ‘8’ were not convinced and
probably never would be. Then again, the 11 probably wouldn’t be either!
But that’s ok, good for them, 'cos diversity is good!
At the very least I could easily live with the tag being removed I just
wish the error msg was left for longer. Would it really be that bad to
have it still? Again, I am referencing the error message. Because of
the blogs/books issue y’know. Just to help people more and save them
from themselves. Same principle though for many other (tags, controller
names, etc.).
I welcome further discussion. I would just ask you to bear in mind that
change is not all or nothing (“If you can’t deal with those changes,
don’t.” wasn’t very helpful) but there can be differences of opinion on
exactly how the changes are implemented.
Best, Michael.

Also (specifically):

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
upgrade.

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
warnings.
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’,
right?

Also
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
    :wink:

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 :slight_smile: 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
goofed’.”

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.

Frederick C. wrote:

It was deprecated in 1.2 and removed in 2.0

Fred

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:

def whatever(*parms)
puts(“whatever method is deprecated and was removed in rails-x.y.z.”)
puts(“Use other_one method instead.”)
end

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?

I LOVE it!
James you are the MAN.
Just suggesting a reasonable solution is awesome and I really mean it.
I would hire you in an instant!
No sly insults or anything in your message, now that’s the way forward.
Give me your email and I’ll paypal you right now. I use
[email protected] on public forums.

VERY much appreciated.
Michael.

James B. wrote:

Frederick C. wrote:

It was deprecated in 1.2 and removed in 2.0

Fred

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:

def whatever(*parms)
puts(“whatever method is deprecated and was removed in rails-x.y.z.”)
puts(“Use other_one method instead.”)
end

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?