Codeoptimierung anhand der CONTENIDO ConLite-Edition

Bei den Optimierungen an unserer ConLite-Edition der 4.8er Serie von CONTENIDO versuchen wir auch ein wenig im Core-Code aufzuräumen und zu Optimieren. Über die Zeit und durch viele unterschiedliche Entwickler haben sich die eine oder andere Baustelle aufgetan bei der sich ein Refactoring oder ein Code Cleanup anbietet.

Am Beispiel der Module-Klasse und deren Verwendung im Core möchte ich hier mal ein wenig davon zeigen.

Im CONTENDIO Core gibt es eigentlich für fast jede DB-Tabelle von CONTENIDO auch eine entsprechende Klasse die auf der genericdb.php beruht, bzw von den dort enthaltenen Klassen für das Item- und das ItemCollection-Objekt abgeleitet werden. So auch die Klassen Module und ModuleCollection die für das Handling der Module im Core zuständig sind. Mit Hilfe dieser Klassen werden auch die Inhalte für In- und Output der Module aus der DB gelesen, bzw. beim Speichern geschrieben.

Schaut man aber nun mal in einer aktuellen 4.8.15 in den Bereichen bei denen der Output oder der Input eines Modules benötigt wird, so ist schon auffällig das dort nicht konsequent mit den Klassen gearbeitet wird. Dieses ist aber z.B. in Bezug auf die Wartungsfreundlichkeit der Anwendung suboptimal, denn werden nun Änderungen an der DB oder am Handling gemacht, müssen diese an mehreren Stellen eingepflegt werden. Ein Beispiel? Kein Problem, bitte schön (Auszug: include.pretplcfg_edit_form.php ab Zeile 96) :

if ($value != 0) {

                $sql = "SELECT
                            *
                        FROM
                            ".$cfg["tab"]["mod"]."
                        WHERE
                            idmod = '".Contenido_Security::toInteger($a_d[$cnumber])."'";

                $db->query($sql);
                $db->next_record();

                $input = $db->f("input")."\n";

				global $cCurrentModule;
				$cCurrentModule = $db->f("idmod");

                $modulecaption = sprintf(i18n("Module in Container %s"), $cnumber);
                $modulename    = $db->f("name");

Mal abgesehen davon das man den Query (‚SELECT * ‚) noch optimieren könnte, bietet sich hier die Verwendung der Module-Klassen einfach an, zumal man damit das ganze übersichtlicher und kompakter gestalten kann.

Das folgende Beispiel habe ich heute für das nächste Release der ConLite-Edition im SVN eingecheckt.

if ($value != 0) {
            global $cCurrentModule;

            $oModule = new cApiModule((int) $a_d[$cnumber]);
            $input = $oModule->get("input")."\n";
            $cCurrentModule = $oModule->get("idmod");
            $modulecaption = sprintf(i18n("Module in Container %s"), $cnumber);
            $modulename    = $oModule->get("name");
            unset($oModule);

Sieht doch schon viel freundlicher und aufgeräumter aus. 🙂

Unabdingbar für solche CleanUps und Optimierungen ist aber ein gewisses Maß an KnoffHoff des Cores von CONTENIDO und eine gute Grundkenntnis von PHP und OOP. Oft geht sowas erst nach einer zeitintensiven Beschäftigung mit dem Script. Grundsätzlich sollte man in meinen Augen immer versuchen ein gutes Mittelmaß zwischen schnellem und wartungsfreundlichem Code zu finden. An dieser Stelle z.B. ist eventuell die Verwendung der Klasse etwas langsamer, aber durch die wiederkehrende Verwendung auch an anderer Stelle und die dadurch einfachere Wartung an nur einer Stelle um ein vielfaches sinnvoller.

Soviel für heute zum Thema Codeoptimierung und vielen Dank für eure Aufmerksamkeit.
to be continued…