Php

Architecture

A schematic diagram of Genero Report Writer for Php

Scalability

A schematic diagram illustrating the distributed nature of Genero Report Writer for Php

Highlights

Detailed feature overview

Customizing the presentation

  • Easy to use, WYSIWYG editor,
  • Schema based, type-safe editing
  • Avoids run-time errors caused by failing string conversions,
  • Compile-time impact analysis,
  • Lists issues in a report design caused by changes to the schema. This feature is of  particular importance for end users that have customized or created their own report designs. Upon receipt of a software update they can check their reports against the new schemas shipped with the update to detect and fix any issues before making the update operational,
  • Batch upgrades.  A command line tool is available to perform batch upgrades of report design files from one version of the software to another,
  • Batch updates and software-assisted issue resolution in the report designer. A command line tool is available to update the report design files in cases where the schemas may have changed (e.g. during an application update and the end user’s site). The update algorithm is optimal in the sense that it finds a minimal patch so that in the general case no manual intervention is required. In the rare case that parts of a schema have been removed or renamed users are assisted in resolving the issues in form of issue list that is persistently stored with the report design file until all issues have been resolved.

Data production and presentation separated

  • Data stream and document formatting are separate,
  • Multiple presentations per data source,
  • Defines a clear interface between application vendors who are responsible for providing the data sources and their associated schemas and users who customize or add presentations to them.

Structured data source

  • Process level interface as opposed to accessing the database directly,
  • Less sensitive to database changes. Process level messages shield users from details of the database and allow application vendors to change the database schema without breaking customized or self made reports,
  • Prevents replication of business rules in report designs. By accessing “cooked” data, users are shielded from the need to know details on how things are stored in the database. It avoids the replication of central business logic in the report designs (e.g. rules about which address is actually used as a billing address of an invoice when there are multiple choices in the database),
  • Support for structured data as opposed to flat record sets returned by SQL queries. The data behind sophisticated reports such as invoices or delivery can rarely be represented as a flat list of records. The natural representation is a structured message allowing for arbitrary nested lists of different records. Using “sub reports” as in many ad hoc reporting tools is not an adequate solution since it adds unnecessary complexity and typically reverses the network communication causing performance problems due to network latency,
  • Novel, serial, graphical matching and transformation language. Conceptually similar to XSL-T, the RTL transformation language is limited in the type of transformations it can do (e.g. no recursion), but can be represented graphically. It works for documents of arbitrary size.

Performance & scalability

  • Single pass, unidirectional processing pipe. Since network latency can be regarded as a resource that does not scale it is important to avoid reversing the communication direction during a job. The engine can be used in a distributed environment with very high roundtrip times and low bandwidth without noticeable decrease in performance,
  • Serial processing of arbitrarily sized documents.
    • Thousands of pages, low and constant memory,
    • Distributed processing and multiple server option. The multi tier option allows to offload the report rendering to one or more separate machines leaving only the data source message creation for the server.

Sophisticated layout engine

  • Pixel exact positioning,
  • Relative positioning vertical and horizontal,
  • Content propagation vertical and horizontal,
  • Multicolumn layout,
  • Tabular layout,
  • Pivot tables,
  •  Sub-reports,
  • Sophisticated headers and footers,
  • Sophisticated page breaking,
  • Label printing on varying media. The report design contains the description of a single label abstracting from the actual layout on the media removing the need to change the report design for different label printers or different label sheets,
  • Running totals in headers and footers,
  • Page n of m in headers and footers while retaining serial processing,
  • Self-layouting business graphs,
  • Large number of natively implemented bar codes,
  • Bitmap and SVG images. The lean scalable vector graphics (also those of other origin such as bar codes and business graphics) are preserved in all formats that support vector drawing such as PDF, browser or printer output. In all other formats they are rendered into bitmaps.

APIs

  • Design time API
    • API for schema introspection,
    • API for report design file introspection and generation,
    • API for template based report design generation,
    • API for pivot table configuration.
  • Run time API
    • Data level API,
      • Selection of source,
      • Configuration of localization,
      • Recommend JAXB for schema generation and marshalling,
    • Document level API,
      • Selection of design,
      • Configuration of page characteristics,
      • Configuration of label layout,
    • Device level API
      • Selection of device (e.g. PDF, server printer, client printer, ..),
      • Device specific configuration (e.g. Paper tray selection of printer).

Report viewers and devices

  • Browser based report viewer
    • Low band-width,
    • 100% pixel exact rendering,
    • Uses cacheable WOFF fonts and SVG vector graphics,
    • Streaming capable for immediate rendering of huge reports,
    • Fast, random navigation in huge documents,
    • Bookmarkable and shareable reports
  • Native report viewer
    • Very fast processing, low, nearly fixed memory consumption,
    • 100% pixel exact rendering using embedded fonts,
    • Streaming capable for immediate rendering of huge reports,
    • Fast, random navigation in huge documents,
    • Support for silent printing
      • Viewer not visible,
      • Selecting printer via server API,
      • Configuration of printer via server API (e.g. selecting paper source),
  • Server side printing
    • Serial processing if supported by the operating system,
    • Programmatic control via IPP properties
  • File generation
    • PDF,
    • RTF (MS-Word),
    • XLS/XLSX (MS-Excel),
    • Postscript,
    • SVG

Run time localization

  • Single design for multiple languages. Primitives are provided to translate strings and format data in locale specific manner individually per document at runtime. Layouts can be defined that handle the resulting differences in text size well.
  • Asian language and alternative writing modes support.
  • Efficient handling of Asian fonts.

Templates

  • Support for self written document templates,
  • Type-safe unrolling of field lists and placeholders,
  • Support for complexly structured data sources.

Maintenance

  • Human readable and version controllable file formats,
  • Type safe report design editing,
  • Compile time impact analysis after changed to data sources,
  • Sophisticated report design upgrade algorithm (Similar to diff/patch).
    • 100 % tolerant to addition of fields and structures,
    • Good tolerance to removal,
    • Reports conflicts and allows for manual correction.

Data source generation

  • Graphical data source generator,
  • Creation of code for XML generation,
  • Creation of schema,
  • Type-safe unrolling of field lists and placeholders,
  • Support for complexly structured data sources.

Database support

All of the industry’s leading databases are supported:

  • DB2
  • Informix
  • MS SQL Server
  • MySQL
  • Oracle
  • PostrgreSQL

Getting started

Create data model from the database

In this example we use the dataset designer to define the data object for the report
saleslist.4rp

Generate schema and PHP code

GBuilding the data model in the project manager creates the XML schema and the PHP code.
Graphical reports are designed based on a XML schema that matches the data to be serialized.

The schema file Accounts.xsd for the sample program reads as follows:

 <?xml version="1.0" encoding="utf-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
     <xs:element name="Accounts">
         <xs:complexType>
             <xs:sequence>
                 <xs:element name="Accounts" minOccurs="0" maxOccurs="unbounded">
                     <xs:complexType>
                         <xs:sequence>
                             <xs:element name="account_userid" type="xs:string"></xs:element>
                             <xs:element name="account_firstname" type="xs:string"></xs:element>
                             <xs:element name="account_lastname" type="xs:string"></xs:element>
                         </xs:sequence>
                     </xs:complexType>
                 </xs:element>
             </xs:sequence>
         </xs:complexType>
     </xs:element>
 </xs:schema> 

The PHP code for the sample program reads as follows:

Accounts_main.php

set_include_path(get_include_path().PATH_SEPARATOR.getenv("PHPINCLUDEDIR"));
require_once 'Accounts_lib.php';
require_once 'libgrerunners.php';

$dsn='sqlite:officestore.db';
$pdo = new PDO($dsn, '', '');
$pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

if ($argc == 1) {
  $designFile = 'Accounts.4rp';
} else {
  $designFile = getcwd().DIRECTORY_SEPARATOR.$argv[1];
}
$greRunnerObj = new GreRunner($designFile, 'Accounts');
$greRunnerObj->selectDevice('PDF');
$greRunnerObj->selectPreview(true);
$greRunnerObj->configureDistributedProcessing("127.0.0.1",7000);
try {
  $greRunnerObj->run(new Accounts($pdo));
} catch (UserAbortException $e) {
} catch (GreRuntimeException $e) {
     echo "GreRuntimeException: ".$e->getMessage()."\n";
} catch (Exception $e) {
     echo "Exception: ".$e->getMessage()."\n";
}

Accounts.php :

require_once 'libgretypes.php';
require_once 'libgrerunners.php';

class Accounts extends SerializableRecord
{
  public $account_userid;
  public $account_firstname;
  public $account_lastname;
  
  private $pdo;
  private $query;

  public function __construct($pdo)
  {
    $this->pdo = $pdo;
    $this->query = '
  SELECT  account.userid as account_userid,
          account.firstname as account_firstname,
          account.lastname as account_lastname
  FROM    account
  WHERE      1=1';
  }

  public function serialize(GreXMLConnector $greXmlConnector)
  {
    $stmt = $this->pdo->prepare($this->query);
    $stmt->execute();
    $row = $stmt->fetch();
    
    while ($row !== false) {
      $this->setValues($row);
      
      parent::serialize($greXmlConnector);
      $row = $stmt->fetch();
    }
  }

  protected function serializeChildren(GreXMLConnector $greXmlConnector)
  {
  }
}

Design report from schema

Design the report using Report Designer. Choose your report template, associate the triggers and populate the report with data picked from the data view.

The image below shows “Accounts.4rp” created in the Report Designer:

saleslist.4rp

Run report

The code to run the report was generated in Accounts_main.php. It selects the report design and configures the output.

Selecting the report design

if ($argc == 1) {
  $designFile = 'Accounts.4rp';
} else {
  $designFile = getcwd().DIRECTORY_SEPARATOR.$argv[1];
}
$greRunnerObj = new GreRunner($designFile, 'Accounts');

Configuring the output
Selecting PDF output

$greRunnerObj->selectDevice('PDF');

Serializing the model
Using PHP reflection to serialize the data.

parent::serialize($greXmlConnector);

Resulting Report

Executing the above code produces the following PDF document:

saleslist.4rp