Vladimir S. Tikhonjuk wrote:

>Hi all!
>
>    Our company has a backoffice project written on C++ ( Qt ) for Linux
>by my department. But nessesity appear's to make WEB interface, with all
>functions which our C++ program does. Now I have to choose among a lot
>of languages and technologies of WEB development.
>
>    I have a lot of experience with perl, and we already have an Apache
>2 WEB server, so first, I look at  mod_perl. Reading documentation and
>making some practice with mod_perl, I didn't find ( or understand ) how
>to solve some, for my point of view, standart tasks.
>
>    1. Reading form parameters ( i.e. POST data of request header ).
>
>  
>

Use CGI.pm or libapreq also known as Apache2::Request.

http://search.cpan.org/~lds/CGI.pm-3.20/
http://search.cpan.org/~joesuf/libapreq2-2.07/

<http://search.cpan.org/%7Ejoesuf/libapreq2-2.07/glue/perl/lib/Apache2/Request.pm>

>    2. Result of first question  :)  Sessions.
>
>    As I understand, I need session to save ( restore ) user data
>between requests. What for ? Now I'll try to explain.
>
>  
>
Use Apache::Session or CGI::Session

http://search.cpan.org/~cwest/Apache-Session-1.81/
http://search.cpan.org/~markstos/CGI-Session-4.14/

>So, why I need session's or pnote's for passing data between handlers if
>I can make vars like $Promtelecom::Authentication::password and
>$Promtelecom::Authentication::login and access them from other handlers?
>
>  
>
Because when storing informations in global variables they presist
between requests made to this very apache child.
Pnotes only stay for this single request. In short if you restore this
information when making the next request which maybe
totally unrelated to the first one this information is still there.
Please see below why you cannot use this to restore
persistent information.

>    3. Database persistant connection.
>
>    As I understand, such possibility I can get only using Apache::DBI
>module. So, here is my httpd.conf:
>
>
>  
>
If I'm not complete mistaken but others may know better Apache::DBI
persists connections on a per-child base
so as long as you hit other children when requesting pages (you don't
have control over that because this is done by).
This is also the reason why it won't help you to restore information in
this global scope variables.

Please search the archives for a discussion about request handling by
apache.

http://mail-archives.apache.org/mod_mbox/perl-modperl/200504.mbox/[EMAIL 
PROTECTED]

>You have already seen my Promtelecom::Authentication module ( question 2
>), so here is a simple code of Promtelecom::Debitor:
>
>======= PostDataParser.pm BEGIN =======
>
>package Promtelecom::Debitor;
>
>use strict;
>use Apache2::Const -compile => qw( OK );
>
>
>sub handler {
>  my $r = shift;
>
>  my $dbh = DBI->connect( 'dbi:Pg:dbname=database;host=database',
>$Promtelecom::Authentication::user,
>$Promtelecom::Authentication::password, { AutoCommit => 0 } );
>
>  return Apache2::Const::OK;
>}
>
>1;
>
>======= PostDataParser.pm END =======
>
>So, here is what I'm waiting from mod_perl:
>
>1. Client open browser and enter address http://myserver/debitor
>2. Apache ( on myserver ) get the request, and call's PerlAuthenHandler
>Promtelecom::Authentication
>3. Client get then window with login and password line edits.
>4. Client enters login and password.
>5. Promtelecom::Authentication gets client's login and password and try
>to set database connection using these datas.
>
>In /var/log/apache2/error_log I see something like:
>
>11836 Apache::DBI             new connect to
>'dbname=database;host=databaseuserpasswordAutoCommit=0PrintError=1Username=user'
>
>6. If connection established, Apache calls PerlHandler Promtelecom::Debitor
>7. Here I think that Apache::DBI will see that
>Promtelecom::Authentication already established database connection with
>same parameters and  returns me this connection, but I see new string in
>err_log here:
>
>11838 Apache::DBI             new connect to
>'dbname=database;host=databaseuserpasswordAutoCommit=0PrintError=1Username=user'
>
>Where is a mistake ?
>
>Best regards,
>Vladimir S. Tikhonjuk
>  
>
Tom

Reply via email to