In my experience, there’s really only one sure-fire way to diagnose problems like this:   use the debugging facilities or plug-in of your favorite browser to LQQK at the HTTP GET/POST data that is being sent and that is being received.

Your <input type="checkbox" ...> tags do not have a value= attribute, and I suspect that this is the problem.   You would be able to instantly confirm (or disprove ...) this when you look at what your browser actually sends.

yes thank you i did notice the value tag missing, just didnt think it was the best solution. Im glad you pointed it out.

your suggestion to check post headers also was spot on. Even without using value tag, i see the solution is that the checkbox is not passed as a parameter when it is not selected. when selected checkbox value is set to 'on'. thanks.

so i see now there is some quirk involved. and unchecked checkboxes are not passed in the session. im using a conditional check in my CGI::Application module to set checkbox to off if the query parameter is not available in the session.

 
#checkbox needs a fix as it is not set in POST if unchecked
       if (!defined($query->param('c_scl'))){
         $c_scl = 'off';
       }
      else {
         $c_scl = $query->param('c_scl');
      }
[download]

If i dont do this, then i see that the fields in my template "after" the checkbox are not getting retrieved/ showing field names instead of field values in the html (sounds wierd) $self->tt_process('school_register.tt',\%ret_params);. I/m fairly certain there is a possible issue either in TT or in my TT code specifically, so i have to post this to the TT mailing list.

I see a few problems

urls are hardcoded ...

debugging via log ... eew

$global_session ... super yuck

random suspicious or die on $! usage not seen in the docs

CGI::Application::Plugin::Session is broken as session_config seems to have no effect

your logic is fudgy, you don't use P/R/G

both collect_data and display_data are the same form, and pretty much the same code, and in both codes you fetch data from the $cgi_query and not from the $session -- this is fudge -- and in both display and collect you save data into session -- display is display

I think having templates and logging and "everything" is confusing you (it confused me), its just a lot of stuff to juggle

You should start with pictures, for example

collectPage
    presents a form
    processes form submission
       if got valid data
           save data into session
           redirect via get to displayPage
       if got invalid data
           show form again
           while explaining what data is bad

displayPage
     if session 
          display data from session
     if no session
          give link to collectPage
[download]

err. newbie code. ok thank you for pointing these out. will go a long way in my development as a perl developer.

err. newbie code. ok thank you for pointing these out. will go a long way in my development as a perl developer.

We've all been there :)

sub collect_data {
    my $self = shift;
    my( $page_data, $errors ) = valiDaaTTTee( $self->query, $validatio
+nProfile )
    if( $errors ){
        return $self->tt_process('collect_data.tt', $errors );
    } else {
        $self->validated_session( $page_data );
        return $self->redirect( $self->url_for('display) ); 
    }
}
[download]

on success you do a redirect get with a url_for('display') not 'mode2' ... matching names makes make things easier ...

valiDaaTTTee can be some something you write using Data::FormValidator kinda like CGI::Application::Plugin::ValidateRM

Want to inspect sessions? If viewing your temp or session directory isn't enough, you can always write a session viewer in your admin.cgi :)

Now to add sub validated_session { } and sub url_for { } and sub valiDaaTTTee { } ... redirect comes from plugin