| Name : perl-CGI-XMLApplication
| |
| Version : 1.1.4
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : 3.1
| Date : 2015-06-22 07:24:50
|
| Group : Development/Libraries/Perl
| Source RPM : perl-CGI-XMLApplication-1.1.4-3.1.src.rpm
|
| Size : 0.08 MB
| |
| Packager : (none)
| |
| Summary : Object Oriented Interface for CGI Script Applications
|
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 the XML::LibXML manpage/ the
XML::LibXSLT manpage module package for content deliverment.
As well CGI::XMLApplication is designed to support project management on
code level. The class allows splitting 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
_param()_.
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 *events*, which
is usually the code abstraction of a click of a submit button or an image,
CGI::XMLApplication implements a simple event system, that keeps event
related code separated from other events.
Therefore, a final application class is not meant 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 *events* 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.
*Pay attention: In this Document XML-DOM means the DOM of XML::LibXML and
not XML::DOM!*
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-C/openSUSE_Tumbleweed/noarch |
