Acme-ReturnValue

 view release on metacpan or  search on metacpan

LICENSE  view on Meta::CPAN

2. You may apply bug fixes, portability fixes and other modifications derived
from the Public Domain or from the Copyright Holder. A Package modified in such
a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided that
you insert a prominent notice in each changed file stating how and when you
changed that file, and provided that you do at least ONE of the following:

  a) place your modifications in the Public Domain or otherwise make them
     Freely Available, such as by posting said modifications to Usenet or an
     equivalent medium, or placing the modifications on a major archive site
     such as ftp.uu.net, or by allowing the Copyright Holder to include your
     modifications in the Standard Version of the Package.

  b) use the modified Package only within your corporation or organization.

  c) rename any non-standard executables so the names do not conflict with
     standard executables, which must also be provided, and provide a separate
     manual page for each non-standard executable that clearly documents how it
     differs from the Standard Version.

t/interesting.t  view on Meta::CPAN

    is($data->{package},'WWW::Shorten::TinyClick','package');
    is($data->{value},'0','interesting: 0');
}

done_testing();

# invalid returns:
# Test::MockTime
# SpamMonkey::Config

# wrong postives
# RayApp

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

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

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

/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.

If you issue a request for /sub/app.xml, the presentation
postprocessing is skipped and you get the XML output -- ideal for
debugging.

If the app.html file exists in the filesystem, it "overrides" any
attempts to is generate dynamic content, and the file is returned.
Likewise, if there is a app.xml file in the filesystem and there is
a request for app.xml, the XML file is returned. If there is app.xml
but no app.html and a request for app.html comes, the app.xml is
serialized using app.xsl. So B<RayApp> can be used not only for fully
dynamic sites, but also as a XSLT processor.

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

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 (