Many web applications require a framework for validating email addresses of registered users. This module provides a basic toolkit for the common routines.
It stores a JSON object file in the spool directory, and retrieves this when the code is provided.
The verification routines are intended to be usable from web-based, email-based, and other means of verification.
Receipt printers are often not controlled through print spool frameworks in point of sale environments. This is for a number of reasons including the need for highly responsive printers which often control other hardware, such as cash drawers, through themselves. For this reason, one would typically echo or read commands directly to the device port.
PerlPOS::RPI is intended to provide a DBI-like interface (in the sense of commonality across lower level components) to receipt printers in point of sales environments. It is intended to support both integration with command-line printing operations (like lp, lpq) and direct to port printing. The former would typically occur in restaurant settings where kitchen printers might require CUPS to manage queuing, while the latter would be more typical at the actual point of sale, particularly where the cash drawer is controlled through the printer (using CUPS in such an environment would mean, effectively, waiting for a print job to spool so you could get into a cash drawer).
The design is modular. Modes, and drivers are modular. Command sets are also intended to be modular, but printer drivers may override parts or all of them since there may be incompatibilities between command sets. Commands are not used for preprocessing input, but only for basic printer functions like activating the autocut bar. Command modules are intended to be eventually useful for other things as well, such as preprocessing, but that would not be used by these drivers here.
I am intending to put:
print drivers in PerlPOS::RPD::*
mode drivers in PerlPOS::RPM::* (will support CUPS and raw first)
command sets in PerlPOS::RPC::* (ESC/POS offered by first)
This module is intended to be something like a unified interface framework for point of sale customer-facing pole displays.
That we can use standard reading and writing to the file to determine status or write output
That all drivers have relatively simple needs (namely to write to the display, to clear it, and so forth)
The driver is responsible for handling escaping of special characters in the print_line input. Newlines are not valid characters to send in a print_line.
PGObject::Simple::Role arose out of a need for more formalized object structures than the quick and dirty approach (released in PGObject::Simple) required. PGObject::Simple::Role thus gives you the quick and flexible mapping of stored procedures to application objects as a Moose role, giving you the power of that object system as well.
This module implements essentially a wrapper around PGObject::Simple. The internals are not the same. Both the enumerated argument (call_procedure) and mapped argument (call_dbmethod) APIs are supported.
This is based on code developed for the forthcoming LedgerSMB 1.4. It is thus not an approach we have used extensively in production for many users yet, but it will get there.
PGObject::Simple a top-half object system for PGObject which is simple and inspired by (and a subset functionally speaking of) the simple stored procedure object method system of LedgerSMB 1.3. The framework discovers stored procedure APIs and dispatches to them and can therefore be a base for application-specific object models and much more.
PGObject::Simple is designed to be light-weight and yet robust glue between your object model and the RDBMS's stored procedures. It works by looking up the stored procedure arguments, stripping them of a conventional prefix (by default 'in_', and mapping what is left to object property names. Properties can be overridden by passing in a hashrefs in the args named argument. Named arguments there will be used in place of object properties.
This system is quite flexible, perhaps too much so, and it relies on the database encapsulating its own logic behind self-documenting stored procedures using consistent conventions. No function which is expected to be discovered can be overloaded, and all arguments must be named for their object properties. For this reason the use of this module fundamentally changes the contract of the stored procedure from that of a fixed number of arguments in fixed types contract to one where the name must be unique and the stored procedures must be coded to the application's interface. This inverts the way we typically think about stored procedures and makes them much more application friendly.
PGObject contains the base routines for object management using discoverable stored procedures in PostgreSQL databases. This module contains only common functionality and support structures, and low-level API's. Most developers will want to use more functional modules which add to these functions.
The overall approach here is to provide the basics for a toolkit that other modules can extend. This is thus intended to be a component for building integration between PostgreSQL user defined functions and Perl objects.
Because decisions such as state handling are largely outside of the scope of
this module, this module itself does not do any significant state handling.
Database handles (using DBD::Pg 2.0 or later) must be passed in on every call. This decision was made in order to allow for diversity in this area, with the idea that wrapper classes would be written to implement this.
This module provides what are essentially bottom-half services for other modules which create developer-friendly API's. One would do well to see this as the "database-facing" piece of a framework for integrating stored procedures in a flexible and yet robust manner.