Modulvarianten und Template-Unterverzeichnis

[shadowcat]

Der Zeitpunkt ist grad etwas ungünstig weil unser "Varianten-Fachmann" (creativecat) - äh - grad zeitlich etwas eingeschränkt ist... Hm. Darf ich verraten, daß da ein neuer Erdenbürger...?

Es geht um die Behandlung der Template-Pfade. Derzeit werden Varianten da noch nicht berücksichtigt. Der entsprechende Code-Ausschnitt:

Code: Alles auswählen

        /**
         *
         * @access public
         * @return
         **/
        public static function setTemplatePaths($name,$type='module')
        {
            $base = Directory::sanitizePath(CAT_ENGINE_PATH.'/'.$type.'s/'.$name.'/templates');
            if(file_exists($base.'/default'))
            {
                self::tpl()->setPath($base.'/default');
                self::tpl()->setFallbackPath($base.'/default');
                return;
            }
            if(file_exists($base))
            {
                self::tpl()->setPath($base);
                self::tpl()->setFallbackPath($base);
                return;
            }
        }   // end function setTemplatePaths()

Aktuell habe ich zudem noch das Problem, dass das Modul wbBlueprints aus irgendeinem Grund an dieser Stelle Chaos verursacht, und zwar in der Form, dass im BE der Seitenheader fehlt, aber das finde ich schon noch.

[shadowcat]

Jetzt hab ich glatt vergessen zu schreiben, warum ich das hier poste. Bisher machen die Module von Matthias die Varianten-Behandlung ja selbst, das soll in den Core, daher sollten wir das abstimmen.

[creativecat]

Ich bin da seeehr dafür! Denn das sollte echt der Core erledigen

[shadowcat]

So, Zwischenstand:

\CAT\Addon\Module

Code: Alles auswählen

        /**
         *
         * @access public
         * @return
         **/
        public static function getModuleVariants()
        {
            $module_variants = \CAT\Helper\Directory::findDirectories(
                CAT_ENGINE_PATH.'/modules/'.self::$directory.'/templates',
                array(
                    'max_depth' => 1,
                    'remove_prefix' => true
                )
            );
            return $module_variants;
        }   // end function getModuleVariants()

Ermittelt ganz trivial die Unterverzeichnisse vom /template Verzeichnis und gibt sie als Liste zurück.

Code: Alles auswählen

        /**
         *
         * @access public
         * @return
         **/
        public static function getVariant()
        {
            return \CAT\Sections::getVariant(self::$section_id);
        }   // end function getVariant()

\CAT\Sections::getVariant() holt den Eintrag aus der Datenbank. Ist die Spalte NULL, wird 'default' zurückgeliefert.

Der Code-Abschnitt aus \CAT\Backend\Page:

Code: Alles auswählen

                            if ($handler)
                            {
                                self::log()->addDebug(sprintf('found class file [%s]',$handler));
                                include_once $handler;
                                $classname::initialize($section_id);
                                Base::addLangFile(CAT_ENGINE_PATH.'/modules/'.$module.'/languages/');
                                self::setTemplatePaths($module,$classname::getVariant());
                                $section_content = $classname::modify($section_id);
                                // make sure to reset the template search paths
                                Backend::initPaths();
                            }

Hybrid-Module wie etwa wbBlueprints müssen die entsprechenden Methoden selbst implementieren, da sie nicht von unseren Klassen erben können, aber das kann man sich dann ja später bei wbBlueprints abgucken.

Natürlich muß das auch noch für's Frontend eingebaut werden, aber so weit bin ich nicht gekommen.

Und zuguterletzt noch obige Funktion setTemplatePaths():

Code: Alles auswählen

        /**
         *
         * @access public
         * @return
         **/
        public static function setTemplatePaths($name,$variant='default',$type='module')
        {
            $base = Directory::sanitizePath(CAT_ENGINE_PATH.'/'.$type.'s/'.$name.'/templates');
            $paths = array(
                $base.'/'.$variant,
                $base.'/default',
                $base
            );
            foreach($paths as $path)
            {
                if(file_exists($path))
                {
                    self::tpl()->setPath($path);
                    self::tpl()->setFallbackPath($base.'/default');
                    return;
                }
            }
        }   // end function setTemplatePaths()

Das ist nochmal anzupassen, aber so ist halt grad der Stand.

[shadowcat]

Hm, hab ich da nicht noch einen Denkfehler drin? Im Moment ist Variante = Template-Unterverzeichnis, aber das ist doch nicht zwangsläufig so, oder?

[shadowcat]

Mal zur Erläuterung: Die ursprüngliche Idee hinter den Template-Verzeichnissen war, dass es ja z.B. sein kann, dass der normale Output eines Moduls nicht so ganz zum Frontend-Layout paßt. Wenn man nun das Template anpaßt und später ein Update des Moduls installiert, sind die Anpassungen weg und man kann von vorne anfangen. Statt dessen kann man sich bei uns nun aber einfach ein eigenes Template-Verzeichnis anlegen, dort die Änderungen ablegen, und das Verzeichnis als "Variante" einstellen. Bei einem Update muß man dann ggfs. mal vergleichen, ob es Änderungen im Original-Template gibt, die man übernehmen muß, aber zumindest bleiben die eigenen Änderungen erst mal erhalten.

Der Gedanke hinter den Varianten, wie sie MultiColumn mitbringt, ist aber weitreichender, denn es geht ja nicht nur darum, das Layout zu ändern, sondern es hängen auch Einstellmöglichkeiten dran.

Demnach wäre Variante != Variante, oder anders gesagt, Template-Verzeichnis-Auswahl und Variante sind nicht zwangsläufig das gleiche.

Fazit: Wir müssen unterscheiden zwischen einer Modulvariante a la MultiColumn und einer "einfachen" Layout-Variante. Was wiederum bedeutet, dass wir neue Begrifflichkeiten finden müssen, um diese beiden Dinge zu unterscheiden.

[shadowcat]

Vielleicht "Skin" (ist ja als Begriff verbreitet) und "Variante"?

[shadowcat]

Na das ist doch schon mal ganz nett...

Symbol erscheint nur, wenn Optionen vorhanden sind

2018-02-22 17_28_59.png (27.37 KiB) 4109 mal betrachtet

Aufgeklappt

2018-02-22 17_29_06.png (27.49 KiB) 4109 mal betrachtet

[creativecat]

Das klingt schon mal von den Funktionen her sehr gut! Mir gefällt der Code der neuen Version schon jetzt! Ganze Arbeit geleistet Bianka!


Zum Thema "Benennung": Ich bin mir gerade nicht sicher, ob man zwei Namen benötigt. Ich verstehe deinen Gedankengang, aber dann kommen die Leute wieder: "Was ist denn bitte der Unterschied?" - vor allem für den Modulentwickler beim der Programmierung?
Bei mir "verstecken" sich die zusätzlichen Einstellungen programmiertechnisch ja eigentlich in den Skins (im Englischen heißt es bei meinem Modulen übrigens immer Skin). Jede Variante kann einfach grundsätzlich ein paar Informationen zusätzlich speichern - angefangen von Hintergrundfarbe bis hin zu zusätzlichen Überschriften oder Sonderformatierungen.

Dann mache ich gleich noch ein Fass auf (und eigentlich gleich wieder zu): Ich habe in einigen Installationen bei der getModuleVariants() noch einen Filter eingebaut, der einfach alles, was mit einem Unterstrich beginnt rausfiltert - Sinn ist, dass ich bei manchen Kunden die Varianten nicht einblenden möchte, aber evtl. später mal doch schnell einbinden will (ist sogar nur aktiv, wenn nicht der "superuser" eingeloggt ist). Dann benenne ich im Template-Ordner die Varianten um (zB "lorem" in "_lorem") und schon verschwindet die Variante in der Auswahl. Das ist die einfachste Möglichkeit.
Jetzt könnte man diese Idee aufbohren und theoretisch gleich wieder mehr Infos mit einer Variante über den Core verknüpfen: Unbeschränkte Benennung der Varianten (muss sich nicht an die Benennung von Ordnern halten), Zusatzinformationen zur Variante (Copyright, Autor etc.) und man kann auch gleich Rechte damit verknüpfen: Wer darf welche Variante setzen und administrieren. Bisher habe ich das umgangen, weil ich kein eigenes Rechtesystem in meine Module einbauen will. Und wenn wir das alles aber dann auch noch in den Core einbauen, wird es irgendwann eine "Never ending story", BC2 niemals fertig und wenn, dann so kompliziert, dass ich auch andere bekannte CMS (nicht) nutzen kann, weil ich keine Lust habe mich jahrelang einzuarbeiten... Die Idee mit dem Unterstrich ist vielleicht einfach eine Sache: Hidden-Feature

[shadowcat]

Hähä, ich nehm auch immer den Unterstrich, wenn ich z.B. Module vorübergehend deaktiviere. Gebongt!

Das mit den Infos zu den Varianten hab ich auch schon überlegt, da könnte man ja auch eine info.php reinpacken. Ich hatte im ersten Anlauf das Formular als options.tpl hinterlegt, inzwischen ist es eine inc.forms.php für den FormBuilder. Ich verstehe Deine Bedenken, aber man kann sich das ja für die Zukunft offen halten. Es muß ja nicht zwangsläufig in die Datenbank, im einfachsten Fall gibt's halt eine readme und fertig.