Programmierstil Datenstruktur Input- u Outptbereich v Modul?

[knb]

Hallo, ich frage mich, was der beste Weg ist, eine Datenstruktur so in Contenido abzulegen, dass sie sowohl im Input- als auch im Outputbereich eines Moduls zur verfügung steht.

Die Struktur ist read-only und sieht ungefähr so aus (ein Array aus Arrays):

Code: Alles auswählen

$html_content = array(
    1 => array(
        "section_title" => mi18n("Description"),
        "cms_var"       => "CMS_VAR[1]",
        "cms_value"     => "CMS_VALUE[1]",
        "cms_html"      => "CMS_HTML[1]",
        "cms_var2"      => "CMS_VAR[201]",
        "cms_value2"    => "CMS_VALUE[201]"
    ),
    2 => array(
        "section_title" => mi18n("Location"),
        "cms_var"       => "CMS_VAR[2]",
        "cms_value"     => "CMS_VALUE[2]",
        "cms_html"      => "CMS_HTML[2]",
        "cms_var2"      => "CMS_VAR[202]",
        "cms_value2"    => "CMS_VALUE[202]"
    ),
    3 => array(
        "section_title" => mi18n("Project Start and End"),
        "cms_var"       => "CMS_VAR[3]",
        "cms_value"     => "CMS_VALUE[3]",
        "cms_html"      => "CMS_HTML[3]",
        "cms_var2"      => "CMS_VAR[203]",
        "cms_value2"    => "CMS_VALUE[203]"
    ),
...
    8 => array(
        "section_title" => mi18n("Current State"),
        "cms_var"       => "CMS_VAR[8]",
        "cms_value"     => "CMS_VALUE[8]",
        "cms_html"      => "CMS_HTML[8]",
        "cms_var2"      => "CMS_VAR[208]",
        "cms_value2"    => "CMS_VALUE[208]"
    ),
...
);
 

Sollte man so was irgendwo global erklären? (config.local.php?) sollte man eine neue Klasse im Root Directory von Contenido anlegen? Oder im inc verzeichnis ? oder im includes Verzeichnis?
Oder ein eigenes Konfigfile im Verzeichnis des Mandanten anlegen? Wenn ja, in welchem Dateiformat?

Ich habe die Struktur zur Zeit zweimal deklariert, im Input und im Outputbereich. Das ist das einfachste, aber auch redundant.

Ich programmiere nur sporadisch Module, und hier im Forum findet man z.T abstruse Lösungen (meist mit 2 fach Deklaration wie bei mir) ... da dachte ich mir, mal einen eigenen Thread aufmachen. Auch wenn es irgendwann schon mal diskutiert worden sein sollte.

[HerrB]

Ähm, hä? Was genau möchtest Du machen?

CMS_VAR und CMS_VALUE dienen der Übergabe von Informationen aus der Konfiguration (Input) in die Ausgabe (Output -> CMS_VALUE).

CMS_HTML sollte nur in der Ausgabe zur Verfügung stehen.

Gruß
HerrB

[knb]

Was ich wissen will, steht da doch. Ich will eine etwas komplexere Read-Only Datenstruktur benutzen die sowohl im Input- als auch im Outputbereich zur verfügung steht. Wozu ich das Modul verwende tut hier gar nichts zur Sache.

Um die Sache einfacher zu machen schreibe ich das Beispiel mal um, stellen wir uns also vor die Struktur sieht so aus (lassen die CMS* weg weil die wirklich gar nichts mit dem Problem zu tun haben):

Code: Alles auswählen

$mystruct  = array(
    1 => array(
        "s" => mi18n("Description"),
        "c"       => "VR[1]",
        "v"     => "VX[1]",
        "h"      => "CM[1]",
        "c2"      => "VR[201]",
        "v2"    => "VX[201]"
    ),
    2 => array(
        "s" => mi18n("Location"),
        "c"       => "VR[2]",
        "v"     => "VX[2]",
        "h"      => "CM[2]",
        "c2"      => "VR[202]",
        "v2"    => "VX[202]"
    ),
    3 => array(
        "s" => mi18n("Project Start and End"),
        "c"       => "VR[3]",
        "v"     => "VX[3]",
        "h"      => "CM[3]",
        "c2"      => "VR[203]",
        "v2"    => "VX[203]"
    ), 

Angenommen die Struktur $mystruct wird zur Compilezeit manuell geändert, also z.B. die Strings in den mi18n() Aufrufen umformuliert, neue Elemente hinzugefügt oder umorganisiert. Bisher muss ich das zweimal machen (da -wie gesagt- die Struktur im Input als auch im OutputBereich deklariert ist. )
Diese doppelte Datenhaltung nervt und ist auch fehleranfällig. Es kann sein dass die Struktur nach Änderungen leicht unterschiedlich vorliegen und zu merkwürdigen Bugs führen wenn das Modul genutzt wird.

Nur deshalb wurde in der Originalstruktur CMS_HTML wird auch im Input eingetragen, (aber im Code nicht genutzt).

[MichFress]

Aussagen wie "steht da doch" werden etwas schwammig, wenn man sich fragt, was denn "zur Compile-Zeit manuell ändern" bedeuten soll.. ,-)

Hilft es dir denn nicht, wenn du dein Array in config.local.php (oder sonstwo) speicherst? hast du das schonmal ausprobiert? Reicht dir diese Lösung? Dort kannst du zwar nicht auf mi18n oder CMS-Typen zurückgreifen, aber so, wie ich dich verstanden habe, geht es dir ja darum, dieses Array nicht doppelt pflegen zu müssen...

[stese]

problem 1: mi18n funktioniert nur direkt im modul - sprich sobald du es auslagerst greift es nicht mehr.

lösungsweg wie ich ihn mir vorstellen könnte wäre folgender:
die ganze zuweisungsgeschichte wie du es dargestellt hast würde ich in den input bereich verlagern. danach mittels serialize einen string draus machen und in einer seperaten variable an den output bereich übergeben. im output bereich dröselst du es wieder auf und schon hast du die daten wieder bei der hand.

allerdings schön ist was anderes. ich als freund der durchaus komplexeren programmierung ;) würde ja nen leicht anderen weg gehen.

ich habe eine einstellungsform (von mir aus im input) der speichert alle daten im feinen xml format - dieses format legst du irgendwo ab (von mir aus statisch als flat file oder dynamisch in irgend nem db feld) - die zuweisung/zugriff erfolgt halt über irgendwelche extern liegenden klassen

wenn du nun an die infos kommen willst, parst du einfach das das xml.
bei der gelegenheit muss ich es auch mal erwähnen: ich finde die datenhaltung von typo3 ziemlich geil. jede datenbank-tabelle/feld etc wird in xml gespeichert - somit sind manipulationen viel leichter möglich - gerade was so kleines standard zeugs anbelangt ist man somit extrem schnell und man kann super so nen extension kickstarter programmieren wo auch idioten sich ne db struktur zusammenklauben können - das nur mal so am rande. ach ja: ich liebe xml ;) schon allein weil ich die daten auch so knorke in flash nutzen kann, geht bei mir sehr viel über xml

[knb]

Schön und gut .... erstmal danke fürs Brainstorming.

Bitte hier nicht jedes wort auf die Goldwaage legen .... mit "zur Compilezeit manuell geändert" meine ich "beim Arbeiten im Backend, bevor man es 'kompiliert' ... also den Inputbereich-Code händisch ändert und abspeichert". Der Syntaxcheck des Moduls ist doch so eine Art Kompilierung. Php ist doch keine rein interpretierte Sprache sondern ein .php-Script wird von php.exe stets als ganzes eingelesen, geprüft und wohl auch optimiert....eben "kompiliert".

Vieleicht sollte man von "Code-Editierzeit" sprechen, im gegensatz zur "(Artikel-)Konfigurationszeit..." also wenn das Modul im Einsatz ist (auch beim Arbeiten im Backend)


Die Struktur in XML abzulegen ist mir eigentlich zu aufwändig. Vielleicht wäre JSON format angebracht? Wie speichern/parsen?

Ausserdem hatte ich eingangs noch gefragt *wo* es im Filesystem am besten abzulegen sei. Ein Standard Ordner für sowas gibt es anscheinend noch nicht. Der Ordner <mandantenname>/templates ist eigentlich für Modultemplates-HTML-Schnipsel vorgesehen.

config.local.php ist eigentlich nicht der richtige Ort da die Struktur nicht mandantenweit zu sehen sein soll.
Ordner <mandantenname>/includes wäre auch ein Kandidat.

Das mit dem mi18n() war mir auch klar, dass das im eval()'d code möglw nicht richtig funktioniert. Aber die mi18n() Aufrufe ermöglichen trotzdem das spätere bequeme Herausfiltern der zu übersetzenden Strings, daher habe ich das mi18n() drin gelassen.


PS Die Struktur dient zum dynamischen Erzeugen von > 20 Checkboxen im Input bereich, und im Outputbereich zum dynamischen Generieren von CMS_HTML (+ mehr) .. in beliebiger Reihenfolge, selektiv ... vielleicht poste ich den Modulcode irgendwann, wenn's fertig ist.

[stese]

dann leg dir die datei in [mandant]/includes ab. dort gehört sowas eigentlich rein, wenn es nicht mandantenübergreifend ist. wenn es mandantenübergreifend ist, kann ich mir das sogar ziemlich gut als Plugin vorstellen.

[knb]

ich mach jetzt im inputbereich und im outputbreich je ein

Code: Alles auswählen

$html_content = include "../<MANDANT>/includes/struct_for_module_my_obfuscated_filename.php";

und in der Datei steht

Code: Alles auswählen

<?php
/*
 * $Id$
 * 
 * 
 * This file is include()d in a contenido module.
 * 
 * 
 */
 
$html_content = array(
    1 => array(
        "section_title" => i18n("Description"),
        "cms_var"       => "CMS_VAR[1]",
        "cms_value"     => "CMS_VALUE[1]",
        "cms_html"      => "CMS_HTML[1]",
        "cms_var2"      => "CMS_VAR[201]",
        "cms_value2"    => "CMS_VALUE[201]"
    ) 
...
    9 => array(
        "section_title" => i18n("Homepage"),
        "cms_var"       => "CMS_VAR[9]",
        "cms_value"     => "CMS_VALUE[9]",
        "cms_html"      => "CMS_HTML[9]",
        "cms_var2"      => "CMS_VAR[209]",
        "cms_value2"    => "CMS_VALUE[209]"
    )
); 
 
return $html_content;  
 
 
?>

[stese]

dafür gibts sogar nen schöneren include befehl:

Code: Alles auswählen

cInclude("frontend", "includes/struct_for_module_my_obfuscated_filename.php");

[knb]

Danke für den Tip.
Dazu muss ich aber am Anfang der includierten Datei sagen

Code: Alles auswählen

global $html_content;

statt

Code: Alles auswählen

return $html_content;

am Ende.

Was ist nun besser? Mein Eclipse gibt mir wegen des include eine Warnung aus. Bei cInclude passiert natürlich nichts. Ich glaube mit dem global kann ich leben. Auch wenn man dann als Modulnutzer genau wissen muss wie die Struktur heisst.

[HerrB]

IMHO sollte es reichen,

cInclude ...

aufzurufen, damit $html_content die gewünschte Struktur enthält (also nicht $html_content = cInclude...). Das global sollte nur dann benötigt werden, wenn das cInclude innerhalb einer Funktion erfolgt.

Siehe http://www.php.net/manual/de/function.include.php.

Sicherheitshalber würde ich an den Anfang der Include-Datei noch ein unset($html_content); setzen.

Gruß
HerrB

[knb]

Siehe Anfang dieses Threads: Das cInclude soll ja auch im Inputbereich-Code eines Moduls erfolgen, also (implizit) innerhalb einer eval() Funktion => daher muss -in diesem Fall- die Struktur global sein.

Aber die Feinheit mit dem unset() stimmt natürlich auch.

[HerrB]

Wie wäre es als Funktion?

Code: Alles auswählen

function getStructureArray() {
return array( 
    1 => array( 
        "section_title" => i18n("Description"), 
        "cms_var"       => "CMS_VAR[1]", 
        "cms_value"     => "CMS_VALUE[1]", 
        "cms_html"      => "CMS_HTML[1]", 
        "cms_var2"      => "CMS_VAR[201]", 
        "cms_value2"    => "CMS_VALUE[201]" 
    ) 
... 
    9 => array( 
        "section_title" => i18n("Homepage"), 
        "cms_var"       => "CMS_VAR[9]", 
        "cms_value"     => "CMS_VALUE[9]", 
        "cms_html"      => "CMS_HTML[9]", 
        "cms_var2"      => "CMS_VAR[209]", 
        "cms_value2"    => "CMS_VALUE[209]" 
    ) 
);
}

Code: Alles auswählen

$html_content = getStructureArray();

Gruß
HerrB