Rails core - Aug 2009 - Non JavaScript dependent scaffolding solution for record deletion

Hello,

The generated scaffold relies on Javascript enabled to be able to
delete a record, which prevents anyone with JavasScript disabled to
delete it.

I''ve hacked a solution with a delete action in one of my projects,
which works nicely, and cleanly. Basically, the link still have
Javascript which will work if enabled, but the url of the link goes to
a delete action, with a form that confirms the user wants to delete
(instead of a Javascript prompt).

Only took 3 new controller lines, 6 new view lines, 1 changed view
line, and a route :member.

Is this something that people would like to see in Rails 3?

Regards
Kieran

On Aug 9, 2009, at 5:20 PM, Kieran P wrote:
> The generated scaffold relies on Javascript enabled to be able to
> delete a record, which prevents anyone with JavasScript disabled to
> delete it.
>
> I''ve hacked a solution with a delete action in one of my projects,
> which works nicely, and cleanly. Basically, the link still have
> Javascript which will work if enabled, but the url of the link goes to
> a delete action, with a form that confirms the user wants to delete
> (instead of a Javascript prompt).
>
> Only took 3 new controller lines, 6 new view lines, 1 changed view
> line, and a route :member.
>
> Is this something that people would like to see in Rails 3?

I''d vote NO.  Scaffolding isn''t about providing a
cross-browser
solution with graceful degradation.  It''s about giving you a temporary
structure you can lean your app against while building it.  By the  
time you want to launch the app, scaffolding should be replaced by  
code you built yourself.  I don''t have anything against doing things  
the way you propose, but I''d rather scaffolding stay as minimal and  
simple as possible.  Every line of code in the scaffolding bears a  
maintenance cost, and it seems better to keep it easy to upgrade than  
make it feature-complete for end-users.

--
Josh Susser
http://blog.hasmanythrough.com

Hey Josh.

Thanks for your comments.
> I''d vote NO.  Scaffolding isn''t about providing a
cross-browser solution with graceful degradation.
Perhaps not, but isn''t it better to have applications that do and to
promote graceful degredation?

And even if the scaffolding doesn''t get changed, the code to support a
delete action by default would still be a good thing, rather than
adding a collection to each resources route.
> It''s about giving you a temporary structure you can lean your app
against while building it.
Most of my code still uses scaffolded controller code (only added
lines to it, didn''t take away).
> By the time you want to launch the app, scaffolding should be replaced by
code you built yourself.
For the views and tests, sure. But the base of the model and
controllers likely stay the whole way through app development (at
least, this has been the case with a project I''m working on at the
moment).
> I don''t have anything against doing things the way you propose,
but I''d rather scaffolding stay as minimal and  simple as possible.
When it comes down to it, it''s only 3 controller lines and a view
file.
> Every line of code in the scaffolding bears a  maintenance cost
Shouldn''t be much though right? How often does the scaffolding code
change per release since 2.1?

Regards
Kieran

I think this is something that is always annoying.
Namely I have to reinvent a convention to handle this.

Something like "pre_delete" with a GET
- this is just a proper delete form
and "delete" with a DELETE
- this does the delete

but I think we deserve to have this baked into rails.

I think it''d be cool if;
GET /posts/delete mapped to the "pre-delete" action
DELETE /posts/delete mapped to the "delete action"

thereby,
with a "link_to "delete", :method => :delete"
you automatically fall back when javascript is disabled.

Boom.

On Aug 10, 1:20 am, Kieran P <kieran...@gmail.com>
wrote:
> Hello,
>
> The generated scaffold relies on Javascript enabled to be able to
> delete a record, which prevents anyone with JavasScript disabled to
> delete it.
>
> I''ve hacked a solution with a delete action in one of my projects,
> which works nicely, and cleanly. Basically, the link still have
> Javascript which will work if enabled, but the url of the link goes to
> a delete action, with a form that confirms the user wants to delete
> (instead of a Javascript prompt).
>
> Only took 3 new controller lines, 6 new view lines, 1 changed view
> line, and a route :member.
>
> Is this something that people would like to see in Rails 3?
>
> Regards
> Kieran

I am in favor of a standard delete action, analagous to new and edit. I 
can''t think of a good reason not to have it--it shows good practice and
isn''t exactly a new concept. We have new and edit as HTML precursor 
actions for the POST and PUT verbs, why not delete as HTML precursor for 
DELETE. One of the biggest wins of Rails is conventionality; when you 
come into a new Rails app, you don''t have to wonder what the edit
action
is called. Why not extend this to delete confirmation screens as well?

-- Yehuda

MatthewRudy wrote:
> I think this is something that is always annoying.
> Namely I have to reinvent a convention to handle this.
>
> Something like "pre_delete" with a GET
> - this is just a proper delete form
> and "delete" with a DELETE
> - this does the delete
>
> but I think we deserve to have this baked into rails.
>
> I think it''d be cool if;
> GET /posts/delete mapped to the "pre-delete" action
> DELETE /posts/delete mapped to the "delete action"
>
> thereby,
> with a "link_to "delete", :method =>  :delete"
> you automatically fall back when javascript is disabled.
>
> Boom.
>
> On Aug 10, 1:20 am, Kieran P<kieran...@gmail.com>  wrote:
>    
>> Hello,
>>
>> The generated scaffold relies on Javascript enabled to be able to
>> delete a record, which prevents anyone with JavasScript disabled to
>> delete it.
>>
>> I''ve hacked a solution with a delete action in one of my
projects,
>> which works nicely, and cleanly. Basically, the link still have
>> Javascript which will work if enabled, but the url of the link goes to
>> a delete action, with a form that confirms the user wants to delete
>> (instead of a Javascript prompt).
>>
>> Only took 3 new controller lines, 6 new view lines, 1 changed view
>> line, and a route :member.
>>
>> Is this something that people would like to see in Rails 3?
>>
>> Regards
>> Kieran
>>      
> >
>    
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

MatthewRudy wrote:
> I think this is something that is always annoying.
> Namely I have to reinvent a convention to handle this.
>
> Something like "pre_delete" with a GET
> - this is just a proper delete form
> and "delete" with a DELETE
> - this does the delete
>
> but I think we deserve to have this baked into rails.
>
> I think it''d be cool if;
> GET /posts/delete mapped to the "pre-delete" action
> DELETE /posts/delete mapped to the "delete action"
>    
This doesn''t make sense. The normal HTTP convention would be:

DELETE /posts/1 to delete.

I like the idea of:

GET /posts/1/delete for a DELETE confirmation screen. You''d then have:

---

GET /posts/1 to see the post
GET /posts/1/edit to get a screen with information on editing the post, 
which:
PUT /posts/1 to update the post

We also have:

GET /posts to see all posts
GET /posts/new to get a screen with information on creating a new post, 
which:
POST /posts to create it

This would add:

GET /posts/1/delete to get a screen with information on deleting the 
post (a confirmation), which would:
DELETE /posts/1 to delete it
> thereby,
> with a "link_to "delete", :method =>  :delete"
> you automatically fall back when javascript is disabled.
>
> Boom.
>
> On Aug 10, 1:20 am, Kieran P<kieran...@gmail.com>  wrote:
>    
>> Hello,
>>
>> The generated scaffold relies on Javascript enabled to be able to
>> delete a record, which prevents anyone with JavasScript disabled to
>> delete it.
>>
>> I''ve hacked a solution with a delete action in one of my
projects,
>> which works nicely, and cleanly. Basically, the link still have
>> Javascript which will work if enabled, but the url of the link goes to
>> a delete action, with a form that confirms the user wants to delete
>> (instead of a Javascript prompt).
>>
>> Only took 3 new controller lines, 6 new view lines, 1 changed view
>> line, and a route :member.
>>
>> Is this something that people would like to see in Rails 3?
>>
>> Regards
>> Kieran
>>      
> >
>    
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

-1.

On Mon, Aug 10, 2009 at 12:39 PM, Yehuda Katz<wycats@gmail.com>
wrote:
> I am in favor of a standard delete action, analagous to new and edit. I
> can''t think of a good reason not to have it--it shows good
practice and
> isn''t exactly a new concept.
It makes poor and slow UI.
> We have new and edit as HTML precursor actions
> for the POST and PUT verbs, why not delete as HTML precursor for DELETE.
One
> of the biggest wins of Rails is conventionality; when you come into a new
> Rails app, you don''t have to wonder what the edit action is
called. Why not
> extend this to delete confirmation screens as well?
When you edit/create - you don''t just press one button. You enter a
good amount of data too. That''s not true when you DELETE the record in
99.99% of the cases.
-- 
Cheers!
- Pratik
http://m.onkey.org

Pratik wrote:
> -1.
>    
+2
> On Mon, Aug 10, 2009 at 12:39 PM, Yehuda Katz<wycats@gmail.com> 
wrote:
>    
>> I am in favor of a standard delete action, analagous to new and edit. I
>> can''t think of a good reason not to have it--it shows good
practice and
>> isn''t exactly a new concept.
>>      
>
> It makes poor and slow UI.
>    
Sure. Better than no UI, wouldn''t you say?
>> We have new and edit as HTML precursor actions
>> for the POST and PUT verbs, why not delete as HTML precursor for
DELETE. One
>> of the biggest wins of Rails is conventionality; when you come into a
new
>> Rails app, you don''t have to wonder what the edit action is
called. Why not
>> extend this to delete confirmation screens as well?
>>      
>
> When you edit/create - you don''t just press one button. You enter
a
> good amount of data too. That''s not true when you DELETE the
record in
> 99.99% of the cases.
>    
Are you suggesting that we just put an inline small form with a submit 
button to DELETE the record? I''d be ok with that, provided
we''re not
worried about the lack of confirmation. Maybe gracefully degrading the 
confirmation isn''t very important (after all, the functionality is
still
available)?

-- Yehuda

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Aug 10, 2009, at 7:39 AM, Yehuda Katz wrote:
> I am in favor of a standard delete action, analagous to new and  
> edit. I can''t think of a good reason not to have it--it shows good
> practice and isn''t exactly a new concept. We have new and edit as
> HTML precursor actions for the POST and PUT verbs, why not delete as  
> HTML precursor for DELETE. One of the biggest wins of Rails is  
> conventionality; when you come into a new Rails app, you don''t
have
> to wonder what the edit action is called. Why not extend this to  
> delete confirmation screens as well?
+1

We follow this pattern and I''ve often wished it was a standard  
resource action instead of cluttering up my routes file. To the UI  
concern, we enhance the links via javascript to do an immediate  
destroy where appropriate (just takes one attribute on the link once  
you have a little app-wide JS in place). It makes testing with  
cucumber/webrat easier and gives us a built-in solution for users  
without javascript.
--
Luke Melia
luke@lukemelia.com
http://www.lukemelia.com/

On Mon, Aug 10, 2009 at 13:58, Yehuda Katz <wycats@gmail.com> wrote:
>
> Are you suggesting that we just put an inline small form with a submit
> button to DELETE the record? I''d be ok with that, provided
we''re not worried
> about the lack of confirmation.
>
I was just about to suggest that when I read the rest of the comments. +1
for the inline form

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I like the idea of a small inline form for scaffolding.  But I also
REALLY like the idea of a standard HTML-only approach that supports
confirmation: some resources are too important to delete without
confirmation (or better yet, a "review" of the consequences), and
counting on JavaScript is Bad.

+1 for GET /posts/1/delete
+1 for small inline form in scaffolding that DELETE /posts/1 (without
confirmation if deemed appropriate).

-Chris

On Aug 10, 7:43 am, Yehuda Katz <wyc...@gmail.com>
wrote:
> MatthewRudy wrote:
> > I think this is something that is always annoying.
> > Namely I have to reinvent a convention to handle this.
>
> > Something like "pre_delete" with a GET
> > - this is just a proper delete form
> > and "delete" with a DELETE
> > - this does the delete
>
> > but I think we deserve to have this baked into rails.
>
> > I think it''d be cool if;
> > GET /posts/delete mapped to the "pre-delete" action
> > DELETE /posts/delete mapped to the "delete action"
>
> This doesn''t make sense. The normal HTTP convention would be:
>
> DELETE /posts/1 to delete.
>
> I like the idea of:
>
> GET /posts/1/delete for a DELETE confirmation screen. You''d then
have:
>
> ---
>
> GET /posts/1 to see the post
> GET /posts/1/edit to get a screen with information on editing the post,
> which:
> PUT /posts/1 to update the post
>
> We also have:
>
> GET /posts to see all posts
> GET /posts/new to get a screen with information on creating a new post,
> which:
> POST /posts to create it
>
> This would add:
>
> GET /posts/1/delete to get a screen with information on deleting the
> post (a confirmation), which would:
> DELETE /posts/1 to delete it
>
> > thereby,
> > with a "link_to "delete", :method =>  :delete"
> > you automatically fall back when javascript is disabled.
>
> > Boom.
>
> > On Aug 10, 1:20 am, Kieran P<kieran...@gmail.com>  wrote:
>
> >> Hello,
>
> >> The generated scaffold relies on Javascript enabled to be able to
> >> delete a record, which prevents anyone with JavasScript disabled
to
> >> delete it.
>
> >> I''ve hacked a solution with a delete action in one of my
projects,
> >> which works nicely, and cleanly. Basically, the link still have
> >> Javascript which will work if enabled, but the url of the link
goes to
> >> a delete action, with a form that confirms the user wants to
delete
> >> (instead of a Javascript prompt).
>
> >> Only took 3 new controller lines, 6 new view lines, 1 changed view
> >> line, and a route :member.
>
> >> Is this something that people would like to see in Rails 3?
>
> >> Regards
> >> Kieran
>
>

On 10-Aug-09, at 8:37 AM, Mislav Marohnić wrote:
> On Mon, Aug 10, 2009 at 13:58, Yehuda Katz <wycats@gmail.com> wrote:
>
> Are you suggesting that we just put an inline small form with a  
> submit button to DELETE the record? I''d be ok with that, provided
> we''re not worried about the lack of confirmation.
>
> I was just about to suggest that when I read the rest of the  
> comments. +1 for the inline form
I I agree that for the purposes of scaffolding, it should be an  
inline form. However, I think having map.resource(s) support GET / 
posts/1/delete by default would be a good idea; often a javascript  
popup isn''t the best way to ask for confirmation

Toss in another favorable vote for an inline form with a submit for the
DELETE action. This would be good as it (a) gracefully degrades on its own,
and (b) clearly illustrates to the developer what code needs to be written
to put the form together correctly in the future.

I view the confirmation alert as a "nice-to-have" feature but not
necessary
to the base scaffolding functionality. Perhaps that would be a reasonable
case for inline javascript on the deletion form? Just enough to make it work
out of the box and demonstrate what should be going on.

-Alex

On Mon, Aug 10, 2009 at 8:37 AM, Mislav Marohnić
<mislav.marohnic@gmail.com>wrote:
> On Mon, Aug 10, 2009 at 13:58, Yehuda Katz <wycats@gmail.com> wrote:
>
>>
>> Are you suggesting that we just put an inline small form with a submit
>> button to DELETE the record? I''d be ok with that, provided
we''re not worried
>> about the lack of confirmation.
>>
>
> I was just about to suggest that when I read the rest of the comments. +1
> for the inline form
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Aug 10, 2009 at 12:58 PM, Yehuda Katz<wycats@gmail.com>
wrote:
> +2
http://en.wikipedia.org/wiki/Dissociative_identity_disorder ?? You''re
just one person, wake up ;-)
> Are you suggesting that we just put an inline small form with a submit
button to DELETE the record? I''d be ok with that, provided
we''re not worried about the > lack of confirmation. Maybe gracefully
degrading the confirmation isn''t very important (after all, the
functionality is still available)?
No I''m not suggesting that. I''m not suggesting any change. You
are.
And confirmation *is* important.

I understand the change you people are suggesting is desired in many
situations. However, it''s very easy to add that and it does not belong
in scaffolding.
-- 
Cheers!
- Pratik
http://m.onkey.org

I like the delete GET for a confirmation page. However, if javascript
is enabled it should allow the bypass of this page.

On Aug 10, 7:43 am, Yehuda Katz <wyc...@gmail.com>
wrote:
> MatthewRudy wrote:
> > I think this is something that is always annoying.
> > Namely I have to reinvent a convention to handle this.
>
> > Something like "pre_delete" with a GET
> > - this is just a proper delete form
> > and "delete" with a DELETE
> > - this does the delete
>
> > but I think we deserve to have this baked into rails.
>
> > I think it''d be cool if;
> > GET /posts/delete mapped to the "pre-delete" action
> > DELETE /posts/delete mapped to the "delete action"
>
> This doesn''t make sense. The normal HTTP convention would be:
>
> DELETE /posts/1 to delete.
>
> I like the idea of:
>
> GET /posts/1/delete for a DELETE confirmation screen. You''d then
have:
>
> ---
>
> GET /posts/1 to see the post
> GET /posts/1/edit to get a screen with information on editing the post,
> which:
> PUT /posts/1 to update the post
>
> We also have:
>
> GET /posts to see all posts
> GET /posts/new to get a screen with information on creating a new post,
> which:
> POST /posts to create it
>
> This would add:
>
> GET /posts/1/delete to get a screen with information on deleting the
> post (a confirmation), which would:
> DELETE /posts/1 to delete it
>
>
>
> > thereby,
> > with a "link_to "delete", :method =>  :delete"
> > you automatically fall back when javascript is disabled.
>
> > Boom.
>
> > On Aug 10, 1:20 am, Kieran P<kieran...@gmail.com>  wrote:
>
> >> Hello,
>
> >> The generated scaffold relies on Javascript enabled to be able to
> >> delete a record, which prevents anyone with JavasScript disabled
to
> >> delete it.
>
> >> I''ve hacked a solution with a delete action in one of my
projects,
> >> which works nicely, and cleanly. Basically, the link still have
> >> Javascript which will work if enabled, but the url of the link
goes to
> >> a delete action, with a form that confirms the user wants to
delete
> >> (instead of a Javascript prompt).
>
> >> Only took 3 new controller lines, 6 new view lines, 1 changed view
> >> line, and a route :member.
>
> >> Is this something that people would like to see in Rails 3?
>
> >> Regards
> >> Kieran

+1 for using button_to instead of link_to.

And if submit_tag were to generate a <button> instead of an <input>
then +10000000000 :)

-foca

On Mon, Aug 10, 2009 at 9:37 AM, Mislav
Marohnić<mislav.marohnic@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 13:58, Yehuda Katz <wycats@gmail.com> wrote:
>>
>> Are you suggesting that we just put an inline small form with a submit
>> button to DELETE the record? I''d be ok with that, provided
we''re not worried
>> about the lack of confirmation.
>
> I was just about to suggest that when I read the rest of the comments. +1
> for the inline form
> >
>

On Aug 10, 2009, at 4:51 AM, Pratik wrote:
>
> -1.
>
> On Mon, Aug 10, 2009 at 12:39 PM, Yehuda Katz<wycats@gmail.com>
wrote:
>> I am in favor of a standard delete action, analagous to new and  
>> edit. I
>> can''t think of a good reason not to have it--it shows good
practice
>> and
>> isn''t exactly a new concept.
>
> It makes poor and slow UI.
>
>> We have new and edit as HTML precursor actions
>> for the POST and PUT verbs, why not delete as HTML precursor for  
>> DELETE. One
>> of the biggest wins of Rails is conventionality; when you come into  
>> a new
>> Rails app, you don''t have to wonder what the edit action is
called.
>> Why not
>> extend this to delete confirmation screens as well?
>
> When you edit/create - you don''t just press one button. You enter
a
> good amount of data too. That''s not true when you DELETE the
record in
> 99.99% of the cases.
Not sure I understand your position.  The existing functionality where  
a JS dialogue appears requires the user to just press one button, and  
you''re saying that this is good UI, but having an HTML form appear  
requiring the user to press a button is not good UI?

Seems like precisely the same UI to me, just in two different forms  
and with the obvious latency for the non-JS user.  As others have  
mentioned, surely a slower UI is better than no UI at all?

-- 
Jason King


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

+1 for the GET request on a delete action to show a confirmation
dialog. Also if you send a DELETE call to this URL it could trigger
the destroy action directly. This way it conveniently degrades nicely
with javascript.

<%= link_to "Destroy", delete_item_path(item), :method
=> :delete, :confirm => "Are you sure?" %>

GET /items/1/delete # => maps to delete action with confirmation
screen
DELETE /items/1/delete # => maps to destroy action

If javascript is disabled it will fall back to a GET request and
therefore display a confirmation screen.

Having this defined by default in map.resources would be convenient
and won''t get in the way if not used. Whether or not scaffolding takes
advantage of this I don''t care.

Ryan


On Aug 10, 8:38 am, Jason King <smathy.w...@gmail.com>
wrote:
> On Aug 10, 2009, at 4:51 AM, Pratik wrote:
>
>
>
>
>
>
>
> > -1.
>
> > On Mon, Aug 10, 2009 at 12:39 PM, Yehuda Katz<wyc...@gmail.com>
wrote:
> >> I am in favor of a standard delete action, analagous to new and  
> >> edit. I
> >> can''t think of a good reason not to have it--it shows
good practice  
> >> and
> >> isn''t exactly a new concept.
>
> > It makes poor and slow UI.
>
> >> We have new and edit as HTML precursor actions
> >> for the POST and PUT verbs, why not delete as HTML precursor for  
> >> DELETE. One
> >> of the biggest wins of Rails is conventionality; when you come
into  
> >> a new
> >> Rails app, you don''t have to wonder what the edit action
is called.  
> >> Why not
> >> extend this to delete confirmation screens as well?
>
> > When you edit/create - you don''t just press one button. You
enter a
> > good amount of data too. That''s not true when you DELETE the
record in
> > 99.99% of the cases.
>
> Not sure I understand your position.  The existing functionality where  
> a JS dialogue appears requires the user to just press one button, and  
> you''re saying that this is good UI, but having an HTML form appear
 
> requiring the user to press a button is not good UI?
>
> Seems like precisely the same UI to me, just in two different forms  
> and with the obvious latency for the non-JS user.  As others have  
> mentioned, surely a slower UI is better than no UI at all?
>
> --
> Jason King

On Aug 10, 2009, at 11:58 AM, Ryan Bates wrote:
>
> +1 for the GET request on a delete action to show a confirmation
> dialog. Also if you send a DELETE call to this URL it could trigger
> the destroy action directly. This way it conveniently degrades nicely
> with javascript.
>
> <%= link_to "Destroy", delete_item_path(item), :method
> => :delete, :confirm => "Are you sure?" %>
>
> GET /items/1/delete # => maps to delete action with confirmation
> screen
> DELETE /items/1/delete # => maps to destroy action
>
> If javascript is disabled it will fall back to a GET request and
> therefore display a confirmation screen.
That''s very tidy, +1 on that specific permutation.

I presume the idea would be to have DELETE /items/1 still mapping to  
destroy as well, for backwards compat (with a deprecation notice).  If  
not - then -1 :)
> Having this defined by default in map.resources would be convenient
> and won''t get in the way if not used. Whether or not scaffolding
takes
> advantage of this I don''t care.
I think if you make it like this then you need to have scaffolding  
support it - otherwise (I think) you''ll get a missing template error  
when JS is disabled, which is untidy ->  "Won''t somebody PLEASE
think
of the newbs?!?"

+1 for scaffolding support.

Cheers,
Jason

On Aug 10, 2009, at 3:17 PM, Jason King wrote:
>
> On Aug 10, 2009, at 11:58 AM, Ryan Bates wrote:
>
>> GET /items/1/delete # => maps to delete action with confirmation
>> screen
>> DELETE /items/1/delete # => maps to destroy action
>>
>> If javascript is disabled it will fall back to a GET request and
>> therefore display a confirmation screen.
>
> That''s very tidy, +1 on that specific permutation.
>
> I presume the idea would be to have DELETE /items/1 still mapping to
> destroy as well, for backwards compat (with a deprecation notice).  If
> not - then -1 :)
I''d certainly hope there''s not a deprecation notice - the
''DELETE /
items/1/delete'' is distinctly un-RESTful. The HTTP verb is sufficient  
- do we really want to be POSTing to /items/create and PUTting to / 
items/1/update (again)?

--Matt Jones

The DELETE on /items/1/delete would only be for convenience to
gracefully degrade with javascript. The DELETE on /items/1 should
definitely stay.

Regards,

Ryan

On Aug 10, 12:31 pm, Matt Jones <al2o...@gmail.com>
wrote:
> On Aug 10, 2009, at 3:17 PM, Jason King wrote:
>
>
>
> > On Aug 10, 2009, at 11:58 AM, Ryan Bates wrote:
>
> >> GET /items/1/delete # => maps to delete action with
confirmation
> >> screen
> >> DELETE /items/1/delete # => maps to destroy action
>
> >> If javascript is disabled it will fall back to a GET request and
> >> therefore display a confirmation screen.
>
> > That''s very tidy, +1 on that specific permutation.
>
> > I presume the idea would be to have DELETE /items/1 still mapping to
> > destroy as well, for backwards compat (with a deprecation notice).  If
> > not - then -1 :)
>
> I''d certainly hope there''s not a deprecation notice - the
''DELETE /
> items/1/delete'' is distinctly un-RESTful. The HTTP verb is
sufficient  
> - do we really want to be POSTing to /items/create and PUTting to /
> items/1/update (again)?
>
> --Matt Jones

I strongly agree with Josh on this one.  Scaffolds should generate the
minimum necessary to get things working in the most common case.  When
you generate scaffolds you''re not writing tests, you''re not
thinking
about exact requirements, it''s just a proof of concept to get off the
ground.  Anything beyond the absolute basics should be something you
write yourself.

On Aug 9, 5:35 pm, Josh Susser <j...@hasmanythrough.com>
wrote:
> On Aug 9, 2009, at 5:20 PM, Kieran P wrote:
>
> > The generated scaffold relies on Javascript enabled to be able to
> > delete a record, which prevents anyone with JavasScript disabled to
> > delete it.
>
> > I''ve hacked a solution with a delete action in one of my
projects,
> > which works nicely, and cleanly. Basically, the link still have
> > Javascript which will work if enabled, but the url of the link goes to
> > a delete action, with a form that confirms the user wants to delete
> > (instead of a Javascript prompt).
>
> > Only took 3 new controller lines, 6 new view lines, 1 changed view
> > line, and a route :member.
>
> > Is this something that people would like to see in Rails 3?
>
> I''d vote NO.  Scaffolding isn''t about providing a
cross-browser  
> solution with graceful degradation.  It''s about giving you a
temporary  
> structure you can lean your app against while building it.  By the  
> time you want to launch the app, scaffolding should be replaced by  
> code you built yourself.  I don''t have anything against doing
things  
> the way you propose, but I''d rather scaffolding stay as minimal
and  
> simple as possible.  Every line of code in the scaffolding bears a  
> maintenance cost, and it seems better to keep it easy to upgrade than  
> make it feature-complete for end-users.
>
> --
> Josh Susserhttp://blog.hasmanythrough.com

> I strongly agree with Josh on this one.  Scaffolds should generate the
> minimum necessary to get things working in the most common case.  When
> you generate scaffolds you''re not writing tests, you''re
not thinking
> about exact requirements, it''s just a proof of concept to get off
the
> ground.  Anything beyond the absolute basics should be something you
> write yourself.
As do I.

Guys, the goal for scaffolding is to give new-developers a decent
intro into how to wire up a web application in rails.  it is *not*
intended to be used for production / shipping code.  It''s an education
tool, not a development tool.

Now before you come back and say "I use it in production!"
that''s
great, and so do I, but that''s not it''s primary goal.

We have several alternative scaffolding plugins which would be the
right place to have this functionality, the scaffolding in core
doesn''t need anything else.

-- 
Cheers

Koz

Thank you Yehuda. And because I feel strongly about this, I''ve made a
patch (which apparently is already marked ''wont fix'') at
https://rails.lighthouseapp.com/projects/8994/tickets/3029-patch-non-javascript-dependent-record-deletion-solution
It''s got documentation, code, and test changes.

It''s not hard to see why this is needed. Very simply, you
can''t delete
a record with Javascript disabled, and that is very bad!

However, I am also in support of the other solution mentioned in this
thread, of an inline form, with javascript confirmation as well, that
degrades. Some very simple styling, and the Delete button could be
made to look like a link. However, it still means users with
Javascript disabled could mistakenly click delete and its gone. So I''d
still prefer the delete action solution, because, as Chris said so
well, "some resources are too important to delete without
confirmation".

And as a reminder:
>> "It makes poor and slow UI. " - Pratik
No, it''s not. Users with Javascript on still get the Javascript
prompt, and when accepted, goes right ahead and hits the destroy
action (they don''t need to look at the delete action). This case only
handles where Javascript is disabled.
>> "the scaffolding in core doesn''t need anything
else." - Michael
But the core problem behind this change would still be present without
changes.

And it''s not a lot of scaffolding changes. It''s one existing
line
change, 3 new controller lines, and one small view file.

The rest of the code happens in tests/routing to allow the
delete_users_path(user) resources without having to add it to each
resource in routes.

It''s not a big ask considering some of the other scaffold changes that
have been proposed in another thread (support for _form partial,
changing all HTML markup).

Regards
Kieran

On Aug 10, 11:39 pm, Yehuda Katz <wyc...@gmail.com>
wrote:
> I am in favor of a standard delete action, analagous to new and edit. I
> can''t think of a good reason not to have it--it shows good
practice and
> isn''t exactly a new concept. We have new and edit as HTML
precursor
> actions for the POST and PUT verbs, why not delete as HTML precursor for
> DELETE. One of the biggest wins of Rails is conventionality; when you
> come into a new Rails app, you don''t have to wonder what the edit
action
> is called. Why not extend this to delete confirmation screens as well?
>
> -- Yehuda

FWIW,

I implement my delete actions by using a modified version of button_to  
which actually creates an inline form with a *button* tag instead of  
an input of type ''submit''

That way, I can style the button to appear exactly like a link. I can  
also attach the appropriate javascript to the form (instead of the  
button) to display the confirmation dialog and cancel the submit if  
necessary.

Like Nicolás, I am giving my +1 to actually changing submit_tag and  
button_to to a button tag and possibly upgrading the scaffold code to  
use button_to for delete actions.

-christos



On 10 Aug 2009, at 02:20, Kieran P wrote:
>
> Hello,
>
> The generated scaffold relies on Javascript enabled to be able to
> delete a record, which prevents anyone with JavasScript disabled to
> delete it.
>
> I''ve hacked a solution with a delete action in one of my projects,
> which works nicely, and cleanly. Basically, the link still have
> Javascript which will work if enabled, but the url of the link goes to
> a delete action, with a form that confirms the user wants to delete
> (instead of a Javascript prompt).
>
> Only took 3 new controller lines, 6 new view lines, 1 changed view
> line, and a route :member.
>
> Is this something that people would like to see in Rails 3?
>
> Regards
> Kieran
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google  
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
> -~----------~----~----~----~------~----~------~--~---
>