Note that these snapshot packages might be outdated. The latest version of these modules are avaialble from their Git repositories. Use of the Git version is always recommended.
The "Class::Registry" module defines a registry for short names of Perl classes (packages). It might be useful where there could be different sets of subclasses and a library does not know which set of subclasses should be used a priori.
Dongry is a lightweight Perl interface to MySQL databases. It provides different levels of abstractions for applications to handle database operations in easy, memorable, and safe ways without stealing full control for how and when SQL queries are executed from them.
The "Dongry::Database" module contains the implementation of the database object, which is the most fundamental and important object in Dongry. All of the features in Dongry can be directly or indirectly accessible from the database object, as described in the following sections.
In addition to the synchronous processing model, Dongry also supports the asynchronous event-based model by using the AnyEvent::DBI module as its backend. Since both modes can be switched or combined easily, you can transit one from the other, or you can partially change the processing mode, in very low cost.
+ - - - - - - - - - - - - - - - - - - - - - +
: :
: Application :
: :
+---+------------+ :
| D | Query obj. | :
| o +------------+-----------+ :
| n | Schema-aware ops. | :
| g +------------------------+------+ :
| r | Structured SQL ops. | :
| y +-------------------------------+---+ :
| | Bare SQL w/named placeholders | :
| +-----------------------------------+---+
| | Bare SQL ops. |
| +---------------------------------------+
| | Connection management |
+---+------------------+--------------------+
| | AnyEvent::DBI |
| +--------------------+
| DBI |
| DBD |
+-------------------------------------------+
| ^
| |
v |
+-------------------------------------------+
| Database |
+-------------------------------------------+
Fig. Various levels of features in DongryThe "Dongry::Type::DateTime" module defines data types for handing date and time in Dongry. They represents date and time in Perl DateTime object.
The "Dongry::Type::JSON" module defines data types for handing JSON-encoded data structure as column value in Dongry.
The "Dongry::Type::MessagePack" module defines data types for handing MessagePack-encoded data structure as column value in Dongry.
The "JSON::Functions::XS" module provides various useful functions to decode or encode JSON data. These functions are wrappers; actual conversion is enforced by the JSON::XS module.
Strictly speaking, "JSON::Functions::XS" is not just a wrapper for JSON::XS, but it adds some modifications to improve interoperability, namely:
- Support for scalar literal values According to ECMAScript 5.1, i.e. the latest JSON specification, a number, string, boolean, or null value can be recognized as valid input.
- Silent error recovery from fatal errors In many use cases of JSON parsing, the application don't have to know what is exatly wrong with the JSON input but rather the entire operation should not die just because the input is invalid. In such an application, ill-formed input is as bad as wrongly-constructed well-formed JSON data, such that it has to check the result data structure anyway to be error tolerant. Therefore this module does not raise when the input is invalid. If you'd like to distinguish parse errors from application-dependent structural errors, this module would not be a choice for you.
- Avoiding HTML XSS To prevent from HTML XSS attacks when the JSON output is poorly-labelled, or for legacy-browser users, this module replaces "<" characters in JSON output into its escaped form.
- Avoiding UTF-7 XSS To avoid UTF-7 XSS attacks for legacy-browser users, this module replaces "+" characters in JSON output into its escaped form.
- JavaScript/JSONP compatbility To improve JavaScript/JSONP compatibility, this module replaces U+2028 and U+2029 characters in JSON output, which are not allowed in JavaScript string literals, into their escaped forms.
This module defines the "simple_request" method that can be used to replace "LWP::UserAgent"'s "simple_request" method such that curl is invoked instead of usual "LWP::UserAgent"'s processing.
The "List::Ish" module provides a class for handling a list (or array) as an object.
The "Test::AnyEvent::plackup" module invokes the "plackup" command of Plack with specified options. It might be useful for testing your PSGI Web applications, or applications that requires access to some Web applications.
The "Test::Directory::Diff" module provides a test assertion to ensure that two given directories contain same content. The equivalence is determined by the "diff" command.
The "Test::Interval" module exports a test subroutine "ms_ok", which can be used to test the execution time of the specified block is less than or equal to the specified milliseconds.
The "Test::MoreMore" module provides a number of basic but useful test assertion subroutines. It is a superset of Test::More.
The "Test::X1" module defines a simple, lightweight test management framework for Test::Builder-based tests. It supports automatic naming of tests, partial execution, concurrent execution, and other useful features.
The "Wanage::HTTP" module provides a set of APIs for handling HTTP messages in server-side Web applications, namely interpretation of HTTP request message and generation of HTTP response message in response to the request, using the underlying interface for server-application communication such as CGI and PSGI.
The Wanage HTTP object provides access to data contained in HTTP request message, as well as primitive methods to generate HTTP response, while not entirely exposing historical complexness of underlying interfaces to servers. The goal of the HTTP object implementation is not completely modeling the HTTP request and response messages, but providing a set of API that is convinient and secure enough to build general-purpose Web applications. Therefore, it does not, and will not, support full HTTP protocol features.
Although it is not required, Wanage is intended to be combined with Warabe::App, a fundamental building block of server-side Web applications. Warabe defines more specific or higher-level APIs for typical Web application use cases, such as URL path interpretation, request validation, error handling, redirect response construction, and so on, which are all built on the top of Wanage's generic HTTP interface.
The Warabe::App module is the primary component of Warabe, a server-side Web application construction toolkit. It provides a number of convinient methods handling HTTP request and response in the way that would be useful for typical Web applications.
Warabe accesses the HTTP request and response through the interface provided by Wanage::HTTP. Therefore, Warabe can handle any server-application interface supported by Wanage::HTTP, including CGI and PSGI.
Warabe constructs higher-level operations for more concrete use cases on the top of APIs provided by Wanage HTTP object. It does not mean a Web application using Warabe should not access Wanage HTTP object directly - in fact, Warabe does not provide complete access to HTTP request and response, as it can be easily accessed through the HTTP object directly from the application, if necessary.
+------+ +------+ +------+ +------+ +------+
|Your |<->|Warabe|<->|Wanage|<---->|HTTP |<---->|HTTP |
| App.| +------+ | | CGI |server| HTTP |client|
| |<------------>| | PSGI | | | |
+------+ +------+ +------+ +------+
App. Common Generic TCP/HTTP
specific Web app. HTTP protocol
logic operations interpret. handlingThe "Warabe::App::Role::DateTime" module defines additional methods for handling date-time data as DateTime objects in Warabe::App API. This module is intended to be used a superclass of some subclass of Warabe::App.
The "Warabe::App::Role::JSON" module defines additional methods for handling JSON data in Warabe::App API. This module is intended to be used a superclass of some subclass of Warabe::App.
The "Warabe::App::Role::MessagePack" module defines additional methods for handling MessagePack data in Warabe::App API. This module is intended to be used a superclass of some subclass of Warabe::App.
This module provides three functions for HTTP access: "http_get", "http_post", and "http_post_data". They are in fact wrappers for LWP::UserAgent. They accept parameters that describes which resource is how retrieved and return HTTP::Request and HTTP::Response objects of the HTTP access.
It adds following features to the original LWP::UserAgent module:
- Useful functional interfaces - Avoiding use of SOCKS proxy transparently using LWP::UserAgent::Curl module - "application/x-www-form-urlencoded" support - OAuth 1.0 support
The "WebService::Microsoft::Translator" module is a wrapper for Microsoft Translator API.
The "generate-pm-package" script can be used to generate Perl module packages using a simple manifest file.