Problem
Der loadModule()-Mechanismus in class.application_core.php (Zeile 223-260) unterstuetzt bereits das _custom.php-Pattern: Wenn eine Datei www/pages/<modul>_custom.php mit einer Klasse <Modul>Custom extends <Modul> existiert, wird die Custom-Klasse bevorzugt geladen. Dieses Pattern wird fuer Core-Klassen bereits genutzt:
- `www/lib/class.erpapi_custom.php` (erpAPICustom)
- `www/lib/class.remote_custom.php` (RemoteCustom)
- `www/lib/class.printer_custom.php` (PrinterCustom)
Der Player (`phpwf/class.player.php`, Zeile 175-178) laedt Page-Controller allerdings ohne diesen Mechanismus:
```php
include_once(dirname(DIR)."/www/pages/".$module.".php");
$constr = strtoupper($module[0]) . substr($module, 1);
if(class_exists($constr))$myApp = new $constr($this->app);
```
Dadurch ist es nicht moeglich, Page-Controller update-sicher zu erweitern — man muss die Original-Datei aendern.
Loesung
Zwei zusaetzliche Zeilen im Player, analog zu `loadModule()`:
- Nach dem `include_once` der Basis-Datei: Pruefe ob `_custom.php` existiert und inkludiere sie
- Bei der Instanziierung: Bevorzuge die Custom-Klasse
```php
include_once(dirname(DIR)."/www/pages/".$module.".php");
// NEU: Support _custom.php extension pattern
$customFile = dirname(DIR)."/www/pages/".$module."_custom.php";
if(file_exists($customFile)) {
include_once($customFile);
}
$constr = strtoupper($module[0]) . substr($module, 1);
$constrCustom = $constr . 'Custom';
if(class_exists($constrCustom)) {
$myApp = new $constrCustom($this->app);
} elseif(class_exists($constr)) {
$myApp = new $constr($this->app);
}
```
Nutzen
- Update-sichere Erweiterung jedes Page-Controllers (Ticket, Adresse, Auftrag, etc.)
- Konsistenz mit dem bestehenden `loadModule()`-Pattern
- Kein Breaking Change — ohne `_custom.php` Datei aendert sich nichts
Anwendungsbeispiel
```
www/pages/ticket.php -> class Ticket { ... }
www/pages/ticket_custom.php -> class TicketCustom extends Ticket { ... }
```
`TicketCustom` kann einzelne Methoden ueberschreiben (z.B. `ticket_edit()`) ohne `ticket.php` zu aendern. Bei einem OpenXE-Update bleibt `ticket_custom.php` erhalten.
Problem
Der
loadModule()-Mechanismus inclass.application_core.php(Zeile 223-260) unterstuetzt bereits das_custom.php-Pattern: Wenn eine Dateiwww/pages/<modul>_custom.phpmit einer Klasse<Modul>Custom extends <Modul>existiert, wird die Custom-Klasse bevorzugt geladen. Dieses Pattern wird fuer Core-Klassen bereits genutzt:Der Player (`phpwf/class.player.php`, Zeile 175-178) laedt Page-Controller allerdings ohne diesen Mechanismus:
```php
include_once(dirname(DIR)."/www/pages/".$module.".php");
$constr = strtoupper($module[0]) . substr($module, 1);
if(class_exists($constr))$myApp = new $constr($this->app);
```
Dadurch ist es nicht moeglich, Page-Controller update-sicher zu erweitern — man muss die Original-Datei aendern.
Loesung
Zwei zusaetzliche Zeilen im Player, analog zu `loadModule()`:
```php
include_once(dirname(DIR)."/www/pages/".$module.".php");
// NEU: Support _custom.php extension pattern
$customFile = dirname(DIR)."/www/pages/".$module."_custom.php";
if(file_exists($customFile)) {
include_once($customFile);
}
$constr = strtoupper($module[0]) . substr($module, 1);
$constrCustom = $constr . 'Custom';
if(class_exists($constrCustom)) {
$myApp = new $constrCustom($this->app);
} elseif(class_exists($constr)) {
$myApp = new $constr($this->app);
}
```
Nutzen
Anwendungsbeispiel
```
www/pages/ticket.php -> class Ticket { ... }
www/pages/ticket_custom.php -> class TicketCustom extends Ticket { ... }
```
`TicketCustom` kann einzelne Methoden ueberschreiben (z.B. `ticket_edit()`) ohne `ticket.php` zu aendern. Bei einem OpenXE-Update bleibt `ticket_custom.php` erhalten.