aristotle laid some criticism on CGI::Prototype based on heavy usage of it. Let's take his first criticism:
Its core idea is the "stay on this page or go to another" mechanism. This is directly in opposition to POST-redirect-GET and therefore to good HTTP style. I didn’t have to fight CGIP to do things properly, but I had to ignore its offerings and manually devise everything I needed.

stay or go

Yes, the core of CGI::Prototype is the activate function and what he says about stay or go is obvious if you look at the code: 
sub activate {
  my $self = shift;
  eval {
    $self->prototype_enter;
    $self->app_enter;
    my $this_page = $self->dispatch;
    $this_page->control_enter;
    $this_page->respond_enter;
    my $next_page = $this_page->respond; ## STAY OR GO!
    $this_page->respond_leave;
    if ($this_page ne $next_page) {
      $this_page->control_leave;
      $next_page->control_enter;
    }
    $next_page->render_enter;
    $next_page->render;
    $next_page->render_leave;
    $next_page->control_leave;
    $self->app_leave;
    $self->prototype_leave;
  };
  $self->error($@) if $@;    # failed something, go to safe mode
}

[download]

what is POST-redirect-GET

POST-redirect-GET is best explained by example. Let's say you are filling out a form and it posts to /register_user

What the webapp would do is store the POSTed data in the session stash and then issue a redirect to the same URL but via a GET, and most likely the GET would retrieve the session data and say "thank you for registering" or offer to confirm the entered data.

why is that cool?

To be honest, what I see is twice as many hits on my server just because someone did not want to call an in-memory function.

But I think the argument is that the GET form of /register_user could be used to present user registration data at many times based on query string data and other things. And so have a well-formed URL API to that rendering functionality is important. And if one resorted to functions, one might not separate the idea of storing a user versus displaying the results of such storage.

I get along just fine without POST-redirect-GET

Because CGI::Prototype is quite modular, the rendering of user registration is handled in a different model. So, after getting the POST data via one module (let's say User::Register), I then confirm it via another module (i.e. User::Register::Confirm) and the code the the User::Register module would have a  respond method that would return 'User::Register::Confirm' Here is actual code from a working CGI::Prototype website of mine... the respond method basically looks at the form data and either confirms the signup or makes the user redo... and all without using redirects: 
sub respond {
  my $self = shift;

  my $results = Data::FormValidator->check( $self->CGI, $dfv_profile )
+;
  my $response_page;

  if ( $results->has_missing() || $results->has_invalid() ) {

    $response_page = 'Gimble::Page::Signup::Redo';
    eval "require $response_page";
    $response_page->reflect->addSlots( results => $results );
  } else {
    $response_page = $self;
  }

  return $response_page;
}

[download]

Which do you like and why

Feel free to tell me how you would do this in your favorite framework. We dont hear enought about Jifty these days... wha about Mojo, Catalyst... share your ideas on this topic.

In reply to CGI::Prototype criticism 1 - cannot use POST-redirect-GET paradigm by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.