CGI-XMLApplication-1.1.3/ 0040755 0000764 0000764 00000000000 10024356104 013757 5 ustar phish phish CGI-XMLApplication-1.1.3/examples/ 0040755 0000764 0000764 00000000000 10024356067 015605 5 ustar phish phish CGI-XMLApplication-1.1.3/examples/example4.pl 0100644 0000764 0000764 00000000661 07416724441 017667 0 ustar phish phish #!/usr/bin/perl
# (c) 2001 ph15h
# example4.pl
#
# show how to pass script configurations
#
use lib qw( ../../ );
{
# well i leave it up to your phantasy what to do here :)
my %config = ( -DUMMY=>"the dummy" );
require "example4.pm";
my $script_class = new example4;
# we could do some tricks with CGI.pm functions before run ...
# and pass our prepared information to run().
$script_class->run( \%config );
}
CGI-XMLApplication-1.1.3/examples/example2.pl 0100644 0000764 0000764 00000000663 07416724441 017667 0 ustar phish phish #!/usr/bin/perl
# (c) 2001 ph15h
# example2.pl
use lib qw( ../../ );
{
# this script will figure by its calling name, which module to load
my ( $package ) = ( $0 =~ /\/?(\w+)\.pl/i );
require "$package.pm";
# some times there are already information available at this level.
my %ctxt = (-test=>1);
my $script_class = new $package;
$script_class->setStylesheetPath( "your/path" );
$script_class->run(\%ctxt);
}
CGI-XMLApplication-1.1.3/examples/example1.pl 0100755 0000764 0000764 00000001270 07327000735 017656 0 ustar phish phish #!/usr/bin/perl
# (c) 2001 ph15h (GPL)
# This is an example for a cgi script. such a script should not look
# different than this. If you put all functionality into the
# application class this script stays clean and causes no problems
# while debugging at all.
#
# the global structure of the script is extremly easy:
# 1. load your application class.
# 2. create an instance of your class with new
# 3. call the function.
#
# if it is to hard for you to type all the code by your self,
# feel free to rename this script and modify it as needed.
use lib qw( ../blib/lib );
use example1;
my $script_class = new example1;
run $script_class;
# or do it this way:
# $script_class->run();
CGI-XMLApplication-1.1.3/examples/example2.pm 0100644 0000764 0000764 00000012441 07375312245 017664 0 ustar phish phish # this is the application class
#
# this example shows how to make use of the context
# and how passing your personalized xml dom around.
#
# actually this is allready a full featured example, although it does
# nothing useful :>
#
# while programming with this package you should avoid printing to the
# clientside, because this is the job of the serialization function.
# for q'n'd scripter this will be the biggest change of
# paradigma. from the viewpoint of XML/ XSLT this follows exactly the
# paradigma of separating function, content and presentation.
#
# once you get used not using the print function from inside a script,
# you will realize the resulting code will be much easier to maintain.
package example2;
use vars qw( @ISA @HANLDER );
use CGI::XMLApplication;
use XML::LibXML;
@ISA = qw(CGI::XMLApplication);
# if you implement internal error events ashure, you place them at the
# very end of the eventlist, so if someone places a parameter with the
# same name into a form, the script can still find the correct event
# (which is usually the submit button a client pushed).
#
# what are internal events good for? i found it's comfortable to have
# special events, for special problems. this could be that a database
# server is not reachable or a client session has expiered. These are
# no real events, clients cause by clicking around, but in my logic,
# this should be handled in special events. So i delete all existing
# events (done implicit by sendEvent) and send the error event by
# myself.
sub registerEvents { qw( submit _internal_error_ ); } # the handler list
# the requestDOM function is called by the serialize function. it has
# to return a XML::LibXML::Document object. If no DOM is
# returned,sreialize will create an empty DOM, so stylesheets can be
# processed, even if the script does not create a DOM structure
#
# pay attention that you can use any name to store your own DOM
# in the context hash.
sub requestDOM { my ( undef, $ctxt ) = @_; return $ctxt->{-XML}; }
# one can implement any complexity of stylesheet selection wanted, but
# i recommend to keep this function as simple as possible.
sub selectStylesheet {
my ( $self, $ctxt ) = @_;
return $self->getStylesheetPath() . qw( ex2_form.xsl ex2_finish.xsl )[ $ctxt->{-stylesheet} ];
}
# the following subroutine will make CGI::XMLApplication to pass the returned
# hash to the stylesheetprocessor
sub getXSLTParameter {
my ( $self, $ctxt ) = @_;
return ( test=>$ctxt->{-test}||-1 );
}
# the init event should do all required initializing, that is common
# to all events implemeted, as well system problems should be catched
# here as well
sub event_init {
my ( $self , $ctxt ) = @_;
# initialize the context
my $dom = XML::LibXML::Document->new();
my $root= $dom->createElement( 'yourfavouritetagname' );
$dom->setDocumentElement( $root );
$ctxt->{-XML} = $dom;
$ctxt->{-ROOT}= $root;
$ctxt->{-stylesheet} = 0; # on default we'll display the form
# do some testing
# in more complex scripts such tests would be confusing here ...
# the use of error handling inside event_init is more for general
# problems.
if ( $self->param('email')=~/\@.*\@/ || $self->param('email')!~/\@..+/ ) {
$self->sendEvent('_internal_error_' );
}
}
# exit is called before serialization
sub event_exit {
my ( $self , $ctxt ) = @_;
# we do some caching here, but you can do whatever you like
# (e.g. release lockfiles)
if ( exists $ctxt->{-XML} && not exists $ctxt->{-ERROR} ){
open CACHEFILE , "> ex2_cache.xml";
print CACHEFILE $ctxt->{-XML}->toString();
close CACHEFILE;
}
}
sub event_default {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message','Hey user from ' .
$self->remote_host() .
" pass your email!" );
# PAY ATTENTION HERE!
# the return value has to be greater or equal 0. If a value
# less than 0 is returned CGI::XMLApplication asumes an so called
# panic. This will have the effect, that no XSLT redering is tried
# and a special error message is returned (see setPanicMsg)
# CGI::XMLApplication knows 4 types of panics:
# -1 "no stylesheet set" (internal error) (no filename given)
# -2 "no stylesheet found" (internal error) (like file not found)
# -3 "no event function for registred event" (internal error) (...)
# -4 "application error" (this one is for you) ;)
#
# if it is a valid value, the value itself has no meaning anymore...
return 0;
}
# as one can see easily, the event functions has to have the same name
# as the event has. the prefix 'event_' is a requirement.
#
# i think, i'll introduce real callbacks quite soon, so one can choose
# any function name prefered and has only to register it to the related
# event.
sub event__internal_error_ {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message',
'this email seems not to be valid');
$ctxt->{-ROOT}->appendTextChild( 'email', "".$self->param( 'email' ) );
$ctxt->{-ERROR} = 1;
return 0;
}
sub event_submit {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message',
"ALL YOUR BASE DOES BELONG TO US!"); # ;)
$ctxt->{-stylesheet} = 1; # submit was ok, so display the thank you message
return 0;
}
1;
CGI-XMLApplication-1.1.3/examples/example1.pm 0100644 0000764 0000764 00000004215 07375312245 017663 0 ustar phish phish # this is the applcation class
# this example is an example for a CGI prototype. stylesheetnames and
# all events are allready defined, but not fully implemented. This is
# done to demonstrate, the internal error handling, if the requested
# data cannot be found.
# the class only defines only the default event function. this is ok,
# if no functionality on startup or exit is required.
package example1;
use vars qw( @ISA @HANLDER );
use CGI::XMLApplication;
@ISA = qw(CGI::XMLApplication);
# we define two handler here but below there is only a single explicit
# handler implemented. if you call the coma event the script will tell
# the event is not yet defined.
#
# if you have several application layer, that all define some events,
# you should write the function like this:
# sub registerEvents { ( $_[0]->SUPER::registerEvents(), @eventlist ); }
# to ashure, no events get lost during initialization.
sub registerEvents { qw(submit coma); } # the handler list
# a rather simple example :)
# this function is called by the serialization function. As shown this
# function should return the full path and filename. otherwise the
# script will check, if the stylesheets are in the local directory.
sub selectStylesheet {
my ( $self , $ctxt ) = @_;
my $path_to_style = 'your/path/';
return $path_to_style . qw( bsp1.xsl bsp2.xsl )[$ctxt{-stylesheetid}];
}
# notice, that we do not implement getDOM!
# this will cause CGI::XMLApplication to create an empty document
# so the transformation will be done anyway
# implicit handler
# no init and exit needed here :)
# This event is called, if no other event can be found in the
# parameter list.
sub event_default {
my $self = shift;
my $ctxt = shift;
warn "test->default\n";
$ctxt->{-stylesheetid} = 1;
return 0;
}
# explicit handler
# this handler is called if the param list contains 'submit=abc' or
# 'submit.x=123'. The script does not check the value of the event, at the
# current state. commonly this is not neccesary anyway since designers
# decide to change values all the time :)
sub event_submit {
my $self = shift;
warn "test->submit\n";
$ctxt->{-stylesheetid} = 2;
return 0;
}
1;
CGI-XMLApplication-1.1.3/examples/example3.pl 0100644 0000764 0000764 00000000740 07416724441 017664 0 ustar phish phish #!/usr/bin/perl
# (c) 2001 ph15h
# example3.pl
#
# show how to pass script configurations
#
use lib qw( ../../ );
{
# well i leave it up to your phantasy what to do here :)
my %config = ( -DUMMY=>"the dummy" );
my ( $package ) = ( $0 =~ /\/?(\w+)\.pl/i );
require "$package.pm";
my $script_class = new $package;
# we could do some tricks with CGI.pm functions before run ...
# and pass our prepared information to run().
$script_class->run( \%config );
}
CGI-XMLApplication-1.1.3/examples/minimalapp.pm 0100644 0000764 0000764 00000001050 07405240515 020262 0 ustar phish phish package minimalapp;
# This application is one of the most simple CGI::XMLApplications one
# can write. It simply defines a stylesheet and passes the variable
# "version" to the stylesheetprocessor.
#
# Since this application makes no use of any events, there are none
# registred. Even the default event is ommited because it does nothing.
use CGI::XMLApplication;
@minimalapp::ISA = qw( CGI::XMLApplication );
sub getStylesheet {
return "minimal.xsl";
}
sub getXSLParameter {
return ( version => $CGI::XMLApplication::VERSION );
}
1;
CGI-XMLApplication-1.1.3/examples/ex2_form.xsl 0100644 0000764 0000764 00000001115 07327000735 020051 0 ustar phish phish
example 2 form
CGI-XMLApplication-1.1.3/examples/example4.pm 0100644 0000764 0000764 00000003015 07375312245 017663 0 ustar phish phish # this is the application class
# this example shows how to skip the build in xml/xslt serialization
package example4;
use vars qw( @ISA @HANLDER );
use CGI::XMLApplication;
use XML::LibXML;
@ISA = qw(CGI::XMLApplication);
sub registerEvents { qw( submit ); } # the handler list
sub selectStylesheet {
return './' . ex2_form.xsl;
}
sub event_init {
my ( $self , $ctxt ) = @_;
# initialize the internal context
my $dom = XML::LibXML::Document->new();
my $root= $dom->createElement( 'yourfavouritetagname' );
$dom->setDocumentElement( $root );
$ctxt->{-XML} = $dom;
$ctxt->{-ROOT}= $root;
$ctxt->{-stylesheet} = 0; # on default we'll display the form
if ( $self->param('email')=~/\@.*\@/ || $self->param('email')!~/\@..+/ ) {
$self->sendEvent('_internal_error_' );
}
}
sub event_default {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message','Hey user from ' .
$self->remote_host() .
" pass your email!" );
return 0;
}
sub event_submit {
my ( $self , $ctxt ) = @_;
# assume we have an file uploaded by the user and simply want to return
# it back to the client
my $file = $self->param("thefile");
my $type = $self->uploadInfo($file)->{'Content-Type'};
print $self->header( -type=>$type );
while ( <$file> ) { print; }
# in such a case we already handled the request so CGI::XMLApplication
# should not try any serialization
$self->skipSerialization(1);
return 0;
}
1;
CGI-XMLApplication-1.1.3/examples/minimal.xsl 0100644 0000764 0000764 00000001157 07405240515 017763 0 ustar phish phish
evaluate! userlisting
CGI::XMLApplication
The Version of CGI::XMLApplication is
CGI-XMLApplication-1.1.3/examples/example3.pm 0100644 0000764 0000764 00000005267 07327000735 017670 0 ustar phish phish # this is the application class # This example shows how to pass a
# configuration to CGI::XMLApplication. In fact the data passed to
# CGI::XMLApplication can be of any type you like. The data is simply
# inserted to the context (see CGI::XMLApplication for
# details). Basicly this module has the same function as example2, so
# I asume you have through that module already.
package example3;
use vars qw( @ISA @HANLDER );
use CGI::XMLApplication;
use XML::LibXML;
@ISA = qw(CGI::XMLApplication);
sub registerEvents { qw( submit _internal_error_ ); } # the handler list
sub requestDOM { my ( undef, $ctxt ) = @_; return $ctxt->{-XML}; }
sub selectStylesheet {
my ( undef, $ctxt ) = @_;
return './' . qw( ex2_form.xsl ex2_finish.xsl )[ $ctxt->{-stylesheet} ];
}
sub event_init {
my ( $self , $ctxt ) = @_;
# lets see if our configuration is here :)
if ( exists $ctxt->{-DUMMY} ){
# not very useful, huh? =)
# the thing here is, that the data passed to run() in the script,
# is available in ALL events. this may be useful, if one has to
# load script configurations on runtime
warn "example3 found the dummy!\n";
}
# initialize the internal context
my $dom = XML::LibXML::Document->new();
my $root= $dom->createElement( 'yourfavouritetagname' );
$dom->setDocumentElement( $root );
$ctxt->{-XML} = $dom;
$ctxt->{-ROOT}= $root;
$ctxt->{-stylesheet} = 0; # on default we'll display the form
if ( $self->param('email')=~/\@.*\@/ || $self->param('email')!~/\@..+/ ) {
$self->sendEvent('_internal_error_' );
}
}
# exit is called before serialization
sub event_exit {
my ( $self , $ctxt ) = @_;
# we do some caching here, but you can do whatever you like
# (e.g. release lockfiles)
if ( exists $ctxt->{-XML} && not exists $ctxt->{-ERROR} ){
open CACHEFILE , "> ex2_cache.xml";
print CACHEFILE $ctxt->{-XML}->toString();
close CACHEFILE;
}
}
sub event_default {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message','Hey user from ' .
$self->remote_host() .
" pass your email!" );
return 0;
}
sub event__internal_error_ {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message',
'this email seems not to be valid');
$ctxt->{-ROOT}->appendTextChild( 'email', "".$self->param( 'email' ) );
$ctxt->{-ERROR} = 1;
return 0;
}
sub event_submit {
my ( $self , $ctxt ) = @_;
$ctxt->{-ROOT}->appendTextChild('message',
"ALL YOUR BASE DOES BELONG TO US!"); # ;)
$ctxt->{-stylesheet} = 1; # submit was ok, so display the thank you message
return 0;
}
1;
CGI-XMLApplication-1.1.3/examples/minimal.pl 0100755 0000764 0000764 00000000120 07405240515 017560 0 ustar phish phish #! /usr/bin/perl -w
use minimalapp;
my $app = minimalapp->new();
$app->run();
CGI-XMLApplication-1.1.3/examples/ex2_finish.xsl 0100644 0000764 0000764 00000000575 07327000735 020377 0 ustar phish phish
example 2 finish
CGI-XMLApplication-1.1.3/Changes 0100644 0000764 0000764 00000003317 10024355637 015265 0 ustar phish phish Revision history for Perl extension CGI::XMLApplication
1.1.3
o check for multivalued parameters stored in a \0 separated string by CGI::Vars (Michael Kröll)
1.1.2
+ changed run() to accept a hash reference or an object in
addition to a plain hash as context (Michael Kröll)
o redirection handling fix
o documentation fixes (thanks to Christian Kauhaus)
1.1.1
+ documentation fixes and updates :)
o tiny tiny patch related to "perl -w"
o made run() more flexible
1.1.0
tiny interface changes in this
getStylesheet() obsoletes selectStylesheet()
+ getStylesheetString() so xsl strings can be passed as well
+ panic() sends now the error state
+ $CGI::XMLApplication::Quiet controls the errormessages returned
to the client
+ event_default returns now 0 instead of an panic on default
+ added the minimal example
o documentation bugs fixed
o default functions return now default values (empty hashes or strings)
instead of undef
o no warnings send with perl -w (as far as i tested)
1.0.2
THIS VERSION FIXES TWO MAJOR BUGS INTRODUCED WITH 1.0.0
+ getEvent Bug FIXED
+ $stylesheet Bug FIXED
1.0.1
+ passthru() function
+ some documentation
1.0.0
+ cleaned the structure
+ uses strict
+ better code to handle binary response data
- old (compatibility) code
0.8.1 Sat Jul 21 14:43 2001
Renamed the Package from CGI::OO to CGI::XMLApplication, since that
name makes more clear what it does :)
As well I enabled the run function, to get a context hash as a
parameter.
0.8 Thu Jul 5 11:31:26 2001
Made the Package work with MakeMaker after using it as a private
Module for some Months
CGI-XMLApplication-1.1.3/MANIFEST 0100644 0000764 0000764 00000000541 07557746612 015135 0 ustar phish phish XMLApplication.pm
Changes
MANIFEST
Makefile.PL
README
test.pl
t/01basic.t
examples/example1.pm
examples/example1.pl
examples/example2.pm
examples/example2.pl
examples/example3.pm
examples/example3.pl
examples/ex2_form.xsl
examples/ex2_finish.xsl
examples/example4.pm
examples/example4.pl
examples/minimal.pl
examples/minimalapp.pm
examples/minimal.xsl
CGI-XMLApplication-1.1.3/t/ 0040755 0000764 0000764 00000000000 10024356067 014232 5 ustar phish phish CGI-XMLApplication-1.1.3/t/01basic.t 0100644 0000764 0000764 00000000235 07375321070 015637 0 ustar phish phish use Test;
BEGIN { plan tests => 2 }
END { ok(0) unless $loaded }
use CGI::XMLApplication;
$loaded = 1;
ok(1);
my $p = CGI::XMLApplication->new('');
ok($p);
CGI-XMLApplication-1.1.3/test.pl 0100644 0000764 0000764 00000000017 07327000735 015276 0 ustar phish phish print "ok\n";
CGI-XMLApplication-1.1.3/XMLApplication.pm 0100644 0000764 0000764 00000123102 10024355637 017147 0 ustar phish phish # $Id: XMLApplication.pm,v 1.19 2004/03/10 17:55:00 c102mk Exp $
package CGI::XMLApplication;
# ################################################################
# $Revision: 1.19 $
# $Author: c102mk $
#
# (c) 2001 Christian Glahn
# All rights reserved.
#
# This code is free software; you can redistribute it and/or
# modify it under the same terms as Perl itself.
#
# ################################################################
##
# CGI::XMLApplication - Application Module for CGI scripts
# ################################################################
# module loading and global variable initializing
# ################################################################
use strict;
use CGI;
use Carp;
#use Data::Dumper;
# ################################################################
# inheritance
# ################################################################
@CGI::XMLApplication::ISA = qw( CGI );
# ################################################################
$CGI::XMLApplication::VERSION = "1.1.3";
# ################################################################
# general configuration
# ################################################################
# some hardcoded error messages, the application has always, e.g.
# to tell that a stylesheet is missing
@CGI::XMLApplication::panic = (
'No Stylesheet specified! ',
'Stylesheet is not available! ',
'Event not implemented',
'Application Error',
);
# The Debug Level for verbose error messages
$CGI::XMLApplication::DEBUG = 0;
# ################################################################
# methods
# ################################################################
sub new {
my $class = shift;
my $self = $class->SUPER::new( @_ );
bless $self, $class;
$self->{XML_CGIAPP_HANDLER_} = [$self->registerEvents()];
$self->{XML_CGIAPP_STYLESHEET_} = [];
$self->{XML_CGIAPP_STYLESDIR_} = '';
return $self;
}
# ################################################################
# straight forward coded methods
# application related ############################################
# both functions are only for backward compatibilty with older scripts
sub debug_msg {
my $level = shift;
if ( $level <= $CGI::XMLApplication::DEBUG && scalar @_ ) {
my ($module, undef, $line) = caller(1);
warn "[$module; line: $line] ", join(' ', @_) , "\n";
}
}
##
# dummy functions
#
# each function is required to be overwritten by any class inheritated
sub registerEvents { return (); }
# all following function will recieve the context, too
sub getDOM { return undef; }
sub requestDOM { return undef; } # old style use getDOM!
sub getStylesheetString { return ""; } # return a XSL String
sub getStylesheet { return ""; } # returns either name of a stylesheetfile or the xsl DOM
sub selectStylesheet { return ""; } # old style getStylesheet
sub getXSLParameter { return (); } # should return a plain hash of parameters passed to xsl
sub setHttpHeader { return (); } # should return a hash of header
sub skipSerialization{
my $self = shift;
$self->{CGI_XMLAPP_SKIP_TRANSFORM} = shift if scalar @_;
return $self->{CGI_XMLAPP_SKIP_TRANSFORM};
}
# returns boolean
sub passthru {
my $self = shift;
if ( scalar @_ ) {
$self->{CGI_XMLAPP_PASSXML} = shift;
$self->delete( 'passthru' ); # delete any passthru parameter
}
elsif ( defined $self->param( "passthru" ) ) {
$self->{CGI_XMLAPP_PASSXML} = 1 ;
$self->delete( 'passthru' );
}
return $self->{CGI_XMLAPP_PASSXML};
}
sub redirectToURI {
my $self = shift;
$self->{CGI_XMLAPP_REDIRECT} = shift if scalar @_;
return $self->{CGI_XMLAPP_REDIRECT};
}
# ################################################################
# content related functions
# stylesheet directory information ###############################
sub setStylesheetDir { $_[0]->{XML_CGIAPP_STYLESDIR_} = $_[1];}
sub setStylesheetPath { $_[0]->{XML_CGIAPP_STYLESDIR_} = $_[1];}
sub getStylesheetDir { $_[0]->{XML_CGIAPP_STYLESDIR_}; }
sub getStylesheetPath { $_[0]->{XML_CGIAPP_STYLESDIR_}; }
# event control ###################################################
sub addEvent { my $s=shift; push @{$s->{XML_CGIAPP_HANDLER_}}, @_;}
sub getEventList { @{ $_[0]->{XML_CGIAPP_HANDLER_} }; }
sub testEvent { return $_[0]->checkPush( $_[0]->getEventList() ); }
sub deleteEvent {
my $self = shift;
if ( scalar @_ ){ # delete explicit events
foreach ( @_ ) {
debug_msg( 8, "[XML::CGIApplication] delete event $_" );
$self->delete( $_ );
$self->delete( $_.'.x' );
$self->delete( $_.'.y' );
}
}
else { # delete all
foreach ( @{ $self->{XML_CGIAPP_HANDLER_} } ){
debug_msg( 8, "delete event $_" );
$self->delete( $_ );
$self->delete( $_.'.x' );
$self->delete( $_.'.y' );
}
}
}
sub sendEvent {
debug_msg( 10, "send event " . $_[1] );
$_[0]->deleteEvent();
$_[0]->param( -name=>$_[1] , -value=>1 );
}
# error handling #################################################
# for internal use only ...
sub setPanicMsg { $_[0]->{XML_CGIAPP_PANIC_} = $_[1] }
sub getPanicMsg { $_[0]->{XML_CGIAPP_PANIC_} }
# ################################################################
# predefined events
# default event handler prototypes
sub event_init {}
sub event_exit {}
sub event_default { return 0 }
# ################################################################
# CGI specific helper functions
# this is required by the eventhandling
sub checkPush {
my $self = shift;
my ( $pushed ) = grep {
defined $self->param( $_ ) || defined $self->param( $_.'.x')
} @_;
$pushed =~ s/\.x$//i if defined $pushed;
return $pushed;
}
# helper functions which were missing in CGI.pm
sub checkFields{
my $self = shift;
my @missing = grep {
not length $self->param( $_ ) || $self->param( $_ ) =~ /^\s*$/
} @_;
return wantarray ? @missing : ( scalar(@missing) > 0 ? undef : 1 );
}
sub getParamHash {
my $self = shift;
my $ptrHash = $self->Vars;
my $ptrRV = {};
foreach my $k ( keys( %{$ptrHash} ) ){
next unless exists $ptrHash->{$_} && $ptrHash->{$_} !~ /^[\s\0]*$/;
$ptrRV->{$k} = $ptrHash->{$k};
}
return wantarray ? %{$ptrRV} : $ptrRV;
}
# ################################################################
# application related methods
# ################################################################
# algorithm should be
# event registration
# app init
# event handling
# app exit
# serialization and output
# error handling
sub run {
my $self = shift;
my $sid = -1;
my $ctxt = (!@_ or scalar(@_) > 1) ? {@_} : shift; # nothing, hash or context object
$self->event_init($ctxt);
if ( my $n = $self->testEvent($ctxt) ) {
if ( my $func = $self->can('event_'.$n) ) {
$sid = $self->$func($ctxt);
}
else {
$sid = -3;
}
}
if ( $sid == -1 ){
$sid = $self->event_default($ctxt);
}
$self->event_exit($ctxt);
# if we allready panic, don't try to render
if ( $sid >= 0 ) {
# check if we wanna redirect
if ( my $uri = $self->redirectToURI() ) {
my %h = $self->setHttpHeader( $ctxt );
$h{-uri} = $uri;
print $self->SUPER::redirect( %h ) . "\n\n";
}
elsif ( not $self->skipSerialization() ) {
# sometimes it is nessecary to skip the serialization
# eg. due passing binary data.
$sid = $self->serialization( $ctxt );
}
}
$self->panic( $sid, $ctxt );
}
sub serialization {
# i require both modules here, so one can implement his own
# serialization
require XML::LibXML;
require XML::LibXSLT;
my $self = shift;
my $ctxt = shift;
my $id;
my %header = $self->setHttpHeader( $ctxt );
my $xml_doc = $self->getDOM( $ctxt );
if ( not defined $xml_doc ) {
debug_msg( 10, "use old style interface");
$xml_doc = $self->requestDOM( $ctxt );
}
# if still no document is available
if ( not defined $xml_doc ) {
debug_msg( 10, "no DOM defined; use empty DOM" );
$xml_doc = XML::LibXML::Document->new;
# the following line is to keep xpath.c quiet!
$xml_doc->setDocumentElement( $xml_doc->createElement( "dummy" ) );
}
if( defined $self->passthru() && $self->passthru() == 1 ) {
# this is a useful feature for DOM debugging
debug_msg( 10, "attempt to pass the DOM to the client" );
$header{-type} = 'text/xml';
print $self->header( %header );
print $xml_doc->toString();
return 0;
}
my $stylesheet = $self->getStylesheet( $ctxt );
my ( $xsl_dom, $style, $res );
my $parser = XML::LibXML->new();
my $xslt = XML::LibXSLT->new();
if ( ref( $stylesheet ) ) {
debug_msg( 5, "stylesheet is reference" );
$xsl_dom = $stylesheet;
}
elsif ( -f $stylesheet && -r $stylesheet ) {
debug_msg( 5, "filename is $stylesheet" );
eval {
$xsl_dom = $parser->parse_file( $stylesheet );
};
if ( $@ ) {
debug_msg( 3, "Corrupted Stylesheet:\n broken XML\n". $@ );
$self->setPanicMsg( "Corrupted document:\n broken XML\n". $@ );
return -2;
}
}
else {
# first test the new style interface
my $xslstring = $self->getStylesheetString( $ctxt );
if ( length $xslstring ) {
debug_msg( 5, "stylesheet is xml string" );
eval { $xsl_dom = $parser->parse_string( $xslstring ); };
if ( $@ || not defined $xsl_dom ) {
# the parse failed !!!
debug_msg( 3, "Corrupted Stylesheet String:\n". $@ ."\n" );
$self->setPanicMsg( "Corrupted Stylesheet String:\n". $@ );
return -2;
}
}
else {
# now test old style interface
# will be removed with the next major release
debug_msg( 5, "old style interface to select the stylesheet" );
$stylesheet = $self->selectStylesheet( $ctxt );
if ( ref( $stylesheet ) ) {
debug_msg( 5, "stylesheet is reference" );
$xsl_dom = $stylesheet;
}
elsif ( -f $stylesheet && -r $stylesheet ) {
debug_msg( 5, "filename is $stylesheet" );
eval {
$xsl_dom = $parser->parse_file( $stylesheet );
};
if ( $@ ) {
debug_msg( 3, "Corrupted Stylesheet:\n broken XML\n". $@ );
$self->setPanicMsg( "Corrupted document:\n broken XML\n". $@ );
return -2;
}
}
else {
debug_msg( 2 , "panic stylesheet file $stylesheet does not exist" );
$self->setPanicMsg( "$stylesheet" );
return length $stylesheet ? -2 : -1 ;
}
}
}
eval {
$style = $xslt->parse_stylesheet( $xsl_dom );
# $style = $xslt->parse_stylesheet_file( $file );
};
if( $@ ) {
debug_msg( 3, "Corrupted Stylesheet:\n". $@ ."\n" );
$self->setPanicMsg( "Corrupted Stylesheet:\n". $@ );
return -2;
}
my %xslparam = $self->getXSLParameter( $ctxt );
eval {
# first do special xpath encoding of the parameter
if ( %xslparam && scalar( keys %xslparam ) > 0 ) {
my @list;
foreach my $key ( keys %xslparam ) {
# check for multivalued parameters stored in a \0 separated string by CGI.pm :-/
if ( $xslparam{$key} =~ /\0/ ) {
push @list, $key, (split("\0",$xslparam{$key}))[-1];
}
else {
push @list, $key, $xslparam{$key};
}
}
$res = $style->transform( $xml_doc,
XML::LibXSLT::xpath_to_string(@list)
);
}
else {
$res = $style->transform( $xml_doc );
}
};
if( $@ ) {
debug_msg( 3, "Broken Transformation:\n". $@ ."\n" );
$self->setPanicMsg( "Broken Transformation:\n". $@ );
return -2;
}
# override content-type with the correct content-type
# of the style (is this ok?)
$header{-type} = $style->media_type;
$header{-charset} = $style->output_encoding;
debug_msg( 10, "serialization do output" );
# we want nice xhtml and since the output_string does not the
# right job
my $out_string= undef;
debug_msg( 9, "serialization get output string" );
eval {
$out_string = $style->output_string( $res );
};
debug_msg( 10, "serialization rendered output" );
if ( $@ ) {
debug_msg( 3, "Corrupted Output:\n", $@ , "\n" );
$self->setPanicMsg( "Corrupted Output:\n". $@ );
return -2;
}
else {
# do the output
print $self->header( %header );
print $out_string;
debug_msg( 10, "output printed" );
}
return 0;
}
sub panic {
my ( $self, $pid ) = @_;
return unless $pid < 0;
$pid++;
$pid*=-1;
my $str = "Application Panic: ";
$str = "PANIC $pid :" . $CGI::XMLApplication::panic[$pid] ;
# this is nice for debugging from logfiles...
$str = $self->b( $str ) . " \n";
$str .= $self->pre( $self->getPanicMsg() );
$str .= "Please Contact the Systemadminstrator \n";
debug_msg( 1, "$str" );
if ( $CGI::XMLApplication::Quiet == 1 ) {
$str = "Application Panic";
}
if ( $CGI::XMLApplication::Quiet == 2 ) {
$str = "";
}
my $status = $pid < 3 ? 404 : 500; # default is the application error ...
print $self->header( -status => $status ) , $str ,"\n";
}
1;
# ################################################################
__END__
=head1 NAME
CGI::XMLApplication -- Object Oriented Interface for CGI Script Applications
=head1 SYNOPSIS
use CGI::XMLApplication;
$script = new CGI::XMLApplication;
$script->setStylesheetPath( "the/path/to/the/stylesheets" );
# either this for simple scripts
$script->run();
# or if you need more control ...
$script->run(%context_hash); # or a context object
=head1 DESCRIPTION
CGI::XMLApplication is a CGI application class, that intends to enable
perl artists to implement CGIs that make use of XML/XSLT
functionality, without taking too much care about specialized
errorchecking or even care too much about XML itself. It provides the
power of the L/ L module package for
content deliverment.
As well CGI::XMLApplication is designed to support project management
on code level. The class allows to split web applications into several
simple parts. Through this most of the code stays simple and easy to
maintain. Throughout the whole runtime of a script
CGI::XMLApplication tries to keep the application stable. As well a
programmer has not to bother about some of XML::LibXML/ XML::LibXSLT
transformation pitfalls.
The class module extends the CGI class. While all functionality of the
original CGI package is still available, it should be not such a big
problem, to port existing scripts to CGI::XMLApplication, although
most functions used here are the access function for client data
such as I.
CGI::XMLApplication, intended to be an application class should make
writing of XML enabled CGI scripts more easy. Especially because of
the use of object orientated concepts, this class enables much more
transparent implemententations with complex functionality compared to
what is possible with standard CGI-scripts.
The main difference with common perl CGI implementation is the fact,
that the client-output is not done from perl functions, but generated
by an internally build XML DOM that gets processed with an XSLT
stylesheet. This fact helps to remove a lot of the HTML related
functions from the core code, so a script may be much easier to read,
since only application relevant code is visible, while layout related
information is left out (commonly in an XSLT file).
This helps to write and test a complete application faster and less
layout related. The design can be appended and customized later
without effecting the application code anymore.
Since the class uses the OO paradigma, it does not force anybody to
implement a real life application with the complete overhead of more
or less redundant code. Since most CGI-scripts are waiting for
B, which is usually the code abstraction of a click of a
submit button or an image, CGI::XMLApplication implements a simple
event system, that allows to keep event related code as separated as
possible.
Therefore final application class is not ment to have a constructor
anymore. All functionality should be encapsulated into implicit or
explicit event handlers. Because of a lack in Perl's OO implementation
the call of a superclass constructor before the current constructor
call is not default behavior in Perl. For that reason I decided to
have special B to enable the application to initialize
correctly, excluding the danger of leaving important variables
undefined. Also this forces the programmer to implement
scripts more problem orientated, rather than class or content focused.
Another design aspect for CGI::XMLApplication is the strict
differentiation between CODE and PRESENTATION. IMHO this, in fact
being one of the major problems in traditional CGI programming. To
implement this, the XML::LibXML and XML::LibXSLT modules are used by
default but may be replaced easily by any other XML/XSLT capable
modules. Each CGI Script should generate an XML-DOM, that can be
processed with a given stylesheet.
B
=head2 Programflow of a CGI::XMLApplication
The following Flowchart illustratrates how CGI::XMLApplication behaves
during runtime. Also chart shows where specialized application code gets
control during script runtime.
------- CGI Script ------->|<--------- CGI::XMLApplication --------
.---------------------. .--------------------.
| app-class creation |--- | event registration |
`---------------------' | registerEvents() |
`--------------------'
.------------------------. |
| context initialization |------------'
| ( optional ) |
`------------------------'
|
.-----------------------. .------------------------.
| run() function called |--| application initialize |
`-----------------------' | event_init() |
`------------------------'
|
.--------'`------------.
/ event parameter found? \_
\ testEvent() / \
`--------.,------------' |
| |
yes | no |
| |
.------------. .------------------.
| call event | | call |
| event_*() | | event_default() |
`------------' `------------------'
| |
.---------------------. |
| application cleanup |-----'
| event_exit() |
`---------------------'
|
.---------'`------------.
_/ avoid XML serialization \
/ \ skip_serialization() /
| `---------.,------------'
| |
yes | no |
| |
| .--------------------------.
| | XML generation, XSLT |
| | serialization and output |
| | serialization() |
| `--------------------------'
.---------------. | |
| END |-------+-------------'
`---------------'
=head2 What are Events and how to catch them
Most CGI Scripts handle the result of HTML-Forms or similar requests
from clients. Analouge to GUI Programming, CGI::XMLApplication calls
this an B. Spoken in CGI/HTML-Form words, a CGI-Script handles
the various situations a clients causes by pushing a submit button or
follows a special link. Because of this common events are thrown by
arguments found in the CGI's query string.
An event of CGI::XMLApplication has the same B as the input
field, that should cause the event. The following example should
illustrate this a little better:
If a user clicks the submitbutton and you have registered the event
name B for your script, CGI::XMLApplication will try to call the
function B. The script module to handle the dummy event
would look something like the following code:
# Application Module
package myApp;
use CGI::XMLApplication;
@ISA = qw(CGI::XMLApplication);
sub registerEvents { qw( dummy ); } # list of event names
# ...
sub event_dummy {
my ( $self, $context ) = @_;
# your event code goes here
return 0;
}
During the lifecircle of a CGI script, often the implementation starts
with ordinary submit buttons, which get often changed to so called
input images, to fit into the UI of the Website. One does not need to
change the code to make the scripts fit to these changes;
CGI::XMLApplication already did it. The code has not to be changed if
the presentation of the form changes. Therefore there is no need to
declare separate events for input images. E.g. an event called evname
makes CGI::XMLApplication tests if evname B evname.x exist in the
querystring.
So a perl artist can implement and test his code without caring if the
design crew have done their job, too ;-)
In many cases an web application is also confronted with events that
can not be represented in with querystring arguments. For these cases
CGI::XMLApplication offers the possibility to send B
from the B function for example in case of application
errors. This is done with the B Function. This will set a
new parameter to the CGI's querystring after removing all other
events. B.
Although a sendEvent function exists, CGI::XMLApplication doesn't
implement an event queqe. For GUI programmers this seems like a
unnessecary restriction. In terms of CGI it makes more sense to think
of a script as a program, that is only able to scan its event queqe
only once during runtime and stopped before the next event can be
thrown. The only chance to stop the script from handling a certain
event is to send a new event or delete this (or even all) events from
inside the event_init() function. This function is always called at
first from the run method. If another event uses the sendEvent
function, the call will have no effect.
=over 4
=item method registerEvents
This method is called by the class constructor - namely
CGI::XMLApplication's B function . Each application should
register the events it likes to handle with this function. It should
return an array of eventnames such as eg. 'remove' or 'store'. This
list is used to find which event a user caused on the client side.
=item method run
Being the main routine this should be the only method called by the
script apart from the constructor. All events are handled inside the
method B. Since this method is extremly simple and transparent
to any kind of display type, there should be no need to override this
function. One can pass a context hash or context object, to pass external
or prefetched information to the application. This context will be
available and acessable in all events and most extra functions.
This function does all event and serialization related work. As well
there is some validation done as well, so catched events, that are not
implemented, will not cause any harm.
=back
=head2 The Event System
A CGI::XMLApplication is split into two main parts: 1) The executable
script called by the webserver and 2) the application module which has
to be loaded, initialized and called by the script.
Commonly applications that make use of CGI::XMLApplication, will not
bother about the B function too much. All functionality is kept
inside B- and (pseudo-)B. This forces one
to implement much more strict code than common perl would allow. What
first looks like a drawback, finally makes the code much easier to
understand, maintain and finally to extend.
CGI::XMLApplication knows two types of event handlers: implicit
events, common to all applications and explicit events, reflecting the
application logic. The class assumes that implicit events are
implemented in any case. Those events have reserved names and need not
be specified through B. Since the class cannot know
something about the application logic by itself, names of events have
to be explicitly passed to be handled by the application. As well all
event functions have to be implemented as member methods of the
application class right now. Because of perls OO interface a class has
to be written inside its own module.
An event may return a integer value. If the event succeeds (no fatal
errors, e.g. database errors) the explicit or common event function
should return a value greater or eqal than 0. If the value is less
than 0, CGI::XMLApplication assumes an application panic, and will not
try to generate a DOM or render it with a stylesheet.
There are 4 defined panic levels:
=over 4
=item -1
Stylesheet missing
=item -2
Stylesheet not available
=item -3
Event not implemented
=item -4
Application panic
=back
Apart from B the panic levels are set
internally. An Application Panic should be set if the application
catches an error, that does not allow any XML/XSLT processing. This
can be for example, that a required perl module is not installed on
the system.
To make it clear: If CGI::XMLApplication throws a panic, the
application is broken, not completely implemented or stylesheets are
missing or broken. Application panics are ment for debugging purposes
and to avoid I. They are B ment as a
replacement of a propper error handling!
But how does CGI::XMLApplication know about the correct event handler?
One needs to register the names of the events the application handles.
This is done by implmenting a registerEvents() function that simply
returns an B of event names. Through this function one prepares
the CGI::XMLApplication to catch the listed names as events from the
query string the client browser sends back to the
script. CGI::XMLApplication tries to call a event handler if a name of
a registred event is found. The coresponding function-name of an event
has to have the following format:
event_
E.g. event_init handles the init event described below.
Each event has a single Parameter, the context. This can be an unblessed
hash reference or an object, where the user can store whatever needed.
This context is useful to pass scriptwide data between callbacks and
event functions around. The callback is even available and useable if
the script does not initialize the application context as earlier shown
in the program flow chart.
If such a function is not implemented in the application module,
CGI::XMLApplication sets the I panic state.
All events have to return an integer that tells about their execution
state as already described.
By default CGI::XMLApplication does not test for other events if it
already found one. The most significant event is the first name of an
event found in the query string - all other names are simply ignored.
One may change this behaviour by overriding the B
function.
But still it is a good idea to choose the event names carefully and do
not mix them with ordinary datafield names.
=over 4
=item function testEvent
If it is nesseccary to check which event is relevant for the current
script one can use this function to find out in event_init(). If this
function returns I, the default event is active, otherwise it
returns the eventname as defined by B.
In case one needs a special algorithm for event selection one can
override this function. If done so, one can make use of the
application context inside this function since it is passed to
B by the B function.
=item method sendEvent SCALAR
Sometimes it could be neccessary to send an event by your own (the
script's) initiative. A possible example could be if you don't have
client input but path_info data, which determinates how the script
should behave or session information is missing, so the client should
not even get the default output.
This can only be done during the event_init() method call. Some coders
would prefer the constructor, which is not a very good idea in this
case: While the constructor is running, the application is not
completely initialized. This can be only ashured in the event_init
function. Therefore all application specific errorhandling and
initializing should be done there.
B only can be called from event_init, because any
CGI::XMLApplication will handle just one event, plus the B and
the B. If B is called from another event than
B it will take not effect.
It is possible through sendEvent() to keep the script logic clean.
Example:
package myApp;
use CGI::XMLApplication;
@ISA = qw(CGI::XMLApplication);
sub registerEvents { qw( missing ... ) ; }
# event_init is an implicit event
sub event_init {
my ( $self, $context ) = @_;
if ( not ( defined $self->param( $paraname ) && length $self->param( $paramname ) ) ){
# the parameter is not correctly filled
$self->sendEvent( 'missing' );
}
else {
... some more initialization ...
}
return 0;
}
... more code ...
# event_missing is an explicit event.
sub event_missing {
my ( $self , $context ) = @_;
... your error handling code goes ...
return -4 if $panic; # just for illustration
return 0;
}
=back
=head2 Implicit Events
CGI::XMLApplication knows three implicit events which are more or less
independent to client responses: They are 'init', 'exit', and
'default'. These events already exist for any
CGI::XMLApplication. They need not to be implemented separatly if they
make no sense for the application.
=over 4
=item event_init
The init event is set before the CGI::XMLApplication tries to evaluate
any of script parameters. Therefore the event_init method should be
used to initialize the application.
=item event_exit
The event_exit method is called after all other events have been
processed, but just before the rendering is done. This should be used,
if you need to do something independend from all events before the
data is send to the user.
=item event_default
This event is called as a fallback mechanism if CGI::XMLApplication
did not receive a stylesheet id by an other event handler; for example
if no event matched.
=back
=head2 the XML Serialization
The presentation is probably the main part of a CGI script. By using
XML and XSLT this can be done in a standartised manner. From the
application view all this can be isolated in a separate subsystem as
well. In CGI::XMLApplication this subsystem is implemented inside the
B function.
For XML phobic perl programmers it should be cleared, that
CGI::XMLApplication makes real use of XML/XSLT functionalty only
inside this function. For all code explained above it is not required
to make use of XML at all.
The XML serialization subsystem of CGI::XMLApplication tries to hide
most of non application specific code from the application programmer.
This method renders the data stored in the DOM with the stylesheet
returned by the event handler. You should override this function if
you like to use a different way of displaying your data.
If the serialization should be skipped, CGI::XMLApplication will not
print any headers. In such case the application is on its own to pass
all the output.
The algorithm used by serialization is simple:
=over 4
=item * request the appplication DOM through B
=item * test for XML passthru
=item * get the stylesheet the application preferes through B
=item * parse the stylesheet
=item * transform the DOM with the stylesheet
=item * set Content-Type and headers
=item * return the content to the client
=back
If errors occour on a certain stage of serialization, the application
is stopped and the generated error messages are returned.
CGI::XMLApplication provides four pseudo-callbacks, that are used to
get the application specific information during serialization. In
order of being called by CGI::XMLApplication::serialization() they
are:
=over 4
=item * getDOM
=item * setHttpHeader
=item * getStylesheet
=item * getXSLTParameter
=back
In fact only getStylesheet has to be implemented. In most cases it
will be a good idea to provide the getDOM function as well. The other
functions provider a interface to make the CGI output more
generic. For example one can set cookies or pass XSL parameters to
XML::LibXSLT's xsl processor.
These methods are used by the serialization function, to create the
content related datastructure. Like event functions these functions
have to be implemented as class member, and like event funcitons the
functions will have the context passed as the single parameter.
=over 4
=item getDOM()
getDOM() should return the application data as
XML-DOM. CGI::XMLApplication is quite lax if this function does not
return anything - its simply assumed that an empty DOM should be
rendered. In this case a dummy root element is created to avoid error
messages from XML::LibXSLT.
=item setHttpHeader()
B should return a hash of headers (but not the
Content-Type). This can be used to set the I pragma, to set
or remove cookies. The keys of the hash must be the same as the named
parameters of CGI.pm's header method. One does not need to care about
the output of these headers, this is done by CGI::XMLApplication
automaticly.
The content type of the returned data is usually not required to be
set this way, since the XSLT processor knows about the content type,
too.
=item getStylesheet()
If the B is implemented the CGI::XMLApplication will
assume the returned value either as a filename of a stylesheet or as a
XML DOM representation of the same. If Stylesheets are stored in a
file accessable from the , one should set the common path for the
stylesheets and let B do the parsing job.
In cases the stylesheet is already present as a string (e.g. as a
result of a database query) one may pass this string directly to
B.
I is an alias for I left for
compatibility reasons.
If none of these stylesheet selectors succeeds the I panic code is thrown. If the parsing of the stylesheet XML
fails I is thrown. The latter case will also
give some informations where the stylesheet selection failed.
B has to return a valid path/filename for the
stylesheet requested.
=item getXSLTParameter()
This function allows to pass a set of parameters to XML::LibXSLT's xsl
processor. The function needs only to return a hash and does not need
to encode the parameters.
The function is the last callback called before the XSLT processing is
done.
=back
=head2 Flow Control
Besides the sendEvent() function does CGI::XMLApplication provide to
other functions that allow to controll the flow of the application.
These two functions are related to the XML serialization and have not
affect to the event handling.
=over 4
=item passthru()
Originally for debugging purposes CGI::XMLApplication supports the
B argument in the CGI query string. It can be used to
directly pass the stringified XML-DOM to the client.
Since there are cases one needs to decide from within the application
if an untransformed XML Document has to be returned, this function was
introduced.
If is called without parameters B returns the current
passthru state of the application. E.g. this is done inside
B. Where TRUE (1) means the XML DOM should be passed
directly to the client and FALSE (0) marks that the DOM must get
XSL transformed first.
Optional the function takes a single parameter, which shows if the
function should be used in set rather than get mode. The parameter is
interpreted as just described.
If an application sets passthru by itself any external 'passthru'
parameter will be lost. This is usefull if one likes to avoid, someone
can fetch the plain (untransformed) XML Data.
=item skipSerialization()
To avoid the call of B one should set B.
event_default {
my $self = shift;
# avoid serialization call
$self->skipSerialization( 1 ); # use 0 to unset
# now you can directly print to the client, but don't forget the
# headers.
return 0;
}
=back
=head2 Helperfunctions for internal use
=over 4
=item function checkPush LIST
This function searches the query string for a parameter with the
passed name. The implementation is "imagesave" meaning there is no
change in the code needed, if you switch from input.type=submit to
input.type=image or vv. The algorithm tests wheter a full name is
found in the querystring, if not it tries tests for the name expanded
by a '.x'. In context of events this function interprets each item
part in the query string list as an event. Because of that, the
algorithm returns only the first item matched.
If you use the event interface on this function, make sure, the
HTML-forms pass unique events to the script. This is neccessary to
avoid confusing behaviour.
This function is used by testEvent() so if it is required to change
the way CGI::XMLApplication selects events, override that function.
=item method panic SCALAR
This a simple error message handler. By default this function will
print some information to the client where the application
failed. While development this is a useful feature on production
system this may pass vunerable informations about the system to the
outside. To change the default behaviour, one may write his own panic
method or simply set I<$CGI::XMLApplication::Quiet> to 1. The latter
still causes the error page but does not send any error message.
The current implementation send the 404 status to the client if any
low level errors occour ( e.g. panic levels > -4 aka Application
Panic). Commonly this really shows a "Not Found" on the application
Level. Application Panics will set the 500 error state. This makes
this implementation work perfect with a mod_perl installation.
In case L is used to handle the script one likes to set
I to 2 which will cause
CGI::XMLApplication just to return the error state while L
does the rest.
=item method setPanicMsg $SCALAR
This useful method, helps to pass more specific error messages to the
user. Currently this method is not very sophisticated: if
the method is called twice, only the last string will be displayed.
=item function getPanicMsg
This method returns the panic message set by setPanicMsg().
=back
=head2 CGI Extras
The following functions are some neat features missing in
CGI.pm
=over 4
=item function checkFields LIST
This is an easy way to test wether all required fields are filled out
correctly. Called in array context the function returns the list of
missing parameter. (Different to param() which returns all parameter names).
In scalar context the function returns a boolean value.
=item function getParamHash LIST
This function is a bit better for general data processing as
the standard CGI::Vars function. While Vars sets a keys for each
parameter found in the query string, getFieldsAsHash returns only the
requested fields (as long they aren't NULL). This is useful in scripts
where the script itself handles different kind of data within the
same event.
Since the function relies on Vars the returned data has the same
structure Vars returns.
=back
=head2 some extra functions for stylesheet handling
The getStylesheet() function should return either a filename or a
stringnyfied XSL-DOM. For the firstcase it can be a restriction to
return the fully qualified path. The following functions allow to set
the stylesheetpath systemwide.
=over 4
=item method setStylesheetDir DIRNAME
alias for B
=item method setStylesheetPath DIRNAME
This method is for telling the application where the stylesheets can
be found. If you keep your stylesheets in the same directory as your
script -- IMHO a bad idea -- you might leave this untouched.
=item function getStylesheetPath
This function is only relevant if you write your own
B method. It returns the current path to the
application stylesheets.
=back
=head1 SEE ALSO
CGI, perlobj, perlmod, XML::LibXML, XML::LibXSLT
=head1 AUTHOR
Christian Glahn, christian.glahn@uibk.ac.at
=head1 VERSION
1.1.1
CGI-XMLApplication-1.1.3/README 0100644 0000764 0000764 00000014131 07327000735 014644 0 ustar phish phish CGI::XMLApplication
How To Install?
The installation should be perlish :)
perl Makefile.PL
make
make test
make install
CGI::XMLApplication requires the XML::LibXML and XML::LibXSLT module.
Both modules are available on CPAN.
What is CGI::XMLApplication?
Perl modules to implement OO CGI-Scripts with XML capabilities in
Perl similar to CGI::Application. It is not related to CGI::XML
(than it would be CGI::XML::Application) ;) and does not include
any features of it (yet)
CGI::XMLApplication is not a simple add on to CGI.pm! I think there
is no simple and fast way to convert existing CGI scripts. This is
basicly because of the gap of main concepts and paradigmata between
CGI.pm and CGI::XMLApplication, although CGI.pm is the SUPER class of
CGI::XMLApplication.
Why is there broken english?
I don't need english for living, but I can speak "all right", but
writing is something different :)
I will try to fix the broken section as soon as possible, so I hope
this situation does not last a long time ;)
The problems behind the scene.
While most CGI-Scripts are embedded into larger web based applications
the scripts themselves usually do not represent this fact. The
evolutionary grown mosaic of an traditional CGI-Script assembly style
application cannot easily be extended with certain features, relevant
to the application in general.
CGI::XMLApplication is an application framework to implement
CGI-Scripts in Perl without the overhead of a complete Perl
application. The framework should hide most of the important, but
redundant code of a Perl CGI-Application shared by several
scripts. Since CGI.pm is a very powerfull module to implement CGI
scripts it is used as a super class of CGI::XMLApplication. This
should make the implementation of new scripts usinge this class easy,
since the whole Interface of CGI.pm is still available. There are some
conceptual changes, basicly related to the response that reflect
concepts of XML/XSLT. This has the effect, that most output functions
of CGI.pm are not very usefull if used from this class ;)
The module have especially been written to enable Perl newbees to
write full featured CGI-Scripts and CGI applications. To make things
more easier readable for people, the CGI:OO module forces the
programmer to implement the application rather problem-orientated than
programm-code-orientated.
Using such concepts makes it much easier for people, who want to
understand the code -- and usually they are forced to --, to follow
the structure of the application. In larger software projects this is
a very important aspect.
Using the object and problem orientated application programming
paradigma makes it possible to develop a certain (web based)
application aloing its structure, not along the restraints of its
primary programming language. The CGI::XMLApplication concept opens the
possiblity to port the application to another programming language
(like C++ or Java) more easily. This aspect is quite important if a
port has to be done -- be it for performance or any other reasons.
Why should I use it?
If you are planning to implement a single script CGI application, that
should do a very simple job, CGI::XMLApplication is probably not what
you are looking for. More commonly Netslaves like us are forced to
implement fully grown web based applications consisting of a set of
more or less isolated CGI-Scripts. Each script having a default
behaviour, for example doing something after an event like a button
being pushed or a link beeing followed by the client. If you know a
little about CGI-Scripts, you may already have recognized that scripts
look amazingly similar in their principal function-set. Most of the
scripts may have quite similar implementations of the same basic
requirements they should fulfill. That being a potential source for
redundancy and painful hours debugging. This is there
CGI::XMLApplication comes in -- a problem oriented application
framework to avoid redundancies and to facilitate easier portabilty of
Perl based CGI applications.
Where is the difference to CGI::Application?
This question is quite important, since CGI::Application was discussed
on the Web a lot at the time I wrote this module. The main difference
I see, is that CGI::XMLApplication includes the XML paradigma of
dispairing data and datapresentation.
The second major difference is, that a perl programmer does not have
that much freedom on the programm structure. Yes, CGI::XMLApplication
is rather strict compared to what perl is known for ;) I realized in
my day to day work, this freedom causes a lot of problems in midsize
or large W3 application projects.
The less obvious difference is how the data presentation is
done. While CGI::Application uses the "propritary" perl format for
data presentation, CGI::XMLApplication uses by default XML and XSLT,
which are a web standard. This leaves the oportunity to change the
programm code and even the programming language, but leaves the data
presentation untouched. As well new output formats can be added,
without changeing the entire script code. This is what project
managers really like to hear ;)
Classical CGI scripts will have most allways quite a lot print calls
(or at least some thing similar). All these calls are related to the
field of data persentation, usually a job done by designers or HTML
programmers. Both modules CGI.pm and CGI::Application include such --
what I call -- formating functions. A perl coder using
CGI::XMLApplication does not need to care about the data presentation
a client will finally see. Therefore formated output calls as they are
used in CGI.pm and CGI::Application doesn't make much sense with
CGI::XMLApplication. The data presentation itself is done through XSLT
Stylesheets. The script has to care only about the data, which should
be kept in a XML-DOM. So a script programmer provides a set of data to
a stylesheet and does not care about the output anymore (which is done
by the class btw.)
As well CGI::XMLApplication implements a more strict application
structure, than CGI::Application. CGI::XMLApplication handles script
initialization, functionality, cleanup and data output is strictly
separated parts of the script.
CGI-XMLApplication-1.1.3/Makefile.PL 0100644 0000764 0000764 00000000500 07375321070 015732 0 ustar phish phish use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
'NAME' => 'CGI::XMLApplication',
'VERSION_FROM' => 'XMLApplication.pm', # finds $VERSION
'PREREQ_PM' => {XML::LibXML => 1.10, XML::LibXSLT => 1.08 },
);