Rails - May 2009 - Two destroy methods with different behavior for the model

I want to have two destroy methods for my model.

First method must be a "classic" destroy method — find a record and
destroy it. "Delete Forever" link in the view.
Second method must find a record and mark it as deleted (or as moved
to trash). "Move to Trash" link in the view.

How can I do this? Should I just use model.destroy for the first case
and write custom method for the second? In this case how can I make a
"Move to Trash" link for the second method in the view inaccessible
for spiders?

Or can I pass an argument for destroy method from view and depending
on that argument do a "classic" destroy or just mark the record as
deleted?

Or even something else?

On May 22, 9:09 am, Denis Kokin
<denis.ko...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I want to have two destroy methods for my model.
>
> First method must be a "classic" destroy method — find a record
and
> destroy it. "Delete Forever" link in the view.
> Second method must find a record and mark it as deleted (or as moved
> to trash). "Move to Trash" link in the view.
>
> How can I do this? Should I just use model.destroy for the first case
> and write custom method for the second? In this case how can I make a
> "Move to Trash" link for the second method in the view
inaccessible
> for spiders?
>
I would go this way. Whenever you display records to the end user
you''ll need to check for that flag ( named_scope and/or default_scope
may be useful here).

Fred
> Or can I pass an argument for destroy method from view and depending
> on that argument do a "classic" destroy or just mark the record
as
> deleted?
>
> Or even something else?

Thank you, Frederick.

Can you give me more details? Some sample code would be useful for me.

Denis,

I did this sort of thing with user accounts a while ago.. I had set up
a site that needed to mark users as ''inactive'' if they ever
decided to
close their account.

Your issue with web crawlers seeing the Move to Trash link makes me
think this page is public and not member-only accessible? If so, I
can''t think of any way to tell a spider to not look at particular
parts of the text (maybe there is a way, i''ve always done a
traditional approach and told the spider to leave my whole page
alone). Either way, on to a possible solution:

The two actions I would have are:
(already in your code) desotry - this action houses the traditional
rails destroy method that will remove the record from the table and
any dependencies.
(need to add) move_to_trash - the new action that will call the
move_to_tash method we will create on the object in view

Explanation:
You should not modify the destroy action and following rails
conventions and good programming practice I would not pass a parameter
into a destroy action and then decide what kind of ''destroy''
to
execute. Rather, let''s create a second action called move_to_trash
with the same access privileges as the destroy. The reason we do this
is because logically our two actions are doing very different things,
one is destroying a sql record and the other is changing an attribute
on an object.

So we add a move_to_trash method to the model and subsequently we will
want a new column on our model moved_to_trash (boolean). Now the
move_to_trash action will call the model.move_to_trash and then that
method will called a self.update_attribute(:moved_to_trash, true).

[[Alternatively, this is where I like to encourage using enums in your
database and have your model have states. It could be very clean to
have a column "status" and then you
have :moved_to_trash, :inbox, :other_cool_states ]]

Hopefully you find this helpful. If you provide more details about
your particular situation we can work out a solution that fits.

On May 22, 1:54 am, Denis Kokin
<denis.ko...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Thank you, Frederick.
>
> Can you give me more details? Some sample code would be useful for me.

Thank you, Mike.

I''ve already made two different methods, just as you explained.





On May 24, 12:12 am, Mike Rose
<MFRosengar...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Denis,
>
> I did this sort of thing with user accounts a while ago.. I had set up
> a site that needed to mark users as ''inactive'' if they
ever decided to
> close their account.
>
> Your issue with web crawlers seeing the Move to Trash link makes me
> think this page is public and not member-only accessible? If so, I
> can''t think of any way to tell a spider to not look at particular
> parts of the text (maybe there is a way, i''ve always done a
> traditional approach and told the spider to leave my whole page
> alone). Either way, on to a possible solution:
>
> The two actions I would have are:
> (already in your code) desotry - this action houses the traditional
> rails destroy method that will remove the record from the table and
> any dependencies.
> (need to add) move_to_trash - the new action that will call the
> move_to_tash method we will create on the object in view
>
> Explanation:
> You should not modify the destroy action and following rails
> conventions and good programming practice I would not pass a parameter
> into a destroy action and then decide what kind of
''destroy'' to
> execute. Rather, let''s create a second action called move_to_trash
> with the same access privileges as the destroy. The reason we do this
> is because logically our two actions are doing very different things,
> one is destroying a sql record and the other is changing an attribute
> on an object.
>
> So we add a move_to_trash method to the model and subsequently we will
> want a new column on our model moved_to_trash (boolean). Now the
> move_to_trash action will call the model.move_to_trash and then that
> method will called a self.update_attribute(:moved_to_trash, true).
>
> [[Alternatively, this is where I like to encourage using enums in your
> database and have your model have states. It could be very clean to
> have a column "status" and then you
> have :moved_to_trash, :inbox, :other_cool_states ]]
>
> Hopefully you find this helpful. If you provide more details about
> your particular situation we can work out a solution that fits.
>
> On May 22, 1:54 am, Denis Kokin
<denis.ko...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Thank you, Frederick.
>
> > Can you give me more details? Some sample code would be useful for me.