Rails - Dec 2007 - undefined local variable or method `start_form_tag'

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!!
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 23 Dec 2007, at 15:09, dc dc wrote:
>
> 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 %>
>
It was deprecated in 1.2 and removed in 2.0

Fred
> 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!!
> -- 
> 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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> For more options, visit this group at http://groups.google.com/grou

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Dec 23, 2007 10:09 AM, dc dc
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> 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!!
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>


-- 
http://www.coreyhaines.com
The Internet''s Premiere source of information about Corey Haines

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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>

On Dec 23, 2007 10:21 AM, dc dc
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> 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.
>
> --
>
> Posted via http://www.ruby-forum.com/.
>
> >
>


-- 
http://www.coreyhaines.com
The Internet''s Premiere source of information about Corey Haines

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Dec 23, 2007 10:29 AM, dc dc
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> 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.
> --
>
> Posted via http://www.ruby-forum.com/.
>
> >
>


-- 
http://www.coreyhaines.com
The Internet''s Premiere source of information about Corey Haines

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Corey,
Here''s my whole form block:
[code]
<%= 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>
<%=  %>
[/code]
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 %>
>
>  <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>
> <%=  %>
> [/code]
> -- 
> 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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Many thanks indeed Frederick Cheung.

yes, that makes sense



-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

<%= 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
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> 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.
> --
> Posted viahttp://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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

<%= %> 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
<anatoly.volovik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> <%= 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
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> wrote:
> > 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.
> > --
> > Posted viahttp://www.ruby-forum.com/.
> >
>

-- 
Ryan Bigg
http://www.frozenplague.net
Feel free to add me to MSN and/or GTalk as this email.

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You might want to look into form_for.

http://api.rubyonrails.com/classes/ActionView/Helpers/FormHelper.html#M000920
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 27 Jan 2008, at 00:11, 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.
>
Because bloating the api isn''t in general a good thing ?

Fred
> 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.
> -- 
> 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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

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


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Frederick Cheung wrote:
> On 27 Jan 2008, at 00:11, 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.
>>
> 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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Mark Reginald James wrote:
> 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.
> 
> --
> 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 </form>.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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:
> 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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Sep 15, 2:39 pm, Michael Durrant
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
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 (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
> 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.
> --
> Posted viahttp://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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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?

>>
> 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
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Michael Durrant wrote:
> Seeing as you asked ;)
> 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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

Sent from my iPhone
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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 <br>''s (not <br
/>''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
;)
> 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
> 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.
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Frederick Cheung 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?
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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 
junk-sxbMu2YjdWtWk0Htik3J/w@public.gmane.org on public forums.

VERY much appreciated.
Michael.

James Byrne wrote:
> Frederick Cheung 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?
-- 
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.