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
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 (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 
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 
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
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,