Apache2-PageKit

 view release on metacpan or  search on metacpan

docsrc/reference.xml  view on Meta::CPAN

  ## inside your Common.pm, maybe also in your Modelclass to overwrite the one in Common.pm

  sub pkit_on_error {
    my ( $model, $err ) = @_;
    my $page_id = $model->pkit_get_page_id;

    if ( $err =~ /DBI/ ) {
      # prevent endless loop if the error happened on our errorpage.
      return $err if ( $page_id =~ /db_error_page$/ );
      $model->pkit_redirect('db_error_page');
      return;
    }

    $model->pkit_message( $err );
    my $default_page = $model->pkit_get_default_page;
    return $err if ( $page_id =~ /^$default_page$/ );
    $model->pkit_redirect($default_page);
    return;
  }

     </synopsis>
    </refsynopsisdiv>
    <refsect1>
     <title>Description</title>
     <para>

pkit_on_error main purpose is to catch errors for some reason. Maybe you can not
 get a database connection or your page can not be delivered in a special
 charset or anywhere inside your modelcode an uncatched die "for unknown
 reason"; is executed.
</para>
<para>
If nowhere else in your code this error is handled, pkit_on_error is called
 with the error message as second parameter and model as the first. This is
 your chance to deliver a working page. At best with pkit_redirect or pkit_send.
</para>
<para>
If an error happened inside pkit_on_error it is passed thru Apache and you get the internal server
 error as before. pkit_on_error returns the error_msg that is logged. So you
 can change the messsage if you like. If the returned error_msg is '' or undef
 nothing is logged and pkit assumes, that the error is repaired. If you like
 to log anyway add a warn $error_msg"; inside your pkit_on_error routine.
</para>
<para>
Also pkit_on_error is no replacement for Apache::ErrorReport. pkit_on_error
 is more a runtime error catcher for most cases. A::E reports errors more
 clear with stacktrace and so on. Both can happy live together.
</para>
<para>
Another advantage is that you need only pkit_on_error to catch the error even
 if your application has millions of cases where it could fail. There is no
 need to catch them all.
</para>
<para>
If pkit_on_error is not defined in your modelclass or Common.pm, it is not used.
</para>
<para>
pkit_on_error catch only fatal errors (die) NOT warnings.
</para>
<para>
If your code likes to throw an error let it die.
     </para>
    </refsect1>
   </refentry>

   <refentry id="model.api.pkit_session_setup">
    <refnamediv>
     <refname>pkit_session_setup</refname>
     <refpurpose>
      Returns Session setup arguments.
     </refpurpose>
    </refnamediv>
    <refsynopsisdiv>
     <synopsis>
  # here a MySQL example:
  sub pkit_session_setup {
    my $model = shift;
    my $dbh = $model->dbh;
    return {
	session_lock_class => 'MySQL',
	session_store_class => 'MySQL',
	session_args => {
			Handle => $dbh,
			LockHandle => $dbh,
			},
	};
  }

  # this one is if you prefer PostgreSQL
  sub pkit_session_setup {
    my $model = shift;
    my $dbh = $model->dbh;

    my %session_setup = (
  	session_store_class => 'Postgres',
  	session_lock_class => 'Null',
  	session_serialize_class => 'Base64',
  	session_args => {
  			 Handle => $dbh,
                           IDLength => 32,
                           Commit => 0,
                          }
    );
    return \%session_setup;
  }

     </synopsis>
    </refsynopsisdiv>
    <refsect1>
     <title>Description</title>
     <para>
      Method must return a hash reference using <ulink url="http://kobesearch.cpan.org/search?dist=Apache-SessionX">Apache::SessionX</ulink> session
      setup arguments.  This hash reference should contain the following key/value pairs:
     </para>
     <variablelist>
      <varlistentry>
       <term>session_store_class</term>
       <listitem>
        The object store class that should be used for
         Apache::SessionX session handling.
       </listitem>



( run in 0.429 second using v1.01-cache-2.11-cpan-39bf76dae61 )