view release on metacpan or  search on metacpan

t/pms/RayApp.pm  view on Meta::CPAN

		my $q = new RayApp::Request($r);
		return ($dbh, $q);
	}
	1;

Here we first validate parameters against DSD (you can optionally
die or just log an error, depending on how strict you want to be),
we connect to the database, so that the applications get connection
to their database backend, and we use B<RayApp::Request> to get
uniform (for mod_perl and CGI) query object. The values B<$dbh> and
B<$q> are returned and will be passed as argument to the application
B<handler>.

=item RayAppStyleParamModule / RAYAPP_STYLE_PARAM_MODULE

There are often additional data except the core data of the
application that you might like to process in your XSLT
stylesheets -- id of the authenticated user, the full and
relative URLs of the currently running application, some sticky
preferences of the user. They are more related to the presentation
than to the business logic of the application, so you do not want to
have them in your DSD and have all your applications generate them and
return them.

The option B<RayAppStyleParamModule> specifies a module name from
which a B<handler> function will be called for every request that goes
to the postprocessing stage. It will be passed the DSD object and the
same arguments as the application B<handler> (those returned by
B<RayAppInputModule>) and it should return a list of key => value
pairs that will be passed to the stylesheet.

A simple style parameter module might look like this:

	package Application::Style_params;
	sub handler {
		my ($dsd, $dbh, $q) = @_;
		return (
			my_full_url => $q->url( -full => 1 ),
			my_relative_url => $q->url( -relative => 1 ),
			dbuser => $dbh->{'Username'},
                );
	}
	1;

and in the XSLT you will get to them for example via

	<xsl:value-of select="$my_relative_url"/>

=item RayAppStyleStaticParams / RAYAPP_STYLE_STATIC_PARAMS

When a static .xml file is processed into HTML, the XSL
transformation is run, even if there was no application invocation
in the process. Normally, the B<handler> of module specified by
B<RayAppInputModule> would not be run in this case. If you want the
module to be run even in this case (thus generating input argument for
the B<RayAppStyleParamModule> module), set this option to true.

=head2 The applications

Having the Web server set up, you can write your first application
in B<RayApp> manner. For start, a simplistic application which only
returns two values will be enough.

First the DSD file, /opt/www/app.dsd:

	<?xml version="1.0"?>
	<root>
		<_param name="name"/>
		<name/>
		<time/>
	</root>

The application will accept one parameter, B<name> and will return
hash with two values, B<name> and B<time>. The code in
/opt/www/app.mpl can be

	sub handler {
		my ($dbh, $q) = @_;
		return {
			name => scalar($q->param('name')),
			time => time,
		};
	}
	1;

Note that the B<$dbh> and B<$q> values are generated by the module
specified by B<RayAppInputModule>.

The application returns a hash with two elements. A request for

	http://server/sub/app.xml?name=Peter

should return

	<?xml version="1.0"?>
	<root>
		<name>Peter</name>
		<time>1075057209</time>
	</root>

Adding the /opt/www/app.xsl file with XSLT templates should be
easy now.

=head1 SEE ALSO

RayApp::DSD(3), RayApp::Request(3)

=head1 AUTHOR

Copyright (c) Jan Pazdziora 2001--2006

=head1 VERSION

This documentation is believed to describe accurately B<RayApp>
version 2.004.