pagekit-devel — For PageKit Developers only.

Re: [Pagekit-devel] Model code is executed twice if page eq default-page

[Boris Z. <bz...@2b...>]

Hi Pieter,

Am Donnerstag, 13. Mai 2004 22:43 schrieb pdu...@so...:
> Hi Boris,
>
> On Thu, May 13, 2004 at 08:40:05PM +0200, Boris Zentner wrote:
> > Hi Pieter,
> >
> > this is not a bug, $default_code_perl_sub should be called before the
> > page_sub itself.
>
> I agree: "$default_code_perl_sub should be called before the page_sub
> itself", and my fix would have violated this.
>
> What I'm trying to avoid is the case of where
> $default_code_perl_sub and page_sub are exactly the same function.

I see that, but this can only happen if you call

http://your_site.xy/xxx/pkit_default

and if so it might be your intent since you must prepare pkit_default to serve 
something on its own, it must have a *.tmpl or you get a error anyway.

> In this case, the same function is called twice, and
> this should not happen.
>
> Like I said, the first fix is wrong, but how about this one:
>
>   $default_code_perl_sub = undef unless (defined &$default_code_perl_sub);
>
>   my @subs = ($pk->page_sub);

Sometimes we do not have a page_sub. Then we end with @subs = ( undef ) but 
scalar(@subs) == 1 which makes call_model_code() unhappy.

I suggest this ( untested ):

Index: PageKit.pm
===================================================================
--- PageKit.pm  (revision 127)
+++ PageKit.pm  (working copy)
@@ -999,6 +999,9 @@
   my $pk = shift;
   my $page_id = shift || $pk->{page_id};

+  return if $page_id =~ /pkit_default$/;
+
   # change all the / to ::
   $page_id =~ s!/!::!g;

>   if (defined($default_code_perl_sub) &&
>       $default_code_perl_sub ne $pk->page_sub) {
>       unshift(@subs, $default_code_perl_sub);
>   }
>   return $pk->call_model_code(@subs) if (@subs);
>
> cu
> --
> Pieter
>
> > Look here: http://pagekit.org/guide/re15.html
> >
[...]
-- 
Boris

Re: [Pagekit-devel] Model code is executed twice if page eq default-page

[<pdu...@so...>]

Hi Boris,

On Thu, May 13, 2004 at 08:40:05PM +0200, Boris Zentner wrote:
> 
> Hi Pieter,
> 
> this is not a bug, $default_code_perl_sub should be called before the page_sub 
> itself.

I agree: "$default_code_perl_sub should be called before the page_sub itself",
and my fix would have violated this.

What I'm trying to avoid is the case of where
$default_code_perl_sub and page_sub are exactly the same function.
In this case, the same function is called twice, and
this should not happen.

Like I said, the first fix is wrong, but how about this one:

  $default_code_perl_sub = undef unless (defined &$default_code_perl_sub);

  my @subs = ($pk->page_sub);
  if (defined($default_code_perl_sub) &&
      $default_code_perl_sub ne $pk->page_sub) {
      unshift(@subs, $default_code_perl_sub);
  }
  return $pk->call_model_code(@subs) if (@subs);

cu
--
Pieter

> 
> Look here: http://pagekit.org/guide/re15.html
> 
> Am Donnerstag, 13. Mai 2004 19:38 schrieb pdu...@so...:
> > Hi,
> >
> > Please take a look at line 968 of PageKit.pm:
> >
> >   966:  $default_code_perl_sub = undef unless (defined
> > &$default_code_perl_sub);
> >
> >   967:
> > > 968:  my @subs = grep { $_ } ( $default_code_perl_sub, $pk->page_sub );
> >
> >   969:  return $pk->call_model_code(@subs) if (@subs);
> >
> > Spotted it? ;-)
> >
> > Here's the bug described in <perl>
> > if ($default_code_perl_sub eg $pk->page_sub) {
> >
> >    # @subs == ($default_code_perl_sub, $default_code_perl_sub),
> >    # which means the model code for $default_code_perl_sub will be
> >    # run twice!
> >
> > }
> > </perl>
> >
> > I suggest changing line 968 to:
> >
> > 968:  my @subs = grep { $_ } ( $pk->page_sub ) || ( $default_code_perl_sub
> > );
> >
> > This bug is potentially quite nasty, if some of the
> > following is done in the default code:
> > - state keeping
> > - logging
> > - db-write actions like updates, inserts and deletes.
> >
> > cu
> > --
> > Pieter
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: SourceForge.net Broadband
> > Sign-up now for SourceForge Broadband and get the fastest
> > 6.0/768 connection for only $19.95/mo for the first 3 months!
> > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> > _______________________________________________
> > Pagekit-devel mailing list
> > Pag...@li...
> > https://lists.sourceforge.net/lists/listinfo/pagekit-devel
> 
> -- 
> Boris
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Pagekit-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagekit-devel

Re: [Pagekit-devel] Model code is executed twice if page eq default-page

[Boris Z. <bz...@2b...>]

Hi Pieter,

this is not a bug, $default_code_perl_sub should be called before the page_sub 
itself.

Look here: http://pagekit.org/guide/re15.html

Am Donnerstag, 13. Mai 2004 19:38 schrieb pdu...@so...:
> Hi,
>
> Please take a look at line 968 of PageKit.pm:
>
>   966:  $default_code_perl_sub = undef unless (defined
> &$default_code_perl_sub);
>
>   967:
> > 968:  my @subs = grep { $_ } ( $default_code_perl_sub, $pk->page_sub );
>
>   969:  return $pk->call_model_code(@subs) if (@subs);
>
> Spotted it? ;-)
>
> Here's the bug described in <perl>
> if ($default_code_perl_sub eg $pk->page_sub) {
>
>    # @subs == ($default_code_perl_sub, $default_code_perl_sub),
>    # which means the model code for $default_code_perl_sub will be
>    # run twice!
>
> }
> </perl>
>
> I suggest changing line 968 to:
>
> 968:  my @subs = grep { $_ } ( $pk->page_sub ) || ( $default_code_perl_sub
> );
>
> This bug is potentially quite nasty, if some of the
> following is done in the default code:
> - state keeping
> - logging
> - db-write actions like updates, inserts and deletes.
>
> cu
> --
> Pieter
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Pagekit-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagekit-devel

-- 
Boris

[Pagekit-devel] Model code is executed twice if page eq default-page

[<pdu...@so...>]

Hi,

Please take a look at line 968 of PageKit.pm:

  966:  $default_code_perl_sub = undef unless (defined &$default_code_perl_sub);
  967:
> 968:  my @subs = grep { $_ } ( $default_code_perl_sub, $pk->page_sub );
  969:  return $pk->call_model_code(@subs) if (@subs);

Spotted it? ;-)

Here's the bug described in <perl>
if ($default_code_perl_sub eg $pk->page_sub) {

   # @subs == ($default_code_perl_sub, $default_code_perl_sub),
   # which means the model code for $default_code_perl_sub will be
   # run twice!

}
</perl>

I suggest changing line 968 to:

968:  my @subs = grep { $_ } ( $pk->page_sub ) || ( $default_code_perl_sub );

This bug is potentially quite nasty, if some of the
following is done in the default code:
- state keeping
- logging
- db-write actions like updates, inserts and deletes.

cu
--
Pieter

Re: [Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[Boris Z. <bz...@2b...>]

Hi,

Am Dienstag, 11. Mai 2004 20:59 schrieb pdu...@so...:
>
> > Ok, I change the output.
>
> I had a look at the diff and it looks Ok, but I have some requests:
>
> I simulated the error and got the following output:
> === begin ===
> one or more tables exists already.
> For security reason we do not overwrite it.
> === end ===
>
> I'll change this to read:
> === begin ===
> One or more tables already exist.
> For security reasons they will not be overwritten.
> === end ===
>
> BTW, this is of course technically wrong, as no database (that I know of)
> will allow you to create a table if it already exists.
>

Sure you are right, I change the script to skip the table, if it exists.

[...]
>
> What I wanted to show in the demo, is how an application can be built
> that is "completely database-type independent". Database-type
> dependency is something that stops most potential developers from
> using a certain package. If it is in the demo, it will impress people
> (even hard core, large-site guys), I think. Just consider the
> following fact: Bricolage == postgres and Krang == mysql
>
> Whatever, the demo is probably good enough as it is.
>
> > What I mean is we need a better beginner tutorial with a pagekit-cookbook
> > ;-). And a better understanding of errors that can occur while trying
> > A::P.
>
> Yes, I admit, that would have helped me too ;-). I you want to, I'll
> help you with something like this.

That whould be really wonderfull. Perhaps we can build the cookbook, docs 
links and so on in a wiki. I search for a solution.

>
> cu
> --
> Pieter

-- 
Boris

Re: [Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[<pdu...@so...>]

Hi Boris,


> Ok, I change the output.

I had a look at the diff and it looks Ok, but I have some requests:

I simulated the error and got the following output:
=== begin ===
one or more tables exists already.
For security reason we do not overwrite it.
=== end ===

I'll change this to read:
=== begin ===
One or more tables already exist.
For security reasons they will not be overwritten.
=== end ===

BTW, this is of course technically wrong, as no database (that I know of)
will allow you to create a table if it already exists.

> I attach the current version of pkit_setup_db.pl not tested so far.

Ok, only if you add your name to the "AUTHOR" section :).

> Im unsure if this is the way to go, pagekit is a very powerfull system, the 
> users have already more or less experience with databases, apache and perl 
> for large applications. They just need to know what to do, not something that 
> do something that satisfy most users. Every PageKit user is already a 
> developer.

You have a better feeling for this, I agree.

What I wanted to show in the demo, is how an application can be built
that is "completely database-type independent". Database-type
dependency is something that stops most potential developers from
using a certain package. If it is in the demo, it will impress people
(even hard core, large-site guys), I think. Just consider the
following fact: Bricolage == postgres and Krang == mysql

Whatever, the demo is probably good enough as it is.

> What I mean is we need a better beginner tutorial with a pagekit-cookbook ;-).
> And a better understanding of errors that can occur while trying A::P.

Yes, I admit, that would have helped me too ;-). I you want to, I'll
help you with something like this.

cu
--
Pieter

Re: [Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[Boris Z. <bz...@2b...>]

Hi,

Am Dienstag, 11. Mai 2004 17:47 schrieb pdu...@so...:
> Hi Boris,
>
> > I include your script to the next release. Perhaps with some minor
> > modifications. Maybe we should test if a table exists already instead=
 of
> > the filetest.
>
> No problem, you can modify it. Maybe it will be a good idea to also
> modify pkit_setup_sqlite_dbfile.pl, so that it calls pkit_setup_db.pl,
> in order to minimize code, errors and maintenance.
>
> Here is what happens when you already have the tables in the db:
>
> $ ~/dev/pagekit=C5pache-PageKit/scripts/pkit_setup_db.pl Pg pagekit pag=
euser
> xxx DBD::Pg::db do failed: ERROR:  relation "pkit_user"already exists a=
t
> /home/pdupreez/dev/pagekit=C5pache-PageKit/scripts/pkit_setup_db.pl lin=
e 56.
> ERROR:  relation "pkit_user"already exists at
> /home/pdupreez/dev/pagekit=C5pache-PageKit/scripts/pkit_setup_db.pl lin=
e 56.
>
> It's cluttered, but clear to me. On the other hand it might be worth
> to wive a better output (or even success) to a new-be. One possible

Ok, I change the output.

> trap will be, if the table is owned by another user. It already
> happened to me, as I created the tables by hand. The problem appears
> later, when the application can't access the tables, even though they
> are there.

Yes, but Im not sure if we ever can ensure that the user do it right. The=
re=20
are so much databases. And note, that the tables for session and pkit_use=
r=20
can differ a lot from the example.

I attach the current version of pkit_setup_db.pl not tested so far.

>
> The ultimate solution will be something like this:
> - Tell the user which db drivers he has installed (see
>   pkit_setup_db.pl for an example)
> - Force the user to first setup their Config/Config.xml
>   A harsh part in the README, or even a curses script might do.
> - Add the following variables to Config/Config.xml (maybe in a
>   separate section, like 'database'):
>   - DBD (database driver)
>   - Database name
>   - Database user (not needed if db is set up for httpd user)
>   - Database pwd (     ditto    )
> - Write a pkit_setup.pl that reads Config/Config.xml in order to:
>   - Do a sanity check on Config/Config.xml. This will reduce some
>   first-run-time frustration (and stupid mistakes).
>   - Check and populate the db.

Im unsure if this is the way to go, pagekit is a very powerfull system, t=
he=20
users have already more or less experience with databases, apache and per=
l=20
for large applications. They just need to know what to do, not something =
that=20
do something that satisfy most users. Every PageKit user is already a=20
developer.

What I mean is we need a better beginner tutorial with a pagekit-cookbook=
 ;-).
And a better understanding of errors that can occur while trying A::P.

>
> > Thanks a lot!
>
> No problem!
>
> cu
> --
> Pieter

--=20
Boris

Re: [Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[<pdu...@so...>]

Hi Boris,

> I include your script to the next release. Perhaps with some minor 
> modifications. Maybe we should test if a table exists already instead of the 
> filetest.

No problem, you can modify it. Maybe it will be a good idea to also
modify pkit_setup_sqlite_dbfile.pl, so that it calls pkit_setup_db.pl,
in order to minimize code, errors and maintenance.

Here is what happens when you already have the tables in the db:

$ ~/dev/pagekitÅpache-PageKit/scripts/pkit_setup_db.pl Pg pagekit pageuser xxx
DBD::Pg::db do failed: ERROR:  relation "pkit_user"already exists at
/home/pdupreez/dev/pagekitÅpache-PageKit/scripts/pkit_setup_db.pl line 56.
ERROR:  relation "pkit_user"already exists at
/home/pdupreez/dev/pagekitÅpache-PageKit/scripts/pkit_setup_db.pl line 56.

It's cluttered, but clear to me. On the other hand it might be worth
to wive a better output (or even success) to a new-be. One possible
trap will be, if the table is owned by another user. It already
happened to me, as I created the tables by hand. The problem appears
later, when the application can't access the tables, even though they
are there.

The ultimate solution will be something like this:
- Tell the user which db drivers he has installed (see
  pkit_setup_db.pl for an example)
- Force the user to first setup their Config/Config.xml
  A harsh part in the README, or even a curses script might do.
- Add the following variables to Config/Config.xml (maybe in a
  separate section, like 'database'):
  - DBD (database driver)
  - Database name
  - Database user (not needed if db is set up for httpd user)
  - Database pwd (     ditto    )
- Write a pkit_setup.pl that reads Config/Config.xml in order to:
  - Do a sanity check on Config/Config.xml. This will reduce some
  first-run-time frustration (and stupid mistakes).
  - Check and populate the db.

> Thanks a lot!
No problem!

cu
--
Pieter

Re: [Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[Boris Z. <bz...@2b...>]

Hi Pieter,

I include your script to the next release. Perhaps with some minor 
modifications. Maybe we should test if a table exists already instead of the 
filetest.

Thanks a lot!

Am Dienstag, 11. Mai 2004 08:23 schrieb pdu...@so...:
> Hi,
>
> I renamed and modified Boris Zentner's pkit_setup_sqlite_dbfile.pl script,
> in order to be db driver independent. For more details, please
> read the contained pod-part of the script below. Tests were successful,
> using the SQLite and Pg DBD drivers. No other drivers were tested,
> but there should be no need to test others ;-).
>
> pkit_setup_db.pl is a contribution and may be added to the project
> (and changed), if it is useful.
>
> === Start of pkit_setup_db.pl ===
> #!/usr/bin/perl -w
> # $Id: $
>
> use strict;
> use warnings FATAL => 'all';
> use DBI;
>
>
> my @driver_names = DBI->available_drivers();
> $#driver_names > 0 ||	die "You have NO drivers available!\n" .
> 	"Please install at least DBD::SQLite or others from CPAN.\n";
>
> if ($#ARGV != 3) {
> 	my $usage = "Usage: $0 driver dbName userName auth\n" .
> 		"For the example site, use the following:\n" .
> 		"$0 SQLite dbfile \"\" \"\"\n";
> 	if ($#driver_names >= 0) {
> 		$usage .= "You have the following installed drivers available:\n";
> 		foreach my $driver (@driver_names) {
> 			$usage .= "$driver ";
> 		}
> 		$usage .= "\n";
> 	}
> 	else {
> 		$usage .= "You have NO drivers available!\n" .
> 			"Please install at least DBD::SQLite or others from CPAN.\n";
> 	}
> 	die $usage;
> }
>
> my $driver = $ARGV[0];
> my $data_source = $ARGV[1];
> my $username = $ARGV[2];
> my $auth = $ARGV[3];
>
> if (!grep(/^$driver$/, @driver_names)) {
> 	my $msg .= "Driver '$driver' is not in the " .
> 		"list of installed drivers!\n" .
> 		"You have the following installed drivers available:\n";
> 	foreach my $driver (@driver_names) {
> 		$msg .= "$driver ";
> 	}
> 	$msg .= "\n";
> 	die $msg;
> }
>
> # The following has a flaw. See bugs, below.
> -e $data_source and die <<"EXISTS_ALREADY";
> File, '$data_source', exists already.
> For security reason we do not overwrite it.
> EXISTS_ALREADY
>
> my $dbh = DBI->connect( "dbi:$driver:dbname=$data_source", $username,
> $auth, { AutoCommit => 1, PrintError => 1, RaiseError => 0 } ) or die
> $DBI::errstr;
>
> $dbh->do(
>   q{
>     CREATE TABLE pkit_user (
>       user_id CHAR(8), login CHAR(255), email CHAR(255), passwd CHAR(255)
>     )}
> ) or die $DBI::errstr;
>
> $dbh->do(
>   q{
>     CREATE TABLE sessions (
>       id char(32) not null primary key,
>       a_session text
>     )}
> ) or die $DBI::errstr;
> $dbh->disconnect;
>
> =pod
>
> =head1 NAME
>
> pkit_setup_db.pl
>
> =head1 SYNOPSIS
>
> This script creates the tables, pkit_user and sessions in the specified
> database.
>
> =head1 REQUIREMENTS
>
> A DBD driver that matches the specified database. In the case of the
> Apache::PageKit example, DBD::SQLite is required.
>
> =head1 USAGE
>
> pkit_setup_db.pl driver dbName userName auth
>
> =over
>
> =item -
>
> C<driver> is the name of the DBD driver that matches the database
> being used.
>
> =item -
>
> C<dbName> is the name of the database. When using file-based
> databases, as with for instance SQLite, it will be the file name.
>
> =item -
>
> C<userName> is the user name that will be used to login and create
> the tables in the database.
>
> =item -
>
> C<auth> is the authentication string needed to log into the database.
>
> =back
>
> =head1 DESCRIPTION
>
> The script logs into the specified database using the specified
> user name and authentication string. It then creates the tables
> pkit_user and sessions.
>
>
> CREATE TABLE pkit_user (
> 	user_id CHAR(8), login CHAR(255), email CHAR(255), passwd CHAR(255)
> )
>
> CREATE TABLE sessions (
>       id char(32) not null primary key,
>       a_session text
> )
>
>
> This may be useful for starting an application, using Apache::PageKit.
>
> =head1 EXAMPLES
>
>   pkit_setup_db.pl dbfile "" ""
>   pkit_setup_db.pl pagekit "" ""
>   pkit_setup_db.pl pagekit pageusr 'Q#Se$Re;w'
>
> =head1 BUGS
>
> The script has at least one flaw, in that if a dbName is the name of
> a non-file-based database (like Postgres) _and_ a file of that name
> exists, the script stops. The problem is that I don't know how to check
> it, and I don't want to overwrite the file. The work-around will be to
> cd to somewhere, where no such a file exists, or mv the file that
> has the same name as dbName.
>
> =head1 NOTES
>
> For the Apache::PageKit demo, the SQLite driver must be used.
> The script will produce the database file in the cwd.
>
> =head1 CREDITS
>
>   Boris Zentner <bz...@2b...>, for the initial script,
>   pkit_setup_sqlite_dbfile.pl, where this script was copied
>   and modified from.
>
> =head1 AUTHOR
>
>   Pieter du Preez <pdu...@so...>
>
> === End of pkit_setup_db.pl ===
>
> cu
> --
> Pieter
>

-- 
Boris

[Pagekit-devel] contribute: pkit_setup_db.pl, a more generic pkit_setup_sqlite_dbfile.pl

[<pdu...@so...>]

Hi,

I renamed and modified Boris Zentner's pkit_setup_sqlite_dbfile.pl script,
in order to be db driver independent. For more details, please
read the contained pod-part of the script below. Tests were successful,
using the SQLite and Pg DBD drivers. No other drivers were tested,
but there should be no need to test others ;-).

pkit_setup_db.pl is a contribution and may be added to the project
(and changed), if it is useful.

=== Start of pkit_setup_db.pl ===
#!/usr/bin/perl -w
# $Id: $

use strict;
use warnings FATAL => 'all';
use DBI;


my @driver_names = DBI->available_drivers();
$#driver_names > 0 ||	die "You have NO drivers available!\n" .
	"Please install at least DBD::SQLite or others from CPAN.\n";

if ($#ARGV != 3) {
	my $usage = "Usage: $0 driver dbName userName auth\n" .
		"For the example site, use the following:\n" .
		"$0 SQLite dbfile \"\" \"\"\n";
	if ($#driver_names >= 0) {
		$usage .= "You have the following installed drivers available:\n";
		foreach my $driver (@driver_names) {
			$usage .= "$driver ";
		}
		$usage .= "\n";
	}
	else {
		$usage .= "You have NO drivers available!\n" .
			"Please install at least DBD::SQLite or others from CPAN.\n";
	}
	die $usage;
}

my $driver = $ARGV[0];
my $data_source = $ARGV[1];
my $username = $ARGV[2];
my $auth = $ARGV[3];

if (!grep(/^$driver$/, @driver_names)) {
	my $msg .= "Driver '$driver' is not in the " .
		"list of installed drivers!\n" .
		"You have the following installed drivers available:\n";
	foreach my $driver (@driver_names) {
		$msg .= "$driver ";
	}
	$msg .= "\n";
	die $msg;
}

# The following has a flaw. See bugs, below.
-e $data_source and die <<"EXISTS_ALREADY";
File, '$data_source', exists already.
For security reason we do not overwrite it.
EXISTS_ALREADY

my $dbh = DBI->connect( "dbi:$driver:dbname=$data_source", $username, $auth, { AutoCommit => 1, PrintError => 1, RaiseError => 0 } )
  or die $DBI::errstr;

$dbh->do(
  q{
    CREATE TABLE pkit_user (
      user_id CHAR(8), login CHAR(255), email CHAR(255), passwd CHAR(255)
    )}
) or die $DBI::errstr;

$dbh->do(
  q{ 
    CREATE TABLE sessions (
      id char(32) not null primary key,
      a_session text
    )}
) or die $DBI::errstr;
$dbh->disconnect;

=pod

=head1 NAME

pkit_setup_db.pl

=head1 SYNOPSIS

This script creates the tables, pkit_user and sessions in the specified
database.

=head1 REQUIREMENTS

A DBD driver that matches the specified database. In the case of the
Apache::PageKit example, DBD::SQLite is required.

=head1 USAGE

pkit_setup_db.pl driver dbName userName auth

=over

=item -

C<driver> is the name of the DBD driver that matches the database
being used.

=item -

C<dbName> is the name of the database. When using file-based
databases, as with for instance SQLite, it will be the file name.

=item -

C<userName> is the user name that will be used to login and create
the tables in the database.

=item -

C<auth> is the authentication string needed to log into the database.

=back

=head1 DESCRIPTION

The script logs into the specified database using the specified
user name and authentication string. It then creates the tables
pkit_user and sessions.


CREATE TABLE pkit_user (
	user_id CHAR(8), login CHAR(255), email CHAR(255), passwd CHAR(255)
)

CREATE TABLE sessions (
      id char(32) not null primary key,
      a_session text
)


This may be useful for starting an application, using Apache::PageKit.

=head1 EXAMPLES

  pkit_setup_db.pl dbfile "" ""
  pkit_setup_db.pl pagekit "" ""
  pkit_setup_db.pl pagekit pageusr 'Q#Se$Re;w'

=head1 BUGS

The script has at least one flaw, in that if a dbName is the name of
a non-file-based database (like Postgres) _and_ a file of that name
exists, the script stops. The problem is that I don't know how to check
it, and I don't want to overwrite the file. The work-around will be to
cd to somewhere, where no such a file exists, or mv the file that
has the same name as dbName.

=head1 NOTES

For the Apache::PageKit demo, the SQLite driver must be used.
The script will produce the database file in the cwd.

=head1 CREDITS

  Boris Zentner <bz...@2b...>, for the initial script,
  pkit_setup_sqlite_dbfile.pl, where this script was copied
  and modified from.

=head1 AUTHOR

  Pieter du Preez <pdu...@so...>

=== End of pkit_setup_db.pl ===

cu
--
Pieter

[Pagekit-devel] ANNOUNCE: Apache::PageKit 1.14

[Boris Z. <bz...@2b...>]

Hi,

soon on CPAN.
You can get it here now.

http://eg.2bz.de/Apache-PageKit-1.14.tar.gz

1.14
 	- Fix: parse for xsl-params again in the xsl files. This was=20
 		broken in 1.13. ( Ben Ausden )
	- Fix: add use Apache::PageKit::Model to eg/Model/MyPageKit/Common.pm
		since it is possible that the application class is loaded
		before Apache::PageKit ( Boris Zentner )
	- the eg site use DBD::SQLite now. This obsoletes
		DBD::CSV, SQL::Statement and Text::CSV_XS.
		( Boris Zentner )
	- fop_command can be disabled with fop_command =3D ""
		( Boris Zentner, Shimon Rura )
	- Remove Apache->request calls from Apache::PageKit::Edit
		just to make apache 2 changes smaller ( Boris Zentner )
	- Fix: Parse Accept-Charsets more pettier ( Boris Zentner )
	! If the client browser has no accept charset header or no good one,
		deliver in the default_output_charset and set the charset
		in the content_type header. ( Erik G=C3=BCnther )
	- Fix uri_prefix in conjunction with can_edit
		( Boris Zentner, Erik G=C3=BCnther )=20

--=20
Boris

Re: [Pagekit-devel] patch for running in different Locations

[Boris Z. <bz...@2b...>]

Hi Pieter,

Am Donnerstag, 6. Mai 2004 21:53 schrieb pdu...@so...:
> Hi,
>
> I'm happy to say that I installed PageKit and that I got the demo
>
> working in DocumentRoot. I then read the FAQ:
> > Can I run more as one site with one Apache Server?
> >
> > Sure, as long as ...
>
> I wasn't so interested in getting more than one site running, and did
> not try it. What I wanted to try was to move the Location from / to
> /pagekit:
>

We have already a solution to move pagekit to a different location. Just do

<Perl>
use Apache::PageKit();
Apache::PageKit->startup('/var/www/pagekit','staging');
</Perl>

<Location /pagekit>
SetHandler perl-script
PerlSetVar PKIT_ROOT /var/www/pagekit
PerlSetVar PKIT_SERVER staging
PerlHandler +Apache::PageKit
</Location>

It looks a bit mad, but this config works on Apache 1.3 and Apache 2.
sure you must add

	uri_prefix="/pagekit"

in the global section of your Config.xml. See:

http://www.pagekit.org/guide/reference.html#d0e694

> Working httpd.conf (Location = DocumentRoot):
>
> #<Perl>
> #  use Apache::DB ();
> #  Apache::DB->init;
> #</Perl>
> #PerlFixupHandler +Apache::DB
>
> SetHandler perl-script
> PerlModule Apache::ErrorReport
> PerlSetVar ErrorReportHandler display
>
> PerlSetVar PKIT_ROOT /var/www/pagekit
> PerlSetVar PKIT_SERVER staging
> PerlSetVar PKIT_DOCROOT /pagekit
> PerlHandler +Apache::PageKit
> <Perl>
>   Apache::PageKit->startup;
> </Perl>
> ######################
>
> Non-working httpd.conf (Location != DocumentRoot):
>
> <Location /pagekit>
>   #<Perl>
>   #  use Apache::DB ();
>   #  Apache::DB->init;
>   #</Perl>
>   #PerlFixupHandler +Apache::DB
>
>   SetHandler perl-script
>   PerlModule Apache::ErrorReport
>   PerlSetVar ErrorReportHandler display
>
>   PerlSetVar PKIT_ROOT /var/www/pagekit
>   PerlSetVar PKIT_SERVER staging
>   PerlSetVar PKIT_DOCROOT /pagekit
>   PerlHandler +Apache::PageKit
>   <Perl>
>     Apache::PageKit->startup;
>   </Perl>
> </Location>
> ######################
>
> The first problem was obvious: PKIT_ROOT and PKIT_SERVER is not set
> up, or are not read properly, when declared inside <Location>.
> The quick fix was:
>
> PerlSetVar PKIT_ROOT /var/www/pagekit
> PerlSetVar PKIT_SERVER staging
>
> <Location /pagekit>
>   #<Perl>
>   #  use Apache::DB ();
>   #  Apache::DB->init;
>   #</Perl>
>   #PerlFixupHandler +Apache::DB
>
>   SetHandler perl-script
>   PerlModule Apache::ErrorReport
>   PerlSetVar ErrorReportHandler display
>
>   #PerlSetVar PKIT_ROOT /var/www/pagekit
>   #PerlSetVar PKIT_SERVER staging
>   PerlSetVar PKIT_DOCROOT /pagekit
>   PerlHandler +Apache::PageKit
>   <Perl>
>     Apache::PageKit->startup;
>   </Perl>
> </Location>
>
> I now got apache to accept the httpd.conf file again. The next problem
> (the one that I made the patch for), was that the index page was being
> served the whole time. PageKit.pm seems to assume that the <Location>
> is alway = <DocumentRoot>.
>
> The fix I made, incorporates another PKIT_ variable, that I called
> PKIT_DOCROOT (PKIT_LOCATION might be better???). This variable is then
> used in PageKit.pm and Edit.pm, in order to fix the hrefs. With my
> attached patch, I managed to get the demo working, regardless of the
> <Location>, if and only if the PKIT_DOCROOT variable is set to the
> <Location>. A small note: PerlSetVar works within <Location> for
> PKIT_DOCROOT, as it is read at request-time. And a last note:
> View/Default/pkit_edit/open_file.tmpl has a hard-coded part:
>    <form action="/pkit_edit/commit_file?...
>                 ^^^
> This still needs to be solved. Who has a good idea?

This was a bug and is already resolved in pagekit 1.14_01

http://eg.2bz.de/Apache-PageKit-1.14_01.tar.gz

>
> I think it is essential that PKIT_ROOT needs to be able to be
> specified within <Location>. Do you want me to have a look at how this
> could be done?

This is a mod_perl issue. What version do you use?

>
> Finally, after giving up on php, mason and a few others, I learnt
> HTML::Template and started writing all mu stuff with that. Fortunately
> I discovered Apache::PageKit, as I would probably only have arrived at
> such an elegant solution only in a few years... Well done! You saw the
> light before the rest. I'll be keen to assist, permitting I find the
> time to do so.
>
> cu
> --
> Pieter du Preez

-- 
Boris

[Pagekit-devel] patch for running in different Locations

[<pdu...@so...>]

Hi,

I'm happy to say that I installed PageKit and that I got the demo
working in DocumentRoot. I then read the FAQ:

> Can I run more as one site with one Apache Server?
>
> Sure, as long as ...

I wasn't so interested in getting more than one site running, and did
not try it. What I wanted to try was to move the Location from / to
/pagekit: 

Working httpd.conf (Location = DocumentRoot):

#<Perl>
#  use Apache::DB ();
#  Apache::DB->init;
#</Perl>
#PerlFixupHandler +Apache::DB

SetHandler perl-script
PerlModule Apache::ErrorReport
PerlSetVar ErrorReportHandler display

PerlSetVar PKIT_ROOT /var/www/pagekit
PerlSetVar PKIT_SERVER staging
PerlSetVar PKIT_DOCROOT /pagekit
PerlHandler +Apache::PageKit
<Perl>
  Apache::PageKit->startup;
</Perl>
######################

Non-working httpd.conf (Location != DocumentRoot):

<Location /pagekit>
  #<Perl>
  #  use Apache::DB ();
  #  Apache::DB->init;
  #</Perl>
  #PerlFixupHandler +Apache::DB

  SetHandler perl-script
  PerlModule Apache::ErrorReport
  PerlSetVar ErrorReportHandler display

  PerlSetVar PKIT_ROOT /var/www/pagekit
  PerlSetVar PKIT_SERVER staging
  PerlSetVar PKIT_DOCROOT /pagekit
  PerlHandler +Apache::PageKit
  <Perl>
    Apache::PageKit->startup;
  </Perl>
</Location>
######################

The first problem was obvious: PKIT_ROOT and PKIT_SERVER is not set
up, or are not read properly, when declared inside <Location>.
The quick fix was:

PerlSetVar PKIT_ROOT /var/www/pagekit
PerlSetVar PKIT_SERVER staging

<Location /pagekit>
  #<Perl>
  #  use Apache::DB ();
  #  Apache::DB->init;
  #</Perl>
  #PerlFixupHandler +Apache::DB

  SetHandler perl-script
  PerlModule Apache::ErrorReport
  PerlSetVar ErrorReportHandler display

  #PerlSetVar PKIT_ROOT /var/www/pagekit
  #PerlSetVar PKIT_SERVER staging
  PerlSetVar PKIT_DOCROOT /pagekit
  PerlHandler +Apache::PageKit
  <Perl>
    Apache::PageKit->startup;
  </Perl>
</Location>

I now got apache to accept the httpd.conf file again. The next problem
(the one that I made the patch for), was that the index page was being
served the whole time. PageKit.pm seems to assume that the <Location>
is alway = <DocumentRoot>.

The fix I made, incorporates another PKIT_ variable, that I called
PKIT_DOCROOT (PKIT_LOCATION might be better???). This variable is then
used in PageKit.pm and Edit.pm, in order to fix the hrefs. With my
attached patch, I managed to get the demo working, regardless of the
<Location>, if and only if the PKIT_DOCROOT variable is set to the
<Location>. A small note: PerlSetVar works within <Location> for
PKIT_DOCROOT, as it is read at request-time. And a last note: 
View/Default/pkit_edit/open_file.tmpl has a hard-coded part:
   <form action="/pkit_edit/commit_file?...
                ^^^
This still needs to be solved. Who has a good idea?

I think it is essential that PKIT_ROOT needs to be able to be
specified within <Location>. Do you want me to have a look at how this
could be done?

Finally, after giving up on php, mason and a few others, I learnt
HTML::Template and started writing all mu stuff with that. Fortunately
I discovered Apache::PageKit, as I would probably only have arrived at
such an elegant solution only in a few years... Well done! You saw the
light before the rest. I'll be keen to assist, permitting I find the
time to do so.

cu
--
Pieter du Preez

[Pagekit-devel] Apache-PageKit-1.14_01

[Boris Z. <bz...@2b...>]

Hi,

I like to release a new version of Apache-PageKit. It is currently avail =
here:

http://eg.2bz.de/Apache-PageKit-1.14_01.tar.gz

I hope some of you report problems or success back. If all goes well, it =
makes=20
the way to CPAN on monday.

1.14
 	- Fix: parse for xsl-params again in the xsl files. This was=20
 		broken in 1.13. ( Ben Ausden )
	- Fix: add use Apache::PageKit::Model to eg/Model/MyPageKit/Common.pm
		since it is possible that the application class is loaded
		before Apache::PageKit ( Boris Zentner )
	- the eg site use DBD::SQLite now. This obsoletes
		DBD::CSV, SQL::Statement and Text::CSV_XS.
		( Boris Zentner )
	- fop_command can be disabled with fop_command =3D ""
		( Boris Zentner, Shimon Rura )
	- Remove Apache->request calls from Apache::PageKit::Edit
		just to make apache 2 changes smaller ( Boris Zentner )
	- Fix: Parse Accept-Charsets more pettier ( Boris Zentner )
	! If the client browser has no accept charset header or no good one,
		deliver in the default_output_charset and set the charset
		in the content_type header. ( Erik G=C3=BCnther )
	- Fix uri_prefix in conjunction with can_edit
		( Boris Zentner, Erik G=C3=BCnther )=20

--=20
Boris

Re: [Pagekit-devel] XSL params issue with 2-14_03

[Boris Z. <bz...@2b...>]

Hi Ben,

I have just uploaded 2.14_06 with your patch and minor changes just for the 
case where pkit_admin is on. It also handles the PAGE_ID_XSL_PARAMS problem.

Please test it.

http://eg.2bz.de/Apache-PageKit-2.14_06.tar.gz

Thanks for your great testcase!

Am Samstag, 1. Mai 2004 12:28 schrieb subs:
> > 2. Something really weird is going on with XSL param caching - the
> > order in which components appear on the page seems to determine
> > whether or not params are correctly cached. I can't figure
> > out exactly
> > why this is happening.
>
> OK I've figured out what's happening. Every time PageKit parses a
> page/component, $Apache::PageKit::Content::PAGE_ID_XSL_PARAMS is
> re-initialized which nukes the previous component's params. I'll submit a
> patch once I've had a chance to test it fully.
>
> ben
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Pagekit-devel mailing list
> Pag...@li...
> https://lists.sourceforge.net/lists/listinfo/pagekit-devel

-- 
Boris

RE: [Pagekit-devel] XSL params issue with 2-14_03

[subs <su...@sn...>]

> 2. Something really weird is going on with XSL param caching - the 
> order in which components appear on the page seems to determine 
> whether or not params are correctly cached. I can't figure 
> out exactly 
> why this is happening.

OK I've figured out what's happening. Every time PageKit parses a
page/component, $Apache::PageKit::Content::PAGE_ID_XSL_PARAMS is
re-initialized which nukes the previous component's params. I'll submit a
patch once I've had a chance to test it fully.

ben

[Pagekit-devel] XSL params issue with 2-14_03

[<su...@sn...>]

Hi,

Apache-PageKit-2.14_03
mod_perl-1.99_13
libapreq2-2.02-dev

I'm having a couple of issues with XSL params:

1. PageKit is trying to locate xsl:param elements in the component XML 
file, rather than the associated XSL file. This change seems to have 
happened recently in Apache::PageKit::Content.pm when the XML::LibXML 
call was moved out of the open_uri callback. 

2. Something really weird is going on with XSL param caching - the 
order in which components appear on the page seems to determine 
whether or not params are correctly cached. I can't figure out exactly 
why this is happening.

A patch for #1 and a testcase for #2 are attached.

cheers,
ben

[Pagekit-devel] 1.13 CVS is broken.

[Rob S. <fa...@ra...>]

A freshly checked out version of 1.13 from CVS does not patch PageKit.pm
correctly.

Attached is a minor patch to Makefile.PL.

Tested with perl 5.8.4 on Fedora Core 1

Rob

---
diff -Nur --exclude=CVS Apache-PageKit-1.13-cvs/Makefile.PL
Apache-PageKit-1.13-cvs-04292004/Makefile.PL
--- Apache-PageKit-1.13-cvs/Makefile.PL 2004-04-06 05:16:46.000000000 -0700
+++ Apache-PageKit-1.13-cvs-04292004/Makefile.PL        2004-04-29
02:13:51.819437051 -0700
@@ -268,7 +268,7 @@

      # correct the header
 -    $apr->content_type("text/html; charset=$retcharset") if ($retcharset);
--    $apr->content_type("text/html")                      unless
($retcharset);
+-    $apr->content_type("text/html; charset=$default_output_charset")
unless ($retcharset);
 +    if ($retcharset) {
 +      $apr->content_type("text/html; charset=$retcharset");
 +    }

[Pagekit-devel] Apache-PageKit-2.14_05 mod_perl 2 only

[Boris Z. <bz...@2b...>]

Hi,

If you run already PageKit-2.14_03 there is no need to update.

http://eg.2bz.de/Apache-PageKit-2.14_05.tar.gz

is available now. The changes from Apache-PageKit-2.14_03 are:

- Correct problems regards to make test, if your mod_perl is build with the
	MP_INST_APACHE2=1 option of mod_perl.

For correct cookies, use libapreq2 from CVS. The current version on CPAN 
( libapreq2-2.02_02-dev ) calculates the expire time wrong.

Since the CVS version has build trouble currently, here is a working version.

http://eg.2bz.de/httpd-apreq-2-19042004.tar.gz

To install that use:

wget http://eg.2bz.de/httpd-apreq-2-19042004.tar.gz
tar zxplvf httpd-apreq-2-19042004.tar.gz
cd httpd-apreq-2
./buildconf
perl Makefile.PL --with-apache2-apxs=/path/to/apache2/bin/apxs
make
make test
make install
-- 
Boris

Re: [Pagekit-devel] Apache-PageKit-2.14_03 mod_perl 2 only

[<su...@sn...>]

> 
> http://eg.2bz.de/Apache-PageKit-2.14_03.tar.gz
> 
> is available now.

Thanks Boris - great work. Also thanks for pointing out the apreq2 
cookie fix!

Ben

[Pagekit-devel] Apache-PageKit-2.14_03 mod_perl 2 only

[Boris Z. <bz...@2b...>]

Hi,

http://eg.2bz.de/Apache-PageKit-2.14_03.tar.gz

is available now. The changes from Apache-PageKit-2.14_01 are:

- Little change for the DBD::SQLite handling.
- mod_perl >= 1.9913 is required now.
- ht_time is used for static files. Former we used format_time. 
	That is no longer part of the mp2 API.
- Apache-PageKit-2 honors Apache2 at startup, so you can install
	Apache-PageKit-1 and Apache-PageKit-2 within the same perl.
	Reported by Henry Kilmer.

For correct cookies, use libapreq2 from CVS. The current version on CPAN 
( libapreq2-2.02_02-dev ) calculates the expire time wrong.

Since the CVS version has build trouble currently, here is a working version.

http://eg.2bz.de/httpd-apreq-2-19042004.tar.gz

To install that use:

wget http://eg.2bz.de/httpd-apreq-2-19042004.tar.gz
tar zxplvf httpd-apreq-2-19042004.tar.gz
cd httpd-apreq-2
./buildconf
perl Makefile.PL --with-apache2-apxs=/path/to/apache2/bin/apxs
make
make test
make install

-- 
Boris

[Pagekit-devel] Apache-PageKit-2.14_01.tar.gz - mod_perl 2 only

[Boris Z. <bz...@2b...>]

Hi,

here is a new test version of Apache-PageKit for mod_perl 2.

http://eg.2bz.de/Apache-PageKit-2.14_01.tar.gz

1.14
	- the eg site use DBD::SQLite now. This obsoletes
		DBD::CSV, SQL::Statement and Text::CSV_XS.
		( Boris Zentner )
	- fop_command can be disabled with fop_command =3D ""
		( Boris Zentner, Shimon Rura )
	- Remove Apache->request calls from Apache::PageKit::Edit
		just to make apache 2 changes smaller ( Boris Zentner )
	- Fix: Parse Accept-Charsets more pettier ( Boris Zentner )
	! If the client browser has no accept charset header or no good one,
		deliver in the default_output_charset and set the charset
		in the content_type header. ( Erik G=FCnther )
	- Fix uri_prefix in conjunction with can_edit
		( Boris Zentner, Erik G=FCnther )=20


--=20
Boris

Re: [Pagekit-devel] re-licence PageKit?

[Boris Z. <bz...@2b...>]

Hi Mike,

Am Dienstag, 6. April 2004 18:37 schrieb mi...@in...:
> I've recently started a new job and want to make use of PageKit in our
> environment, but they only allow use of certain open source licences.
> Apparently PageKit has a custom licence from AnIdea, and at first glance
> it APPEARS that we could use it (seems GPL-like).
>

PageKit is released under the RICOH SOURCE CODE PUBLIC LICENSE. Which is very 
liberal to anybody. Much more liberal than the GPL. It is also OSI Approved.

http://opensource.org/
http://opensource.org/licenses/ricohpl.html
http://www.risource.org/RPL

Basicly it say's do whatever you want with it. Im not responsible for 
anything. Commercial or not. royalty-free.

In contrast to the GPL where you must give back or provide your modifications 
RICOH SOURCE CODE PUBLIC LICENSE does not force you to do so. You can, but 
there is no need to do. 

> I'm wondering if re-licencing PageKit under the Perl Artistic licence or
> maybe the GPL is possible to avoid any legal hassles and future
> reservations about adopting PageKit by other companies?
>

I can not belive that it is a issue for a company, since they do normaly avoid 
to change PageKit, they develop a application that is driven by Pagekit.   
AnIdea have no rights on that ( your ) application even if it does not work 
without PageKit. Beside that, the license allow you to modify PageKit itself 
in any way you like it.

Im not against re-licencing, but I need _very_ strong arguments why RICOH 
SOURCE CODE PUBLIC LICENSE is not enough. Since this might be a lot of hassle 
for me to.

>
> --mike

-- 
Boris

[Pagekit-devel] re-licence PageKit?

[<mi...@in...>]

I've recently started a new job and want to make use of PageKit in our
environment, but they only allow use of certain open source licences. 
Apparently PageKit has a custom licence from AnIdea, and at first glance
it APPEARS that we could use it (seems GPL-like).

I'm wondering if re-licencing PageKit under the Perl Artistic licence or
maybe the GPL is possible to avoid any legal hassles and future
reservations about adopting PageKit by other companies?

--mike

[Pagekit-devel] patch: The eg site use DBD::SQLite now.

[Boris Z. <bz...@2b...>]

Hi,

	- the eg site use DBD::SQLite now. This obsoletes
               DBD::CSV, SQL::Statement and Text::CSV_XS.
               ( Boris Zentner )

-- 
Boris