Use Undo on A List Apart

There's a recent article titled "Never Use a Warning
When you Mean
Undo" at http
://alistapart.com/articles/neveruseawarning.

I'm wondering about the implementation.

One option is to create actions for every possible undo
operation.
That would mean that each undo operation would generate a
specific
link, including request parameters to identify the item that
needed to
be, well, undone.

Another possibility would be to generate the code for the
undo action
and place it in the session so that there's just an /undo
link.  /undo
fetches the code and evals/executes it.  The /undo link
would only be
available for a single request after displaying the undo
link.

If the undo link is part of the server response the back
button might
lead to a stale undo link.  If that's a problem I suppose
could do an
AJAX request to fetch the link to prevent it showing up if
using the
back button.

Comments?


-- 
Bill Moseley
moseleyhank.org


_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Hi,

Le 26 juil. 07 à 08:55, Bill Moseley a écrit :

> There's a recent article titled "Never Use a
Warning When you Mean
> Undo" at http
://alistapart.com/articles/neveruseawarning.
>
> I'm wondering about the implementation.
>

I read that too. Interesting, but from what I see undo is
not so easy  
to implement.

> One option is to create actions for every possible undo
operation.
> That would mean that each undo operation would generate
a specific
> link, including request parameters to identify the item
that needed to
> be, well, undone.
>
> Another possibility would be to generate the code for
the undo action
> and place it in the session so that there's just an
/undo link.  /undo
> fetches the code and evals/executes it.  The /undo link
would only be
> available for a single request after displaying the
undo link.

I like more the idea of a generic undo request. This could
be part of  
a plugin providing this action and the necessary
infrastructure to  
implement the "un-doing" of the action.
This plugin could implement a simple version of the classic
Memento  
pattern (http://e
n.wikipedia.org/wiki/Memento_pattern)

Then you could declare undoable actions like this:

sub delete : Local Undoable {
     my ($self, $c) = _;
     ...

     $c->save_undo( $object );
}

# Actual undo action
sub undo_delete : Private {
   my ($self, $c, $restored_object) = _;
   ...
   # recreate object from $restored_object
}

The generic undo action would then forward to the above
declared  
undo_delete action, restoring the saved object.
This would even perhaps allow multi-level undo.


> If the undo link is part of the server response the
back button might
> lead to a stale undo link.  If that's a problem I
suppose could do an
> AJAX request to fetch the link to prevent it showing up
if using the
> back button.
>

Could be in the plugin too, I guess.

-- 
Matthieu Codron
matthieucodron.org
_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On Sat, Jul 28, 2007 at 01:00:14PM +0200, Matthieu Codron
wrote:
> Hi,
> 
> Le 26 juil. 07 à 08:55, Bill Moseley a écrit :
> 
> >There's a recent article titled "Never Use a
Warning When you Mean
> >Undo" at http
://alistapart.com/articles/neveruseawarning.
> >
> >I'm wondering about the implementation.
> >
> 
> I read that too. Interesting, but from what I see undo
is not so easy  
> to implement.
> 
> >One option is to create actions for every possible
undo operation.
> >That would mean that each undo operation would
generate a specific
> >link, including request parameters to identify the
item that needed to
> >be, well, undone.
> >
> >Another possibility would be to generate the code
for the undo action
> >and place it in the session so that there's just an
/undo link.  /undo
> >fetches the code and evals/executes it.  The /undo
link would only be
> >available for a single request after displaying the
undo link.
> 
> I like more the idea of a generic undo request. This
could be part of  
> a plugin providing this action and the necessary
infrastructure to  
> implement the "un-doing" of the action.

I fail entirely to see why this should be a plugin rather
than part of the
model you're intending to make mutations upon undoable.

> This plugin could implement a simple version of the
classic Memento  
> pattern (http://e
n.wikipedia.org/wiki/Memento_pattern)

I'd say DBIx-Class-Audit (currently in bast trunk pending
more testing)
already implements this pretty well for DBIC models - except
it always saves
the appropriate information, saving you needing to call
anything at all to
make the undo happen.

-- 
      Matt S Trout       Need help with your Catalyst or
DBIx::Class project?
   Technical Director    Want a managed development or
deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at)
shadowcatsystems.co.uk for a quote
http://chainsawblues.vo
x.com/             http://www.shadowc
atsystems.co.uk/ 

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Le 28 juil. 07 à 14:05, Matt S Trout a écrit :
>
>>
>> I like more the idea of a generic undo request.
This could be part of
>> a plugin providing this action and the necessary
infrastructure to
>> implement the "un-doing" of the action.
>
> I fail entirely to see why this should be a plugin
rather than part  
> of the
> model you're intending to make mutations upon
undoable.

Maybe it does not have to be a plugin. But it can't be
exclusively in  
the model layer either, I guess? (I fail to see this one)
The original idea was to provide a generic /undo action to
perform  
the undo. The idea of tagging actions with a
"Undoable" annotation  
was to register the action with the undo framework on the
controller  
side, so that /undo knows where to forward the undo
command.

The actual undoing could reside in the model.

>> This plugin could implement a simple version of the
classic Memento
>> pattern (http://e
n.wikipedia.org/wiki/Memento_pattern)
>
> I'd say DBIx-Class-Audit (currently in bast trunk
pending more  
> testing)
> already implements this pretty well for DBIC models -
except it  
> always saves
> the appropriate information, saving you needing to call
anything at  
> all to
> make the undo happen.
>

Did not know of that, thanks for the info!

-- 
Matthieu Codron
matthieucodron.org
_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/