FAQ
I am having a problem with IE6 not displaying the page after a form has
been submitted. I can call up a form, fill it out, no problem. When I
submit it, I get 'Page cannot be displayed". This works fine in
Firefox, but not IE6. Also, the form data does get written to the
database in both browsers.

I don't have any choice but to use IE6.

It is calling the proper link and it looks like it is supposed to work.
Here is the output from the console. The sub that loads the form is
/prior/new_prior and the page that should load after the form is
submitted is /prior/list_prior

return_date | 2009-October-17
return_time | 3:30 am
submitted | Submit
'-------------------------------------+------------------------------------
[debug] "POST" request for "prior/new_prior" from "127.0.0.1"
[debug] Found sessionid "a4035af645732ec0374b0c6de0cb235a012c4b4d" in cooki
[debug] Restored session "a4035af645732ec0374b0c6de0cb235a012c4b4d"
[debug] Path is "prior/new_prior"
[debug] Catalyst::Controller::HTML::FormFu::Action::FormConfig loading conf
le 'prior/new_prior.yml'
[debug] Redirecting to "http://localhost:3000/prior/list_prior"
[info] Request took 6.334302s (0.158/s)
.------------------------------------------------------------+-----------.
Action | Time |
+------------------------------------------------------------+-----------+
/auto | 0.002467s |
/prior/new_prior | 6.282058s |
/end | 0.000742s |
'------------------------------------------------------------+-----------'

So, it seems to redirect the page to the list_prior as it is supposed to
but then for some reason, the new_prior is reloaded instead and I get a
page cannot be displayed error.

Here is my code, in case it matters.

=head2 new_prior

Create a Prior Approval application

=cut

sub new_prior : Local FormConfig('prior/new_prior.yml') {
my ($self, $c) = @_;

# load the new record object into the stash
$c->stash->{object} = $c->model('DB::Prior')->new_result({});

# Check permissions
$c->detach('/error_noperms')
unless $c->stash->{object}->create_allowed_by($c->user->get_object);

# Clicked the submit button and the form passed error checking
if ($c->stash->{form}->submitted_and_valid) {

# Force the username into the 'submitted_by' field
$c->stash->{form}->add_valid('submitted_by', $c->user->username);

# Force the status_id to 1
$c->stash->{form}->add_valid('status_id', 1);

# Write the record to the resultset
$c->stash->{form}->model->update($c->stash->{object});

# Update the status message
$c->flash->{status_msg} = 'Record created';

# Redirect to the list_prior page
$c->response->redirect($c->uri_for('list_prior'));

# Escape this subroutine
$c->detach;

# First load or form is reloaded due to failing error checking
} else {

# Re-evaluate the form
$c->stash->{form}->process();

}

# Run the code necessary to rename the repeatable elements to be
compatible with wforms.js
OMTSWeb::Controller::WForm::handle_repeat($c->stash->{form});

# Necessary to handle the hints that work work with wforms.js
OMTSWeb::Controller::WForm::handle_hints($c->stash->{form});

# Set the logo
$c->stash->{given_logo} = '/static/images/library.png';

# Set the title
$c->stash->{given_title} = 'Prior Approval';

# Set the page template that is used
$c->stash->{template} = 'prior/edit_prior.tt2';

}


Someone else seemed to have a similair problem a while back, but there
isn't a resolution.
http://www.mail-archive.com/[email protected]/msg04157.html

Search Discussions

  • Oleg Kostyuk at Oct 15, 2009 at 1:19 pm

    2009/10/14 Ascii King <[email protected]>:
    # Redirect to the list_prior page
    $c->response->redirect($c->uri_for('list_prior'));
    Long time ago I have problems with calling uri_for, using string as
    first argument. For me solution was to use action argument, and now I
    use only this way. May be, this help you to:

    $c->response->redirect($c->uri_for($self->action_for('list_prior')));

    HTH

    --
    Sincerely yours,
    Oleg Kostyuk (CUB-UANIC)
  • Ascii King at Oct 16, 2009 at 3:53 pm

    Oleg Kostyuk wrote:
    2009/10/14 Ascii King <[email protected]>:
    # Redirect to the list_prior page
    $c->response->redirect($c->uri_for('list_prior'));
    Long time ago I have problems with calling uri_for, using string as
    first argument. For me solution was to use action argument, and now I
    use only this way. May be, this help you to:

    $c->response->redirect($c->uri_for($self->action_for('list_prior')));

    HTH
    Thanks, Oleg. I tried it, but it didn't resolve my problem. I kept it
    in the code though.

    It seems that even though 'list_prior' is being called, it tries to load
    the page 'new_prior'. In Firefox, it makes the GET request properly:

    [debug] Redirecting to "http://localhost:3000/prior/list_prior"
    [info] Request took 7.597684s (0.132/s)
    .------------------------------------------------------------+-----------.
    Action | Time |
    +------------------------------------------------------------+-----------+
    /auto | 0.002454s |
    /prior/new_prior | 7.481939s |
    /end | 0.000714s |
    '------------------------------------------------------------+-----------'

    [info] *** Request 28 (0.134/s) [2516] [Fri Oct 16 11:11:09 2009] ***
    [debug] "GET" request for "prior/list_prior" from "127.0.0.1"
    [debug] Found sessionid "a78032d6668b68496d032b58142f921ffb76b9e9" in
    cookie
    [debug] Restored session "a78032d6668b68496d032b58142f921ffb76b9e9"
    [debug] Path is "prior/list_prior"
    [debug] Rendering template "prior/list_prior.tt2"

    But, in IE6 it hangs right here and displays a blank page if the form
    had errors on it or a 'page cannot be displayed' message if the
    form was submitted and valid. You can see that it is processing the
    redirect to the list_prior but it doesn't seem to send the "GET" request.

    [debug] Redirecting to "http://localhost:3000/prior/list_prior"
    [info] Request took 6.539849s (0.153/s)
    .------------------------------------------------------------+-----------.
    Action | Time |
    +------------------------------------------------------------+-----------+
    /auto | 0.002566s |
    /prior/new_prior | 6.488534s |
    /end | 0.000663s |
    '------------------------------------------------------------+-----------'
  • Ascii King at Oct 20, 2009 at 2:44 pm
    Solved it. I had it working on my linux server, but not my windows
    server, so I assumed it had to be an out-of-date mod. I went through
    almost every mod I could find that was associated with Catalyst and
    Formfu and upgraded them to the newest version. That solved it for me.

    I don't know which mod it was that fixed the problem, but i do know it
    wasn't Catalyst::Devel, catalyst::Runtime or HTML::Formfu

    Thanks for the help.
  • Alexander Hartmaier at Oct 20, 2009 at 3:29 pm
    Maybe HTTP::Server::Simple?
    The Changelog mentions win32 in the revisions from April.

    Am Dienstag, den 20.10.2009, 16:44 +0200 schrieb Ascii King:
    Solved it. I had it working on my linux server, but not my windows
    server, so I assumed it had to be an out-of-date mod. I went through
    almost every mod I could find that was associated with Catalyst and
    Formfu and upgraded them to the newest version. That solved it for me.

    I don't know which mod it was that fixed the problem, but i do know it
    wasn't Catalyst::Devel, catalyst::Runtime or HTML::Formfu

    Thanks for the help.

    _______________________________________________
    List: [email protected]
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/[email protected]/
    Dev site: http://dev.catalyst.perl.org/
    --
    best regards, Alex


    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
    T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
    Handelsgericht Wien, FN 79340b
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
    Notice: This e-mail contains information that is confidential and may be privileged.
    If you are not the intended recipient, please notify the sender and then
    delete this e-mail immediately.
    *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
  • Ascii King at Oct 20, 2009 at 6:51 pm

    Alexander Hartmaier wrote:
    Maybe HTTP::Server::Simple?
    The Changelog mentions win32 in the revisions from April.
    I did suspect that one, but I was updating groups at a time and then
    testing, so I can't be sure.
  • Tomas Doran at Oct 20, 2009 at 8:34 pm

    On 20 Oct 2009, at 19:51, Ascii King wrote:

    Alexander Hartmaier wrote:
    Maybe HTTP::Server::Simple?
    The Changelog mentions win32 in the revisions from April.
    I did suspect that one, but I was updating groups at a time and then
    testing, so I can't be sure.
    Can you _downgrade_ that release manually and retest?

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 14, '09 at 3:35p
activeOct 20, '09 at 8:34p
posts7
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2023 Grokbase