Heute geben wir Ihnen bekannt, dass ab der Version 2024.4 unsere Produkte Reports.PHP und Dashboards.PHP wesentlich aktualisiert werden. Im Rahmen dieser Aktualisierung wurde ein volles Code-Refactoring verwirklicht, die Arbeit der Komponenten-Ereignisse verbessert, der Ereginisbehandler aktualisiert, die Einstellungen des Exports hinzugefügt, und, am wichtigsten, wurde die Möglichkeit hinzugefügt, den Bericht auf der Server-Seite zu rendern und zu exportieren. Unten beschreiben wir alle wichtigsten Verbesserungen und ihre Verwendungsfälle.
Rendern und Export vom Bericht auf der Server-Seite werden maximal einfach für die Verwendung realisiert. Dafür muss man die Berichtseigenschaft engine in Modus der Arbeit auf dem Server wechseln und die schon existierten Methoden render() und exportDocument() verwenden. Dann werden diese Funktionen automatisch in Modus der Arbeit auf dem Server gewechselt, alle Ereignisse des Berichtes werden gleich wie bei der Arbeit vom Berichtsgenerator auf der Server-Seite funktionieren.
Das Beispiel des Renderns vom Bericht und Erhalten von der Dokument-Datei (oder Speichern in die Datei):
Alle oben erwähnten Probleme können durch die Aktivierung vom Kompatibilitätsmodus mit alter Version gelöst werden. Wir empfehlen diese Variante zu verwenden, aber sie ist temporär, weil in diesem Fall nicht alle Erneuerungen funktionieren können. Um den Kompatibilitätsmodus zu aktivieren, muss man nur eine Codezeile am Anfang der Datei hinzufügen.
Um die Probleme mit Namensräumen zu lösen, muss man nur alte Räume durch neue ersetzen. Man braucht keine anderen Änderungen im Code machen.
Als erste Variante können Sie die Abfragen zur separaten Datei umleiten, und in diesem Fall werden alle Ereignisse wir früher funktionieren. Dafür muss man einen Pfad zur die Datei des Behandelns von Ereignissen angeben.
Bei der Verwendung vom separaten Behandler
Als erste Variante können Sie die Tags <script></script> in der HTML-Vorlage der Seite entfernen, und in diesem Fall braucht man keine zusätzlichen Aktionen erfüllen.
Die alte Variante
Die alte Variante
Die Verwendungsbeispiele mit den letzten Scripts-Versionen befinden sich hier.
Mindestanforderungen ist auf PHP 7.0 erhoben
In neuer Version haben wir viele wesentliche Verbesserungen und Updates, über die wir unten erzählen werden, hinzugefügt. Deswegen brauchte man die Mindestanforderungen auf PHP 7.0 erheben, um auf beste Weise die ganze vorgesehene Funktionalität zu realisieren. PHP 5.6 ist die veraltete Version, und ihre Unterstützung wurde im Dezember 2018 beendet. Dementsprechend, das Upgrade auf eine aktuelle Version bietet mehrere Möglichkeiten, höhere Arbeitsgeschwindigkeit und verbesserte Sicherheit.Vereinfachte Einstellung der Scripts der Komponenten
Früher sollte man für Hinzufügen von Scripts der Komponenten ein spezielles Objekt StiJavaScript erstellen, dann ihn für bestimmte Komponente einstellen, und an einer festgelegten Stelle auf der HTML-Seite ausgeben. Derzeit braucht man nicht diese Aktionen erfüllen – die Komponenten können selbstständig ihre Scripts bereitstellen, und dafür muss man nur eine Codezeile schreiben. Außerdem, wenn es erforderlich ist, kann man die Einstellungen der Scripts direkt in der Komponente verändern.<?php
$viewer = new StiViewer();
$viewer->javascript->usePacked = false;
?>
<!DOCTYPE html>
<html>
<head>
<?php $viewer->javascript->renderHtml(); ?>
</head>Neue Weisen der Anzeige von Komponenten
Früher war nur eine Weise für die Anzeige vom HTML-Code der Komponente – der Aufruf von der Methode renderHtml(), der den ganzen für die Arbeit der Komponente erforderlichen Code an aktueller Stelle der Seite ausgibt. In neuer Version haben wir die Arbeit dieser Methode erweitert, und eine neue Methode – printHtml() für alle Komponenten hinzugefügt. Diese Methode gibt die vorbereitete HTML-Seite mit allen erforderlichen Scripts und mit dem HTML-Code aus. Diese Weise ist ja bequem, wenn man keine Seite-Vorlage braucht und die Viewer- oder Designer-Komponente auf die ganze Seite angezeigt wird.<?php
$viewer = new StiViewer();
$viewer->process();
$viewer->printHtml();
?>
Der Ereginisbehandler ist in die Komponenten eingebettet
Früher wurde der Ereginisbehandler als separates Objekt StiHandler mit ihren Einstellungen und Scripts erstellt und angepasst, und nicht mit den Komponenten (Bericht, Designer, Viewer) verbunden. Derzeit können Sie nur mit den Komponenten arbeiten – sie werden den Code des Ereginisbehandlers erstellen, anpassen und bereitstellen. Alle Eigenschaften des Behandlers können in der Komponente eingestellt werden. Für das Behandeln der Ereignisse wurde eine spezielle Methode process() hinzugefügt, die die Abfrage behandelt und, wenn es erforderlich ist, auf die Client-Seite zurückgibt. Man braucht keine zusätzlichen Aktionen erfüllen.<?php
$viewer = new StiViewer();
// $viewer->handler->encryptData = true;
$viewer->process();
?>Vereinfachter Zugang zu den Komponenten-Optionen
Früher für die Einstellung solcher Komponenten wie Viewer und Designer sollte man ein separates Objekt der Optionen erstellen, einstellen und in Komponente-Konstruktor weitergeben. Derzeit ist das Objekt der Optionen schon in den Konstruktor eingebettet, und ist es ausreichend, erforderliche Eigenschaften direkt in der Komponente zu ändern.<?php
$viewer = new StiViewer();
$viewer->options->appearance->backgroundColor = 'black';
$viewer->options->appearance->theme = StiViewerTheme::Office2022BlackGreen;
$viewer->options->toolbar->displayMode = StiToolbarDisplayMode::Separated;
$viewer->options->toolbar->showFullScreenButton = false;
?>Verbesserte Arbeit der Ereignisse
Früher wurde alle Ereignisse der Komponenten in einer Datei handler.php behandelt, und diese Lösung war nicht immer bequem, sowie hatte die Begrenzung mit gleichnamigen Ereignissen verschiedener Komponenten. In neuer Version enthält jede Komponente seinen eigenen Satz der Ereignisse. Derzeit können die Ereignisse sowohl auf der PHP-Server-Seite, als auch auf JavaScript-Client-Seite aufgerufen werden. Außerdem, wurde die Möglichkeit hinzugefügt, einige Behandler verschiedener Typen einem Ereignis zuzuweisen. Man kann auch dem Ereignis eine PHP-Funktion, den Namen der JavaScript-Funktion aus der aktuellen Seite-Vorlage, und auch JavaScript-Funktion als Code-Block zuweisen oder hinzufügen.<?php
$viewer = new StiViewer();
$viewer->onBeginProcessData = function (StiDataEventArgs $args) {
if ($args->connection == 'MyConnectionName')
$args->connectionString = 'Server=localhost;Database=test;uid=root;password=******;';
};
$viewer->onBeginExportReport->append(function (StiExportEventArgs $args) {
$args->fileName = "MyExportedFileName.$args->fileExtension";
if ($args->format == StiExportFormat::Pdf) {
/** @var StiPdfExportSettings $settings */
$settings = $args->settings;
$settings->creatorString = 'My Company Name';
}
});
$viewer->onBeginExportReport->append('beginExportReport');
$viewer->onBeginExportReport->append('
if (args.format == Stimulsoft.Report.StiExportFormat.Pdf)
args.settings.imageResolution = 200;
');
$viewer->process();
?><?php
$viewer = new StiViewer();
$viewer->handler->url = 'handler.php';
?>Die Einstellungen des Exports
In neuer Version wurden die Einstellungen des Exports für alle unterstützten Formate hinzugefügt. Die Einstellungen können in die Export-Funktion übertragen werden, auch werden die Einstellungen in die Ereignisse des Exports vom Bericht übertragen.<?php
$report = new StiReport();
$settings = new StiPdfExportSettings();
$settings->creatorString = 'My Company Name';
$settings->keywordsString = 'SimpleList PHP Report Export';
$settings->embeddedFonts = false;
$report->exportDocument(StiExportFormat::Pdf, $settings);
?>
Rendern und Export vom Bericht auf der Server-Seite
In neuer Version haben wir die Möglichkeit hinzugefügt, den Bericht auf der PHP-Server-Seite zu rendern und zu exportieren. Dafür kann man die universelle Node.js-Plattform verwendet, die unter verschiedenen Betriebssystemen funktioniert. Für die Arbeit mit dem Bericht auf der Server-Seite muss man schon installierte Plattform Node.js haben, oder spezielle Klassen für die Installation und Einstellung verwenden.<?php
$nodejs = new StiNodeJs();
// Setting the path to the executable files of the already installed Node.js
//$nodejs->binDirectory = "C:\\Program Files\\nodejs";
//$nodejs->binDirectory = "/usr/bin/nodejs";
// Setting the path to the working directory where Node.js packages will be deployed
// By default, the current Python script execution directory is used
//$nodejs->workingDirectory = '';
// Installing the Node.js package from the official website, may take some time
// If the installation fails, the function will return false
$result = $nodejs->installNodeJS();
// Installing or updating product packages to the current version, may take some time
if ($result)
$result = $nodejs->updatePackages();
// Installation status or error text from Node.js engine
$message = $result ? 'The installation was successful.' : $nodejs->error;
?>Rendern und Export vom Bericht auf der Server-Seite werden maximal einfach für die Verwendung realisiert. Dafür muss man die Berichtseigenschaft engine in Modus der Arbeit auf dem Server wechseln und die schon existierten Methoden render() und exportDocument() verwenden. Dann werden diese Funktionen automatisch in Modus der Arbeit auf dem Server gewechselt, alle Ereignisse des Berichtes werden gleich wie bei der Arbeit vom Berichtsgenerator auf der Server-Seite funktionieren.
Das Beispiel des Renderns vom Bericht und Erhalten von der Dokument-Datei (oder Speichern in die Datei):
<?php
$report = new StiReport();
$report->engine = StiEngineType::ServerNodeJS;
$result = $report->render();
if ($result) {
$document = $report->saveDocument();
// $result = $report->saveDocument('reports/SimpleList.mdc');
}
?><?php
$report = new StiReport();
$report->engine = StiEngineType::ServerNodeJS;
$result = $report->render();
if ($result) {
$result = $report->exportDocument(StiExportFormat::Text);
// $result = $report->exportDocument(StiExportFormat::Pdf, null, false, 'reports/SimpleList.pdf');
}
?>Der Modus der Abwärtskompatibilität
Wir versuchten alle Erneuerungen zu realisieren, damit alle schon existierten Projekte arbeitsfähig bleiben und der Übergang zur neuen Version ohne Probleme verwirklicht wird. Nach der Erneuerung können folgende Probleme entstehen:- die Eigenschaft oder die Methode wird als obsolet markiert;
- einige Klassen und Aufzählungen werden nicht gefunden;
- die Abfragen vom Behandler werden auf die Datei handler.php nicht geleitet;
- der HTML-Code der Komponente wird unrichtig ausgegeben.
Alle oben erwähnten Probleme können durch die Aktivierung vom Kompatibilitätsmodus mit alter Version gelöst werden. Wir empfehlen diese Variante zu verwenden, aber sie ist temporär, weil in diesem Fall nicht alle Erneuerungen funktionieren können. Um den Kompatibilitätsmodus zu aktivieren, muss man nur eine Codezeile am Anfang der Datei hinzufügen.
<?php
require_once 'vendor/autoload.php';
\Stimulsoft\StiHandler::enableLegacyMode();
?>Veraltete Eigenschaften und Methoden
In neuer Version sind einige Eigenschaften ihre Position geändert worden, und einige Methoden haben die neuen Namen für bessere Verständnis und Organisation des Codes erhalten. Die alten Namen sind gespeichert und als @deprecated markiert. Um das Problem zu lösen, muss man die alten Namen durch die neuen, die in der Beschreibung der veralteten Eigenschaft oder Methode angegeben sind, ersetzen.Namensräume
In neuer Version haben wir viele neue Klassen und Aufzählungen hinzugefügt, darum musste man die Namensräume überprüfen, um die Überquerungen auszunehmen. Unten ist die Tabelle der Übereinstimmungen der Namensräume dargestellt.| Alte Namensräume | Neue Namensräume |
|---|---|
| Stimulsoft\StiComponentType | Stimulsoft\Enums\StiComponentType |
| Stimulsoft\StiEventType | Stimulsoft\Enums\StiEventType |
| Stimulsoft\StiExportFormat | Stimulsoft\Export\Enums\StiExportFormat |
| Stimulsoft\StiExportAction | Stimulsoft\Viewer\Enums\StiExportAction |
| Stimulsoft\StiPrintAction | Stimulsoft\Viewer\Enums\StiPrintAction |
| Stimulsoft\Report\(enum classes) | Stimulsoft\Report\Enums\(enum classes) |
| Stimulsoft\Viewer\(enum classes) | Stimulsoft\Viewer\Enums\(enum classes) |
| Stimulsoft\Designer\(enum classes) | Stimulsoft\Designer\Enums\(enum classes) |
| Stimulsoft\(event classes) | Stimulsoft\Events\(event classes) |
Um die Probleme mit Namensräumen zu lösen, muss man nur alte Räume durch neue ersetzen. Man braucht keine anderen Änderungen im Code machen.
Die Abfragen des Ereignisbehandlers
In der neuen Version wurden alle Ereignisse sowie der Ereignisbehandler in die Komponenten verschoben. Derzeit werden alle Abfragen standardmäßig auf aktuelle Seite mit der Komponente statt separater handler.php-Datei des Behandelns von Ereignissen gekommen. Es gibt einige Varianten, die dieses Problem lösen können.Als erste Variante können Sie die Abfragen zur separaten Datei umleiten, und in diesem Fall werden alle Ereignisse wir früher funktionieren. Dafür muss man einen Pfad zur die Datei des Behandelns von Ereignissen angeben.
Bei der Verwendung vom separaten Behandler
<?php
$handler = StiHandler("handler.php");
?><?php
$viewer = new StiViewer();
$viewer->handler->url = "handler.php";
?><?php
$viewer = new StiViewer();
$viewer->onBeginProcessData = function (StiDataEventArgs $args) {
if ($args->connection == 'MyConnectionName')
$args->connectionString = 'Server=localhost;Database=test;uid=root;password=******;';
};
$viewer->process();
?>Die Ausgabe vom HTML-Code der Komponenten
In neuer Version wurden neue Varianten der Ausgabe vom HTML-Code der Komponenten hinzugefügt, darum wurde das Benehmen der schon existierten Methoden wesentlich verändert. Die wichtigste Veränderung besteht darin, dass die Methode renderHtml(), außer dem primären Code der Komponente, die HTML-Tags <script></script> ausgibt, was die Arbeit der schon existierten Projekte brechen kann. Es gibt einige Varianten, die dieses Problem lösen können.Als erste Variante können Sie die Tags <script></script> in der HTML-Vorlage der Seite entfernen, und in diesem Fall braucht man keine zusätzlichen Aktionen erfüllen.
Die alte Variante
<script>
<?php
$viewer = new StiViewer();
$viewer->renderHtml();
?>
</script>
<?php
$viewer = new StiViewer();
$viewer->renderHtml();
?>Die alte Variante
<?php
$viewer = new StiViewer();
?>
<script>
function showViewer() {
<?php $viewer->renderHtml(); ?>
}
</script>
<?php
$viewer = new StiViewer();
?>
<script>
function showViewer() {
<?php echo $viewer->getHtml(StiHtmlMode::Scripts); ?>
}
</script>
Bereits verfügbar für die Verwendung
Alle in diesem Artikel beschriebenen Erneuerungen sind ab der Version 2024.3.2 verfügbar und werden in diesem Moment getestet. Sie können die Skripts aus dem separaten Repository-Zweig, der bald in den Hauptzweig geladen wird, laden. Die neuen Beispiele der Arbeit sind schon vorbereitet, und die Dokumentation wird in kurzer Zeit aktualisiert werden. Wir sind immer froh, die Ratschläge und Kommentare über die Arbeit unserer Softwares zu erhalten.Die Verwendungsbeispiele mit den letzten Scripts-Versionen befinden sich hier.