.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sh \" Subsection heading
.br
.if t .Sp
.ne 5
.PP
\fB\\$1\fR
.PP
..
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
'br\}
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. nr % 0
. rr F
.\}
.\"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.hy 0
.if n .na
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
.if n \{\
. ds #H 0
. ds #V .8m
. ds #F .3m
. ds #[ \f1
. ds #] \fP
.\}
.if t \{\
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. ds #V .6m
. ds #F 0
. ds #[ \&
. ds #] \&
.\}
. \" simple accents for nroff and troff
.if n \{\
. ds ' \&
. ds ` \&
. ds ^ \&
. ds , \&
. ds ~ ~
. ds /
.\}
.if t \{\
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
. ds : e
. ds 8 ss
. ds o a
. ds d- d\h'-1'\(ga
. ds D- D\h'-1'\(hy
. ds th \o'bp'
. ds Th \o'LP'
. ds ae ae
. ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "XMLApplication 3pm"
.TH XMLApplication 3pm "2005-01-18" "perl v5.8.8" "User Contributed Perl Documentation"
.SH "NAME"
CGI::XMLApplication \e\-\e\- Object Oriented Interface for CGI Script Applications
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\& use CGI::XMLApplication;
.Ve
.PP
.Vb 2
\& $script = new CGI::XMLApplication;
\& $script\e\->setStylesheetPath( "the/path/to/the/stylesheets" );
.Ve
.PP
.Vb 4
\& # either this for simple scripts
\& $script\e\->run();
\& # or if you need more control ...
\& $script\e\->run(%context_hash); # or a context object
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
CGI::XMLApplication is a \s-1CGI\s0 application class, that intends to enable
perl artists to implement CGIs that make use of \s-1XML/XSLT\s0
functionality, without taking too much care about specialized
errorchecking or even care too much about \s-1XML\s0 itself. It provides the
power of the XML::LibXML/ XML::LibXSLT module package for
content deliverment.
.PP
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.
.PP
The class module extends the \s-1CGI\s0 class. While all functionality of the
original \s-1CGI\s0 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 \fI\fIparam()\fI\fR.
.PP
CGI::XMLApplication, intended to be an application class should make
writing of \s-1XML\s0 enabled \s-1CGI\s0 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.
.PP
The main difference with common perl \s-1CGI\s0 implementation is the fact,
that the client-output is not done from perl functions, but generated
by an internally build \s-1XML\s0 \s-1DOM\s0 that gets processed with an \s-1XSLT\s0
stylesheet. This fact helps to remove a lot of the \s-1HTML\s0 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 \s-1XSLT\s0 file).
.PP
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.
.PP
Since the class uses the \s-1OO\s0 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
\&\fBevents\fR, 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.
.PP
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 \s-1OO\s0 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 \fBevents\fR 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.
.PP
Another design aspect for CGI::XMLApplication is the strict
differentiation between \s-1CODE\s0 and \s-1PRESENTATION\s0. \s-1IMHO\s0 this, in fact
being one of the major problems in traditional \s-1CGI\s0 programming. To
implement this, the XML::LibXML and XML::LibXSLT modules are used by
default but may be replaced easily by any other \s-1XML/XSLT\s0 capable
modules. Each \s-1CGI\s0 Script should generate an \s-1XML\-DOM\s0, that can be
processed with a given stylesheet.
.PP
\&\fBPay attention: In this Document XML-DOM means the \s-1DOM\s0 of XML::LibXML
and not \s-1XML::DOM\s0!\fR
.Sh "Programflow of a CGI::XMLApplication"
.IX Subsection "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.
.PP
.Vb 47
\& \-\-\-\-\-\-\- CGI Script \-\-\-\-\-\-\->|<\-\-\-\-\-\-\-\-\- CGI::XMLApplication \-\-\-\-\-\-\-\-
\& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-.
\& | app\-class creation |\-\-\- | event registration |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-' | registerEvents() |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. |
\& | context initialization |\-\-\-\-\-\-\-\-\-\-\-\-'
\& | ( optional ) |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& |
\& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-.
\& | run() function called |\-\-| application initialize |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-' | event_init() |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& |
\& .\-\-\-\-\-\-\-\-'`\-\-\-\-\-\-\-\-\-\-\-\-.
\& / event parameter found? \e_
\& \e testEvent() / \e
\& `\-\-\-\-\-\-\-\-.,\-\-\-\-\-\-\-\-\-\-\-\-' |
\& | |
\& yes | no |
\& | |
\& .\-\-\-\-\-\-\-\-\-\-\-\-. .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-.
\& | call event | | call |
\& | event_*() | | event_default() |
\& `\-\-\-\-\-\-\-\-\-\-\-\-' `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& | |
\& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. |
\& | application cleanup |\-\-\-\-\-'
\& | event_exit() |
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& |
\& .\-\-\-\-\-\-\-\-\-'`\-\-\-\-\-\-\-\-\-\-\-\-.
\& _/ avoid XML serialization \e
\& / \e skip_serialization() /
\& | `\-\-\-\-\-\-\-\-\-.,\-\-\-\-\-\-\-\-\-\-\-\-'
\& | |
\& yes | no |
\& | |
\& | .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-.
\& | | XML generation, XSLT |
\& | | serialization and output |
\& | | serialization() |
\& | `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& .\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-. | |
\& | END |\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-'
\& `\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-'
.Ve
.Sh "What are Events and how to catch them"
.IX Subsection "What are Events and how to catch them"
Most \s-1CGI\s0 Scripts handle the result of HTML-Forms or similar requests
from clients. Analouge to \s-1GUI\s0 Programming, CGI::XMLApplication calls
this an \fBevent\fR. 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 \s-1CGI\s0's query string.
.PP
An event of CGI::XMLApplication has the same \fBname\fR as the input
field, that should cause the event. The following example should
illustrate this a little better:
.PP
.Vb 3
\&
\&
\&
.Ve
.PP
If a user clicks the submitbutton and you have registered the event
name \fBdummy\fR for your script, CGI::XMLApplication will try to call the
function \fB\f(BIevent_dummy()\fB\fR. The script module to handle the dummy event
would look something like the following code:
.PP
.Vb 2
\& # Application Module
\& package myApp;
.Ve
.PP
.Vb 2
\& use CGI::XMLApplication;
\& @ISA = qw(CGI::XMLApplication);
.Ve
.PP
.Vb 1
\& sub registerEvents { qw( dummy ); } # list of event names
.Ve
.PP
.Vb 1
\& # ...
.Ve
.PP
.Vb 2
\& sub event_dummy {
\& my ( $self, $context ) = @_;
.Ve
.PP
.Vb 1
\& # your event code goes here
.Ve
.PP
.Vb 2
\& return 0;
\& }
.Ve
.PP
During the lifecircle of a \s-1CGI\s0 script, often the implementation starts
with ordinary submit buttons, which get often changed to so called
input images, to fit into the \s-1UI\s0 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 \fBor\fR evname.x exist in the
querystring.
.PP
So a perl artist can implement and test his code without caring if the
design crew have done their job, too ;\-)
.PP
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 \fBspecial events\fR
from the \fB\f(BIevent_init()\fB\fR function for example in case of application
errors. This is done with the \fB\f(BIsendEvent()\fB\fR Function. This will set a
new parameter to the \s-1CGI\s0's querystring after removing all other
events. \fBOne can only send events that are already registred!\fR.
.PP
Although a sendEvent function exists, CGI::XMLApplication doesn't
implement an event queqe. For \s-1GUI\s0 programmers this seems like a
unnessecary restriction. In terms of \s-1CGI\s0 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 \fIevent_init()\fR 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.
.IP "method registerEvents" 4
.IX Item "method registerEvents"
This method is called by the class constructor \e\- namely
CGI::XMLApplication's \fB\f(BInew()\fB\fR 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.
.IP "method run" 4
.IX 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 \fB\f(BIrun()\fB\fR. 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.
.Sp
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.
.Sh "The Event System"
.IX Subsection "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.
.PP
Commonly applications that make use of CGI::XMLApplication, will not
bother about the \fBrun\fR function too much. All functionality is kept
inside \fBevent\fR\- and (pseudo\-)\fBcallback functions\fR. 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.
.PP
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 \fBregisterEvents\fR. 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 \s-1OO\s0 interface a class has
to be written inside its own module.
.PP
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 \s-1DOM\s0 or render it with a stylesheet.
.PP
There are 4 defined panic levels:
.IP "\e\-1" 4
.IX Item "-1"
Stylesheet missing
.IP "\e\-2" 4
.IX Item "-2"
Stylesheet not available
.IP "\e\-3" 4
.IX Item "-3"
Event not implemented
.IP "\e\-4" 4
.IX Item "-4"
Application panic
.PP
Apart from \fBApplication Panic\fR the panic levels are set
internally. An Application Panic should be set if the application
catches an error, that does not allow any \s-1XML/XSLT\s0 processing. This
can be for example, that a required perl module is not installed on
the system.
.PP
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 \fIInternal Server Errors\fR. They are \fBnot\fR ment as a
replacement of a propper error handling!
.PP
But how does CGI::XMLApplication know about the correct event handler?
.PP
One needs to register the names of the events the application handles.
This is done by implmenting a \fIregisterEvents()\fR function that simply
returns an \fBarray\fR 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:
.PP
.Vb 1
\& event_
.Ve
.PP
E.g. event_init handles the init event described below.
.PP
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.
.PP
If such a function is not implemented in the application module,
CGI::XMLApplication sets the \fIEvent not implemented\fR panic state.
.PP
All events have to return an integer that tells about their execution
state as already described.
.PP
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 \e\- all other names are simply ignored.
One may change this behaviour by overriding the \fB\f(BItestEvent()\fB\fR
function.
.PP
But still it is a good idea to choose the event names carefully and do
not mix them with ordinary datafield names.
.IP "function testEvent" 4
.IX 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 \fIevent_init()\fR. If this
function returns \fIundef\fR, the default event is active, otherwise it
returns the eventname as defined by \fBregisterEvents\fR.
.Sp
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
\&\fB\f(BItestEvent()\fB\fR by the \fB\f(BIrun()\fB\fR function.
.IP "method sendEvent \s-1SCALAR\s0" 4
.IX 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.
.Sp
This can only be done during the \fIevent_init()\fR 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.
.Sp
\&\fBsendEvent\fR only can be called from event_init, because any
CGI::XMLApplication will handle just one event, plus the \fBinit\fR and
the \fBexit event\fR. If \fBsendEvent\fR is called from another event than
\&\fB\f(BIevent_init()\fB\fR it will take not effect.
.Sp
It is possible through \fIsendEvent()\fR to keep the script logic clean.
.Sp
Example:
.Sp
.Vb 3
\& package myApp;
\& use CGI::XMLApplication;
\& @ISA = qw(CGI::XMLApplication);
.Ve
.Sp
.Vb 1
\& sub registerEvents { qw( missing ... ) ; }
.Ve
.Sp
.Vb 8
\& # event_init is an implicit event
\& sub event_init {
\& my ( $self, $context ) = @_;
\& if ( not ( defined $self\e\->param( $paraname ) && length $self\e\->param( $paramname ) ) ){
\& # the parameter is not correctly filled
\& $self\e\->sendEvent( 'missing' );
\& }
\& else {
.Ve
.Sp
.Vb 1
\& ... some more initialization ...
.Ve
.Sp
.Vb 3
\& }
\& return 0;
\& }
.Ve
.Sp
.Vb 1
\& ... more code ...
.Ve
.Sp
.Vb 3
\& # event_missing is an explicit event.
\& sub event_missing {
\& my ( $self , $context ) = @_;
.Ve
.Sp
.Vb 1
\& ... your error handling code goes ...
.Ve
.Sp
.Vb 3
\& return \e\-4 if $panic; # just for illustration
\& return 0;
\& }
.Ve
.Sh "Implicit Events"
.IX Subsection "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.
.IP "event_init" 4
.IX 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.
.IP "event_exit" 4
.IX 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.
.IP "event_default" 4
.IX 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.
.Sh "the \s-1XML\s0 Serialization"
.IX Subsection "the XML Serialization"
The presentation is probably the main part of a \s-1CGI\s0 script. By using
\&\s-1XML\s0 and \s-1XSLT\s0 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
\&\fB\f(BIserialize()\fB\fR function.
.PP
For \s-1XML\s0 phobic perl programmers it should be cleared, that
CGI::XMLApplication makes real use of \s-1XML/XSLT\s0 functionalty only
inside this function. For all code explained above it is not required
to make use of \s-1XML\s0 at all.
.PP
The \s-1XML\s0 serialization subsystem of CGI::XMLApplication tries to hide
most of non application specific code from the application programmer.
.PP
This method renders the data stored in the \s-1DOM\s0 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.
.PP
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.
.PP
The algorithm used by serialization is simple:
.IP "* request the appplication \s-1DOM\s0 through \fB\f(BIgetDOM()\fB\fR" 4
.IX Item "request the appplication DOM through getDOM()"
.PD 0
.IP "* test for \s-1XML\s0 passthru" 4
.IX Item "test for XML passthru"
.IP "* get the stylesheet the application preferes through \fB\f(BIselectStylesheet()\fB\fR" 4
.IX Item "get the stylesheet the application preferes through selectStylesheet()"
.IP "* parse the stylesheet" 4
.IX Item "parse the stylesheet"
.IP "* transform the \s-1DOM\s0 with the stylesheet" 4
.IX Item "transform the DOM with the stylesheet"
.IP "* set Content-Type and headers" 4
.IX Item "set Content-Type and headers"
.IP "* return the content to the client" 4
.IX Item "return the content to the client"
.PD
.PP
If errors occour on a certain stage of serialization, the application
is stopped and the generated error messages are returned.
.PP
CGI::XMLApplication provides four pseudo\-callbacks, that are used to
get the application specific information during serialization. In
order of being called by \fICGI::XMLApplication::serialization()\fR they
are:
.IP "* getDOM" 4
.IX Item "getDOM"
.PD 0
.IP "* setHttpHeader" 4
.IX Item "setHttpHeader"
.IP "* getStylesheet" 4
.IX Item "getStylesheet"
.IP "* getXSLTParameter" 4
.IX Item "getXSLTParameter"
.PD
.PP
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 \s-1CGI\s0 output more
generic. For example one can set cookies or pass \s-1XSL\s0 parameters to
XML::LibXSLT's xsl processor.
.PP
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.
.IP "\fIgetDOM()\fR" 4
.IX Item "getDOM()"
\&\fIgetDOM()\fR should return the application data as
\&\s-1XML\-DOM\s0. CGI::XMLApplication is quite lax if this function does not
return anything \e\- its simply assumed that an empty \s-1DOM\s0 should be
rendered. In this case a dummy root element is created to avoid error
messages from XML::LibXSLT.
.IP "\fIsetHttpHeader()\fR" 4
.IX Item "setHttpHeader()"
\&\fBsetHttpHeader\fR should return a hash of headers (but not the
Content\-Type). This can be used to set the \fInocache\fR pragma, to set
or remove cookies. The keys of the hash must be the same as the named
parameters of \s-1CGI\s0.pm's header method. One does not need to care about
the output of these headers, this is done by CGI::XMLApplication
automaticly.
.Sp
The content type of the returned data is usually not required to be
set this way, since the \s-1XSLT\s0 processor knows about the content type,
too.
.IP "\fIgetStylesheet()\fR" 4
.IX Item "getStylesheet()"
If the \fBgetStylesheet\fR is implemented the CGI::XMLApplication will
assume the returned value either as a filename of a stylesheet or as a
\&\s-1XML\s0 \s-1DOM\s0 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 \fBCGI::XMLApplication\fR do the parsing job.
.Sp
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
\&\fBCGI::XMLApplication\fR.
.Sp
\&\fIselectStylesheet\fR is an alias for \fIgetStylesheet\fR left for
compatibility reasons.
.Sp
If none of these stylesheet selectors succeeds the \fIStylesheet
missing\fR panic code is thrown. If the parsing of the stylesheet \s-1XML\s0
fails \fIStylesheet not available\fR is thrown. The latter case will also
give some informations where the stylesheet selection failed.
.Sp
\&\fB\f(BIselectStylesheet()\fB\fR has to return a valid path/filename for the
stylesheet requested.
.IP "\fIgetXSLTParameter()\fR" 4
.IX 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.
.Sp
The function is the last callback called before the \s-1XSLT\s0 processing is
done.
.Sh "Flow Control"
.IX Subsection "Flow Control"
Besides the \fIsendEvent()\fR function does CGI::XMLApplication provide to
other functions that allow to controll the flow of the application.
.PP
These two functions are related to the \s-1XML\s0 serialization and have not
affect to the event handling.
.IP "\fIpassthru()\fR" 4
.IX Item "passthru()"
Originally for debugging purposes CGI::XMLApplication supports the
\&\fBpassthru\fR argument in the \s-1CGI\s0 query string. It can be used to
directly pass the stringified XML-DOM to the client.
.Sp
Since there are cases one needs to decide from within the application
if an untransformed \s-1XML\s0 Document has to be returned, this function was
introduced.
.Sp
If is called without parameters \fB\f(BIpassthru()\fB\fR returns the current
passthru state of the application. E.g. this is done inside
\&\fB\f(BIserialization()\fB\fR. Where \s-1TRUE\s0 (1) means the \s-1XML\s0 \s-1DOM\s0 should be passed
directly to the client and \s-1FALSE\s0 (0) marks that the \s-1DOM\s0 must get
\&\s-1XSL\s0 transformed first.
.Sp
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.
.Sp
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) \s-1XML\s0 Data.
.IP "\fIskipSerialization()\fR" 4
.IX Item "skipSerialization()"
To avoid the call of \fB\f(BIserialization()\fB\fR one should set \fBskipSerialization\fR.
.Sp
.Vb 4
\& event_default {
\& my $self = shift;
\& # avoid serialization call
\& $self\e\->skipSerialization( 1 ); # use 0 to unset
.Ve
.Sp
.Vb 2
\& # now you can directly print to the client, but don't forget the
\& # headers.
.Ve
.Sp
.Vb 2
\& return 0;
\& }
.Ve
.Sh "Helperfunctions for internal use"
.IX Subsection "Helperfunctions for internal use"
.IP "function checkPush \s-1LIST\s0" 4
.IX Item "function checkPush LIST"
This function searches the query string for a parameter with the
passed name. The implementation is \*(L"imagesave\*(R" 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.
.Sp
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.
.Sp
This function is used by \fItestEvent()\fR so if it is required to change
the way CGI::XMLApplication selects events, override that function.
.IP "method panic \s-1SCALAR\s0" 4
.IX 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 \fI$CGI::XMLApplication::Quiet\fR to 1. The latter
still causes the error page but does not send any error message.
.Sp
The current implementation send the 404 status to the client if any
low level errors occour ( e.g. panic levels > \e\-4 aka Application
Panic). Commonly this really shows a \*(L"Not Found\*(R" on the application
Level. Application Panics will set the 500 error state. This makes
this implementation work perfect with a mod_perl installation.
.Sp
In case mod_perl is used to handle the script one likes to set
\&\fICGI::XMLApplication::Quiet\fR to 2 which will cause
CGI::XMLApplication just to return the error state while mod_perl
does the rest.
.ie n .IP "method setPanicMsg $SCALAR" 4
.el .IP "method setPanicMsg \f(CW$SCALAR\fR" 4
.IX 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.
.IP "function getPanicMsg" 4
.IX Item "function getPanicMsg"
This method returns the panic message set by \fIsetPanicMsg()\fR.
.Sh "\s-1CGI\s0 Extras"
.IX Subsection "CGI Extras"
The following functions are some neat features missing in
\&\s-1CGI\s0.pm
.IP "function checkFields \s-1LIST\s0" 4
.IX 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 \fIparam()\fR which returns all parameter names).
In scalar context the function returns a boolean value.
.IP "function getParamHash \s-1LIST\s0" 4
.IX 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 \s-1NULL\s0). This is useful in scripts
where the script itself handles different kind of data within the
same event.
.Sp
Since the function relies on Vars the returned data has the same
structure Vars returns.
.Sh "some extra functions for stylesheet handling"
.IX Subsection "some extra functions for stylesheet handling"
The \fIgetStylesheet()\fR function should return either a filename or a
stringnyfied \s-1XSL\-DOM\s0. For the firstcase it can be a restriction to
return the fully qualified path. The following functions allow to set
the stylesheetpath systemwide.
.IP "method setStylesheetDir \s-1DIRNAME\s0" 4
.IX Item "method setStylesheetDir DIRNAME"
alias for \fBsetStylesheetPath\fR
.IP "method setStylesheetPath \s-1DIRNAME\s0" 4
.IX 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 \e\-\e\- \s-1IMHO\s0 a bad idea \e\-\e\- you might leave this untouched.
.IP "function getStylesheetPath" 4
.IX Item "function getStylesheetPath"
This function is only relevant if you write your own
\&\fB\f(BIserialization()\fB\fR method. It returns the current path to the
application stylesheets.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\s-1CGI\s0, perlobj, perlmod, XML::LibXML, XML::LibXSLT
.SH "AUTHOR"
.IX Header "AUTHOR"
Christian Glahn, christian.glahn@uibk.ac.at
.SH "VERSION"
.IX Header "VERSION"
1.1.1