Redispatching actions

Hi there,

I was wondering if there was some way within the Catalyst
api to redispatch 
calls. The problem I'm having is:

package MyApp::C::Blah;

sub add : Local :Form(...) {
  if($form->submitted) {
    # Add to database
    $c->res->redirect($c->uri_for('view'))
  }
  # Generate form and display
}
sub edit : Local { ... same as add but fill out form
initially }
sub delete: Local {
  # Delete item
    $c->res->redirect($c->uri_for('view'))
}
sub view : Local {
  # display page
}
sub index : Private {
    $c->res->redirect($c->uri_for('view'))
}


This is an awful lot of duplicated code, forever looking up
the uri for view 
and then redirecting there when i want to send the user to
it. I could do 
$c->forward('view'), which would reduce the overhead, and
stop me having to 
send so many 302 responses etc, but because I'm using TT,
$c->action->name is 
automatically used as the template file to process, which is
what I want. I 
could do $c->stash-> = '/blah/view.tt' in
view(), but that's 
annoying as TT already does that for me automatically. There
must be some way 
to simply say "I want to redispatch to the view()
action" in such a way as 
$c->action->name is set to view, etc. I guess
Catalyst::Plugin::SubRequest 
would do that, but again that's quite a lot of overhead and
I don't really 
want all the request data to be localized... Anyone got any
ideas or should I 
write a $c->redispatch plugin?

Thanks,

Mark

_______________________________________________
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 Sun, May 20, 2007 at 01:55:41PM +0100, Mark Zealey
wrote:
> Hi there,
> 
> I was wondering if there was some way within the
Catalyst api to redispatch 
> calls. The problem I'm having is:
> 
> package MyApp::C::Blah;
> 
> sub add : Local :Form(...) {
>   if($form->submitted) {
>     # Add to database
>     $c->res->redirect($c->uri_for('view'))
>   }
>   # Generate form and display
> }
> sub edit : Local { ... same as add but fill out form
initially }
> sub delete: Local {
>   # Delete item
>     $c->res->redirect($c->uri_for('view'))
> }
> sub view : Local {
>   # display page
> }
> sub index : Private {
>     $c->res->redirect($c->uri_for('view'))
> }
> 
> 
> This is an awful lot of duplicated code, forever
looking up the uri for view 
> and then redirecting there when i want to send the user
to it. I could do 
> $c->forward('view'), which would reduce the
overhead, and stop me having to 
> send so many 302 responses etc, but because I'm using
TT, $c->action->name is 
> automatically used as the template file to process,
which is what I want. I 
> could do $c->stash-> = '/blah/view.tt'
in view(), but that's 
> annoying as TT already does that for me automatically.
There must be some way 
> to simply say "I want to redispatch to the view()
action" in such a way as 
> $c->action->name is set to view, etc. I guess
Catalyst::Plugin::SubRequest 
> would do that, but again that's quite a lot of overhead
and I don't really 
> want all the request data to be localized... Anyone got
any ideas or should I 
> write a $c->redispatch plugin?

A native feature to do this will be in 5.80.

However, in your case you -do- want to redirect anyway - it
means the
resultant URL for what the user sees will be correct so they
can bookmark it
and/or mail it to somebody else etc. etc.

I worked on some Maypole apps a few years back that -didn't-
redirect and
behaved the way you're looking at implementing and the
"wrong URL" problem
turned out to be a usability nightmare - I'd strongly,
strongly recommend
against it, sending a 302 really isn't that bad.

-- 
      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/

* Matt S Trout <dbix-classtrout.me.uk> [2007-05-20
15:55]:
> I worked on some Maypole apps a few years back that
-didn't-
> redirect and behaved the way you're looking at
implementing and
> the "wrong URL" problem turned out to be a
usability nightmare

That, plus the re-submit when the user hits the Back
button.

> I'd strongly, strongly recommend against it, sending a
302
> really isn't that bad.

Or 303. 

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/&g
t;

_______________________________________________
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/

A. Pagaltzis wrote:

> * Matt S Trout <dbix-classtrout.me.uk> [2007-05-20
15:55]:
> > I worked on some Maypole apps a few years back
that -didn't-
> > redirect and behaved the way you're looking at
implementing and
> > the "wrong URL" problem turned out to be
a usability nightmare

sub update : Local {
  my ($self, $c) = _;
  $c->detach('view') unless $c->request->method eq
'POST';
  ...

> That, plus the re-submit when the user hits the Back
button.

  ...
  unless ($c->validate_token) { #
Catalyst::Plugin::RequestToken
    $c->stash(message => 'Deja vu!'); # optional
verbosity
    $c->detach('view');
  }
  # do update here
  ...
  $c->remove_token;
  $c->forward('view');
}

> > I'd strongly, strongly recommend against it,
sending a 302
> > really isn't that bad.
>
> Or 303. 

No need for redirects and all the problems they impose.
-- 
Bernhard Graf

_______________________________________________
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 Sun, May 20, 2007 at 08:55:47PM +0200, Bernhard Graf
wrote:
> No need for redirects and all the problems they
impose.

I described the problems with -not- redirecting and yet you
assert their
being bad without justification.

I call straw man. Defend your position or withdraw, sir.

-- 
      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/

* Bernhard Graf <catalyst2augensalat.de>
[2007-05-20 21:05]:
> A. Pagaltzis wrote:
> > That, plus the re-submit when the user hits the
Back button.
> 
>   ...
>   unless ($c->validate_token) { #
Catalyst::Plugin::RequestToken
>     $c->stash(message => 'Deja vu!'); # optional
verbosity
>     $c->detach('view');
>   }

So loading an extra plugin and sprinkling guards all over
your
code is preferrable to you over simply issuing a redirect.
Not
only that, but your choice causes the following sequence of
events:

    User: *hits Back button*
    Computer: This page has POSTDATA. Resubmit it?
    User: (thinks) What the?! Hmm… err…
    User: *hits OK*
    Computer: Ack! You tried to resubmit a form! No cookie!
    User: #$&!!

Compare to the alternative, where successful submit produces
a
redirect:

    User: *hits Back button*
    Computer: *goes back a page*

Guess which one will annoy users less.

You said absolutely nothing to address the “wrong URL”
problem
Matt mentioned, btw.

Of course, you can spend your days writing code to fight the
way
HTTP works. It’s up to you to judge whether that is a
worthwhile
use of your time. But I do think you’d be happier and your
code
simpler and more robust if it didn’t try to cut against
the web’s
grain.

> No need for redirects and all the problems they
impose.

Can you explain one the problems, please?

Redirects are one of the greatest features of HTTP,
actually.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/&g
t;

_______________________________________________
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/

Matt S Trout wrote:

> On Sun, May 20, 2007 at 08:55:47PM +0200, Bernhard Graf
wrote:
> > No need for redirects and all the problems they
impose.
>
> I described the problems with -not- redirecting and yet
you assert
> their being bad without justification.

See my other response.
You can stay with redirects. No problem for me. ;^)
I just pointed out that you don't need them.

> I call straw man. Defend your position or withdraw,
sir.

H�??
-- 
Bernhard Graf

_______________________________________________
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/

Roland Lammel wrote:

> But then again this code has to be added to every
method, that is
> processing form input. In case it's not there... the
nightmare of
> reposting is back in town.

What are you trying to demonstrate?
"If more code isn't there, even more nightmares are in
town" - or what?

> I find it far more easy to actually perform a redirect
at the end of
> an action, that is intentional for the user and the
developer.
> I havn't come across any problems using redirects (not
even on mobile
> devices), so what kind of problems are you referring
too?

- Loosing state within one http request or maintaining
additional
  overhead to keep it beyond the redirect
- imposing additional load to the server
- trouble GET after POST under mod_perl as described in
  http://perl.apache.org/docs/1.0/gui
de/snippets.html#Redirecting_POST_Requests .
  Well, actually I suspect Catalyst already does the right
thing, but I
  was bitten by this issue long ago in the pre-Google era
when you could
  hardly find anything about this on the WWW.

> But as usual, it's probably a matter of taste anyway.

Indeed. Whenever I have to fix somebody else's web
application (usually
PHP), the number of HTTP redirects is inversely proportional
to the
quality of the code. So probably that is the main reason why
I try to
avoid them personally.
-- 
Bernhard Graf

_______________________________________________
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/

A. Pagaltzis wrote:

> * Bernhard Graf <catalyst2augensalat.de>
[2007-05-20 21:05]:
> > A. Pagaltzis wrote:
> > > That, plus the re-submit when the user hits
the Back button.
> >
> >   ...
> >   unless ($c->validate_token) { #
Catalyst::Plugin::RequestToken
> >     $c->stash(message => 'Deja vu!'); #
optional verbosity
> >     $c->detach('view');
> >   }
>
> So loading an extra plugin and sprinkling guards all
over your
> code is preferrable to you over simply issuing a
redirect. Not

Yes.

> only that, but your choice causes the following
sequence of
> events:
>
>     User: *hits Back button*
>     Computer: This page has POSTDATA. Resubmit it?
>     User: (thinks) What the?! Hmm… err…
>     User: *hits OK*
>     Computer: Ack! You tried to resubmit a form! No
cookie!
>     User: #$&!!
>
> Compare to the alternative, where successful submit
produces a
> redirect:
>
>     User: *hits Back button*
>     Computer: *goes back a page*
>
> Guess which one will annoy users less.

Written very nicely. Actually both variants are designed to
keep posting 
data twice, right?

> You said absolutely nothing to address the “wrong
URL” problem
> Matt mentioned, btw.

What wrong URL?
My example showed that http://example.com/dat
a/update is virtually equal 
to http://example.com/data/
view if not posted from a form.

> Of course, you can spend your days writing code to
fight the way
> HTTP works. It’s up to you to judge whether that is a
worthwhile
> use of your time. But I do think you’d be happier and
your code
> simpler and more robust if it didn’t try to cut
against the web’s
> grain.

I don't fight HTTP. A link is one thing, an action is a
different one.
While the first always is a static route to some other
place, the latter
*acts* upon (input) data and the resulting output depends on
this input 
data and potentially other data as well (like this
RequestToken status, 
that tells that the transaction has already been processed
when trying 
to redo the action, or the request method not being POST). 

> > No need for redirects and all the problems they
impose.
>
> Can you explain one the problems, please?

See my other post.

> Redirects are one of the greatest features of HTTP,
actually.

As GOTO is one of the greatest features of Basic - and of
course Perl.
-- 
Bernhard Graf

_______________________________________________
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/