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?

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

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.

Thank you, Mike.

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