The new stuff in dev Routes will make the addition of new subresources
easier. In this case, link("confirm_delete") on the SubMapper object
returned by submapper() or collection() would do nicely. Not everyone
will want it in quite the same way so I wouldn't necessarily make it a
standard action though.
I feel compelled to say after reading this entire thread that this
doesn't have to be unRESTful. REST doesn't mean sticking slavishly to
ATOM - isn't workflow via hyperlinks what HATEOAS is all about?
Regards,
Mike
[email protected]
http://positiveincline.com
On Jan 29, 9:33 pm, Mike Orr <[email protected]> wrote:
> 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.
