On Fri, Jan 29, 2010 at 10:18 AM, Vladimir Dronnikov
<[email protected]> wrote:
> Thanks for feedback. My appoach is similar.
> I appended an additional member for resource mapper in config/routing.py:
> ...
> map.resource('model', 'models', path_prefix='/admin/{model_name}',
> controller='admin', member={'confirm':'GET'})
That's what I did, only I used:
member={"ask_delete": "GET"}
I think this should be added to Routes. Delete confirmation is
necessary in many interactive applications.
> and redirected my 'Delete' links to this method.
>
> But wonder if the same effect can be achieved more reliably (and
> elegantly) by means of some kind of guarding decorators applied to
> potentially dangerous (mostly destructive) methods?
>
> We have such decorators for authentication/authorization purpose. Have
> anyone seen such for confirmation problem?
Interactive users won't get to the delete action except through the
form. They can't enter it directly into the URL box because that
always produces a GET. Non-interactive agents are accustomed to
producing 'DELETE' requests directly, and wouldn't know what to do
with a form anyway.
You can undoubtedly simulate a confirmation with a decorator, but just
adding a GET URL with a form seems more straightforward.
You can't double up the confirmation form and the delete action on the
same URL, at least not with REST, because GET'ting the same URL
displays the record. So you have to use a different URL for the
confirmation form.
Or you can use Javascript to display a confirmation alert dialog.
That's a kind of "decorator". But it would be bypassed in non-visual
browsers or if Javascript is disabled.
I don't understand Vlad's point:
> Confirmation is a process that is not fully compatible with (pure) REST,
because requests must not be dependent of previous ones.
> But if you need one, think of it as a "Deletion resource". POST to
create a "deletion resource". The response is a form containing a nonce
token, ...
A pure REST client would not use the confirmation, it would just
DELETE the resource directly. The confirmation step, if any, would be
built into the client itself. But there's nothing wrong with adding
additional GET URLs to resources. That's just asking the resource to
show a different "view" of itself. And if the view happens to contain
a form that submits a delete action, so what?
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
