view release on metacpan or  search on metacpan

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

			my $package = 'RayApp::Root::pkn' . $handler;
			$handler = $package . '::handler';
			### print STDERR "Loading\n";

			local *FILE;
			open FILE, $application or die "Error reading `$application': $!\n";
			local $/ = undef;
			my $content = <FILE>;
			close FILE or die "Error reading `$application' during close: $!\n";
			if (${^TAINT}) {
				$content =~ /^(.*)$/s and $content = $1;
			}
			my $max_num = $self->{max_handler_num};
			if (not defined $max_num) {
				$max_num = 0;
			}
			## $content =~ s/(.*)/$1/s;
			$max_num++;
			{
			no warnings 'redefine';
			my $appname = $application;
			utf8::decode($appname);
			eval qq!package $package;\n#line 1 "$appname"\n!
				. $content
				or die "Compiling `$application' did not return true value\n";
			}
			$self->{handlers}{$application} = {
				handler => $handler,
				mtime => $mtime,
			};
		}
		no strict;
		return &{ $handler }(@params);
	};
	if ($@) {
		print STDERR $@;
		my $errstr = $@;
		$errstr =~ s/\n$//;
		$self->{errstr} = $errstr;
		return 500;
	}
	return $ret;
}

1;


=head1 NAME

RayApp - Framework for data-centric Web applications

=head1 SYNOPSIS

	use RayApp;
	my $rayapp = new RayApp;
	my $dsd = $rayapp->load_dsd('structure.dsd');
	print $dsd->serialize_data( $data );

=head1 INTRODUCTION

The B<RayApp> provides a framework for data-centric Web applications.
Instead of writing Perl code that prints HTML, or a code that calls
functions that print HTML, or embedding the code inside of HTML
markup, the Web applications only process and return Perl data.
No markup handling is done in the code of individual applications,
thus application code can focus on the business logic. This reduces
the presentation noise in individual applications, increases
maintainability and speeds development.

The data returned by the application is then serialized to XML and
can be postprocessed by XSLT to desired output format, which may be
HTML, XHTML, WML or anything else. In order to provide all parties
involved (analysts, application programmers, Web designers, ...) with
a common specification of the data format, data structure description
(DSD) file is a mandatory part of the applications. The DSD describes
what parameters the application expects and what data it will return,
therefore, what XML will come out of that data. The data returned
by the application in a form of hash by the Perl code is fitted into
the data structure, creating XML file with agreed-on elements.

This way, application programmers know what data is expected from
their applications and Web designers know what XMLs the
prostprocessing stage will be dealing with, in advance. In addition,
application code can be tested separately from the presentation part,
and tests for both application and presentation part can be written
independently, in parallel. Of course, this also works if you are the
sole person on the project, playing the above mentioned roles.

The system will never produce unexpected data output, since the data
output is based on DSD which is known.

=head1 CONFIGURATION

Most of the use of RayApp is expected in the Web context. This
section summarizes configuration steps needed for the Apache HTTP
server. This version of RayApp works with Apache 2.0
and mod_perl 2.0.

Assume you have a Web application that should reside on URL

	http://server/sub/app.html

The application consists of three files:

	/opt/www/app.dsd
	/opt/www/app.pl
	/opt/www/app.xsl

Yes, instead of sticking application code and presentation into one
file, we separate them completely.

Whenever a request for /sub/app.html comes, the DSD
/opt/www/app.dsd is loaded, app.pl (or app.mpl) executed and its
output serialized to HTML using app.xsl. For syntax of app.dsd, see
B<RayApp::DSD>. In the app.pl script, there has to be at least one
function, called B<handler>, and this function should return Perl hash
with data matching the DSD. The whole content of the .pl is evaluated
in a B<package> context in a B<Apache::Registry> manner, so two
B<handler> methods from different applications do not clash. In
app.xsl, there should be an XSLT stylesheet.