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 f
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 no
> 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.
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
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 wrote:
> On Aug 10, 2009, at 3:17 PM, Jason King wrote:
>
>
>
> > On Aug 10, 2009, at 11:58 AM, Ryan B
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 requ
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 "De
+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 =
On Aug 10, 2009, at 4:51 AM, Pratik wrote:
>
> -1.
>
> On Mon, Aug 10, 2009 at 12:39 PM, 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
+1 for using button_to instead of link_to.
And if submit_tag were to generate a instead of an
then +100 :)
-foca
On Mon, Aug 10, 2009 at 9:37 AM, Mislav
Marohnić wrote:
> On Mon, Aug 10, 2009 at 13:58, Yehuda Katz wrote:
>>
>> Are you suggesting that we just put an inline small form
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 a
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 wrote:
> MatthewRudy wrote:
> > I think this is something that is always annoying.
> > Namely I have to reinvent a convention to handle this.
On Mon, Aug 10, 2009 at 12:58 PM, Yehuda Katz 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'r
On 10-Aug-09, at 8:37 AM, Mislav Marohnić wrote:
> On Mon, Aug 10, 2009 at 13:58, Yehuda Katz 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 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.
On Mon, Aug 10, 2009 at 13:58, Yehuda Katz 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
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 an
Pratik wrote:
> -1.
>
+2
> On Mon, Aug 10, 2009 at 12:39 PM, 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.
>>
>
> It makes po
-1.
On Mon, Aug 10, 2009 at 12:39 PM, 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.
It makes poor and slow UI.
> We have new and edit as HTML p
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 hav
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. On
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
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 c
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 clean
24 matches
Mail list logo
