There are a couple of ways to tackle this problem ... The first and most straight-forward is to pass the parameters set in the first run-mode back into hidden form fields or anchor links within your template file. This method is demonstrated in the code snippet below:

    .
    .

    $html->param( $_ => $self->param($_) ) foreach $self->param();
    return $html->output;
}
[download]

For which the corresponding HTML::Template template file would look similar to the follow:

.
.

<input type="hidden" name="rm" value="list" />
<input type="hidden" name="id" value="<tmpl_var name="id">" />
<input type="hidden" name="name" value="<tmpl_var name="name">" />

.
.
[download]

This is the most simple and correspondingly most insecure manner for providing state persistence between run-modes using CGI::Application.

A far better approach to this issue of state persistence is to make use of a server-side based persistence solutions such as that offered by Apache::Session and CGI::Session - I demonstrated an example of such a server-side based persistence solution for CGI::Application with this post.

With this method, only a reference to the server-side storage of persistence data is sent to the client and as such these solutions offer greater security as persistence data is not directly accessible to the client. This is important with clients who with the former method could easily edit the HTML form values and return bogus data - For a further discussion on this, see Re: A CGI chained-event theory question.