Allgemeine Bugs!!!

[paulbr]

Hallo

erstmal Danke das ist eine super Arbeit was Ihr da leistet.

Ich wähle mal diesen Weg, nicht den Bugtracker, da dieser wohl all die Kleinigkeiten nicht
aufnehmen kann. 
Nein Scherz: ich weiss nicht ob diese Bugs nur bei mir auftreten!

Ich habe mir das aktuelle svn (trunk) geladen und darauf aufbauend versucht eine Ausgabe des CMS
auf einem Lokalen Server (ohne virtual domain) zu erzeugen.

Folgende Gravierente Dinge sind mir da aufgefallen:

a) Ihr definiert generell in der clansuite.application.php Konstanten
    z.b. define('ROOT_MOD', ROOT . self::$config['paths']['mod_folder'] . DS, false);
    das ist ok, wenn nicht fast in vielen scripten in der nun ein Pfad auf ein Modul
    gesetzt wird stehen würde (z.B. router.core.php):
    $module_routes_file = ROOT_MOD . '/' . $modulename . '/' . $modulename . '.routes.php';
    konkret: nach der Konstante braucht man kein "/" mehr.

b) Leider berücksichtigt Ihr in der route nur top-level urls
    file: router.core.php - funktion: route()
    if(empty($this->uri) or $this->uri === '/')
    d.h. wenn die domain www.clansuite.com und kein Parameter angegeben wurde
    ist die uri "/" oder leer, dann ist das korrekt.
    Wenn man aber einen lokalen server ohne domäne definiert hat stimmt das nicht mehr, den
    dann ist in der uri der Pfad vom DocumentRoot des Servers bis zum Root der clansuite
    installation enthalten (z.B. bei mir: /test/clansuite/trunk/).
    Ich habe mir beholfen indem ich, wenn clansuite im Development Modus fährt, dies aus der uri
    extrahiere und erst dann prüfe. Im Produktion Modus entfällt das extrahieren dann.

c) Geschmacksache aber was mir nicht gefällt, das in
    file: clansuite.loader.php - funktion: autoload
    Loadpfade für Klassen definiert werden wo gar keine sind, dadurch wird die logdatei
    autoload_misses.log unötigerweise gefüllt.
    Mann könnte das z.B. auf die Art lösen:

    $filenames = array();
    $i=0;

    # Core Class
    # class_name.class.php
    if(file_exists(ROOT_CORE . str_replace('_','',$filename) . '.core.php'))
    {
        $filenames[$i] = ROOT_CORE . str_replace('_','',$filename) . '.core.php';
        $i++;
    }

    ergänzt hab ich bei mir, weil manchmal nicht gefunden wurde:
    # Doctrine
    # doctrinerecords/classname.php
    if(file_exists(ROOT . 'myrecords/' . $classname . '.php')) {
        $filenames[$i] = ROOT . 'myrecords/' . $classname . '.php';
        $i++;
    }

    Ich weiss noch nicht warum, aber bei mir wurden einige Modul-Klassen nicht gefunden.
    Abhilfe schaffte ich durch hinzufügen von:
 
    if(false !== mb_strpos($filename, 'clansuite_module_'))
    {
        self::loadModul($classname);
    }
 
    einzufügen nach:
    $filename = mb_strtolower($classname);

    vor:
    if(false !== mb_strpos($filename, 'clansuite_'))
 
d) in manchen Modulen ist die Doctrine Klasse falsch:
    z.B. Modul: users - file:users.module.php
    die Doctrine Klasse: CsGroup, CsProfile nicht wie dort definiert "CsGroups" "CsProfiles" usw.
    Desweiteren gibt es einige SQL Fehler
    z.B.:
    File: Doctrine.compiled.php - Line: 1
    SQLSTATE[42S22]: Column not found: 1054 Unknown column 'g.id' in 'on clause'. Failing Query:
    "SELECT COUNT(*) AS num_results FROM (SELECT u.user_id FROM users u LEFT JOIN
     rel_user_groups r ON (u.user_id = r.user_id) LEFT JOIN groups g ON g.id = r.group_id LEFT JOIN
     profiles p ON u.user_id = p.user_id GROUP BY u.user_id) dctrn_count_query"
     Diesen Fehler hab ich bisher noch nicht lokalisieren können.
     Er kommt beim Aufruf des Moduls: User über das Navigationsmenü.

e)  Bei Modul teamspeakviewer sind einige Fehler bzgl. des Klassennamens der commands.
     z.B. serverdelete.php die Klasse heisst:
     class Teamspeak3_ServerQueryCommand_servercreate extends ......
     kommt bei einigen vor, ist aber nicht wichtig, da diese commands bisher nicht verwendet werden.

Es gibt noch viele kleine Dinge die nicht ganz rund laufen, aber die sind nicht so wichtig, am meissten
stören die SQL Fehler und die teilweise falschen Doctrine Klassennamen.
Auch denke ich, das es zwingend erfordelich ist, die Server Url neutral zu halten, so das man
jederzeit ohne Umprogrammierung im Development und Produktions Modus fahren kann.

Ich habe dies durch eine eigene config.php gelöst, in der viele developer ihre eigene lokale
Serverumgebung und datenbank definitionen einstellen können. Man kann so entscheiden ob
das CMS im Development, Internen Server, Staging Server oder Produktion Server laufen soll.

Schade das die XTemplate Engine Integration noch nicht soweit fortgeschritten ist.
Ich arbeite lieber mit dieser als mit Smarty 

Grüsse
Paul

[Jens-A. Koch]

Hallo Paul,

zunächst Willkommen im Forum und einen großen Dank für Deinen Bugreport.
Du bist einer von ganz wenigen Menschen Dir mir derzeit Feedback geben.
Ich werde versuchen die Fehler der Reihe nach anzusprechen und abzuarbeiten.

a) ROOT_* Konstanten mit Slash am Ende bearbeitet
Du hast Recht, nach der Konstante is kein "/" mehr nötig.
Bin die Root-Konstanten durchgegangen und habe nun hoffentlich alle unnötigen Slashes entfernt. Kann nich ganz ausschließen, dass noch welche auftauchen. Bitte um Rückmeldung, wenn Du noch welche findest.

b) Router bearbeitet
Der Router ist gerade erst ins Spiel gekommen. Da werden noch einige Bugs zu finden sein^^
Das Problem hab ich aber verstanden: der Pfad muss abgezogen werden.

Auch denke ich, das es zwingend erfordelich ist, die Server Url neutral zu halten, so das man jederzeit ohne Umprogrammierung im Development und Produktions Modus fahren kann.

Hast Du ne Idee wie man das gut umsetzen kann?

c) Autoloading
Da kann man viel dran machen. Einerseits könnte man das Loggen der Hits/Misses ganz abschalten. Das ist eh nur zum Debuggen. Andererseits kann man natürlich die Misses nochmal deutlich reduzieren, wenn man das einbaut, was Du vorgeschlagen hast.

d) Module und DoctrineRecords Noch offen und brauche Unterstützung dafür.
Das ist schlichtweg veraltet! Ich hab das Users-Modul schon lange nich angefasst.
Daher auch die Abweichung von SQL und Records und die ganzen SQL Fehler.

Zum angesprochenen Einzahl/Mehrzahl-Problem: CsGroup/CsGroups.
Es sollte alles auf Mehrzahl lauten - das is dann ein einheitlicher Standard.

e) Teamspeak *Noch offen*
Das sieht nach nem typischen Copy&Paste bei Erstellung der Klassen aus.  ,)

Wie ich sehe hast Du Dich ja doch etwas mehr mit Clansuite beschäftigt
und scheinst das System auch einzusetzen.
Sag mal, möchtest Du Zugriff aufs SVN um Deine Änderungen einzubauen?
Evtl. schaffen wir es zusammen das System etwas runder zu machen und die
ganzen kleinen und großen Fehler rauszuschmeißen. Wir könnten auch
gemeinsam mal ein Theme und Templates für die XTemplate Engine anpacken.
Ich würde mich freuen.

Danke erstmal & Grüsse
Jensa

[paulbr]

Hallo jensa

es gibt da im moment 2 Dinge die mich abhalten deinen Vorschlag zwecks aktiver Mitarbeit an dem Projekt anzunehmen.
1. die Zeit (ich habe davon leder sehr wenig) 
    ich denke das es wenig bringt, wenn ich nur ab und an mal etwas für das Projekt leisten kann.
    Zur Zeit hab ich grad Arbeitspause, oder wie Angestellte sagen würden..Ich hab Urlaub
2. meine PHP Kentnisse 
    Ich hab vor einigen Jahren mal ein WCMS Objektorientiert in PHP4 Programmiert, welches heute
    noch im Einsatzt ist (leider nur bis PHP < 5.2 lauffähig). Dafür nutze ich die XTemplate-Engine.
    Mit PHP5 version >= 5.2 konnte ich mich bisher noch nicht so recht anfreunden
    Bin grad dabei dies zu ändern, also sind meine Kenntnisse darin noch nicht so überzeugend.
    Im moment wird meine PHP 5 OOP kenntniss wohl eher dilletantisch als professionell sein

Ich hab mir clansuite erst ein paar Tage angesehn, was spontan auffällt hinsichtlich der Template-Engine ist:
 - Clansuite sollte frei für die Entscheidung der Nutzung einer Template-Engine sein.
    z.B. Smarty, XTemplate .....
    Aber durch die gesamte clansuite, wie sie im moment vorliegt gesehen, geht das gar nicht.
    Überall wird Smarty verwendet, hier wurde von Anfang an der Fehler gemacht, die Smarty
    Templates nicht in eigene Ordner zu separieren.
    Desweiteren wird in vielen Scripten Smarty als RenderEngine einfach vorrausgesetzt und
    entsprechend die Nutzung einer anderen gar nicht in betracht gezogen.
    Hier ist einige Umstrickarbeit nötig, damit man je nach gusto die TemplateEngine ändern kann,
    auch hinsichtlich evtl. anderen Engines. Das System sollte dahingehend ja flexible bleiben.
    Ich habe mir gestern abend mal den Spass gemacht, Smarty in eigene Ordner zu Separieren,
    aber clansuite habe ich damit bisher noch nicht zum laufen gebracht 

 - Was die Konfiguration angeht, sehe ich hier nicht als das grosse Problem an.
   Man muss lediglich die clansuite.config.php als reine Kontainerablage sehen, d.h.
   die Einstellungen sollten nicht in dieser ini Datei sondern in einer PHP Datei (config.php)
   erfolgen.
   Nur so kann man je nach Entwickler-Umgebung entsprechend die Konfiguration einlesen, diese in
   die clansuite.config.php speichern und hat sie dann wie bisher überall zur Verfügung.
   Diese Variante setze ich schon seit Jahren selbst ein, da bei meinen Projekten auch hin und wieder
   andere Programmierer mitwirken. Die Lokalen Serverinstallationen sind da sehr Unterschiedlich.
   Manche verwenden xampp, ich bevorzuge den Wampserver, viele installieren den Standard in
   C:\programme\xampp ich bevorzuge für den Server ein eigenes laufwerk (E:\SERVER).
   Manche verwenden eine Domäne, ich nicht, da ich viele Projekte habe, macht es keinen Sinn
   jedesmal eine Domäne zu erstellen. Da auch einige in Ihrer lokalen Serverumgebung das Projekt
   nicht im DocumentRoot des Apache installiert haben, sondern in eigene Ordner irgendwo darin
   (was durchaus ja Sinn macht bei vielen projekten), muss das ja auch berücksichtigt und neutral
   behandelt werden können.
   Auch hinsichtlich der Datenbank gibt es da jede Menge differenzen, angefangen mit dem DB-Name
   bis hin zum DB user+pwd.
   Dazu kommt das je nach grösse des Projektes und Anzahl User auf der Webseite evtl. Cluster
   Server eingesetzt werden müssen. Auch das sollte man ja bei dem lokalen Serverbetrieb mit
   berücksichtigen werden.
   Dies entsprechend zu ändern ist kein grosser Aufwand und erfordert keinerlei Umprogrammierung
   der bestehenden clansuite. Lediglich ein Zusatz in clansuite.application.php.
   Auch sollte man hier bereits in der Konfiguration festlegen welche RenderEngine man benutzen
   will. Diese kann man dann als Konstante anlegen und so überall die Fallentscheidung bzgl. des
   Renderings treffen.
   @todo:
      Gleiches könnte man mit dem DB-Abstraktions-Layer(Doctrine) machen.
      So kann man z.b. Doctrine oder ADOdb einsetzen, oder noch andere, je nachdem.
      (ADOdb liegt ja bei einigen Linux distributionen bei)

Zu den Doctrine Records:
  - Die Klassen können ja mit dem Doctrine Import Builder angelegt werden.
    Die Base-Klassen sind soweit Ok, was meiner Meinung nach geändert werden sollte sind die
    Klassen welche die Base-Klassen aufrufen.
    Ich würde dies Neutraler gestalten, so das es je nach verwendetem DB-Abstraktions-Layer
    verwendet werden kann.
    z.B.: Modul News
    /news
    .../model
    ....../doctrine
    ........./generated
    ............BaseCsNews.php
    ............BaseCsRelNewsComments.php
    .........DB_Modul_Csnews.php
    .........DB_Modul_CsRelNewsComments.php
    ....../<andere DB>
    ........./generated
    ............BaseCsNews.php
    ............BaseCsRelNewsComments.php
    .........DB_Modul_Csnews.php
    .........DB_Modul_CsRelNewsComments.php

Man könnte so, genau wie im Autoload bei den Module 'clansuite_module_'
auf 'DB_' checken. Ein checken auf 'Cs' ist da nicht so effizient, da unter umständen
das bei anderen definitionen oder filenamen vorkommen könnten, welche nicht unbedingt etwas
mit den DB Klassen zu tun brauchen.
z.B. Autoload wie mein Vorschlag wenn 'clansuite_module_' dann loadModul(), könnte man hier auch
wenn 'DB_Modul' dann loadDbModul() mit ansetzen.
  - 'DB_Modul' sagt es ist eine Modul-Datenbankklasse
  - Csnews sagt aus um welches Modul es sich handelt, Cs extrahieren dann hat man 'news'
     nun kennt man auch den Pfad für das Autoload
  - Alle Modul unabhängigen klassen in "myrecords" z.b. könnten dann 'DB_Core_...' lauten
     bzw. man legt ein Array an in welchem diese definiert werden.
     So hat man nur 2 Pfade: "/myrecords" + "/modules/<modul>/model/records".

Struktur
Der Gedanke an Module generell ist meiner Meinung nicht vorrangig, sondern die Basis sollte
erstmal Sauber, Strukturiert und Fehlerfrei funtionieren:
 - Konfiguration je nach Serverumgebung
   (nicht der Anwender muss sich der Software, sondern die Software sich dem Anwender anpassen)
 - Trennung der Templates je nach TemplateEngine
 - Striktes Einhalten innerhalb der Modules, so braucht man keinen Autoload Pfad für
   /modules sondern reicht konkret auf das modulbezogen z.b. /modules/news
   Gerade hinsichtlich der TemplateEngine ein muss.
   Bei der Smarty Templatepfad-Definitionen kann dann auch stark abgespeckt werden.
   anstatt ein array mit: /modules + /modules/news + /modules/news/view
   reicht es wenn man direkt auf /modules/news/view/smarty  definiert (performance).
 - bei den Themes gilt das gleiche wie bei den modules, auch hier sollte nach der
   TemplateEngine Separiert werden, ausserdem noch nach Backend, Core und Frontend
   (bessere und einheitliche Struktur-Übersicht)
   z.B.
   /backend
   .../admin
   ....../css
   ....../images
   ....../javascript
   ....../view
   ........./smarty
   ........./xtemplate
   ......theme_info.xml

   /core
   ....../css
   ....../exceptions
   ....../fonts
   ....../images
   ....../javascript
   ....../view
   ........./smarty
   ........./xtemplate

   /frontend
   .../meinTheme
   ....../css
   ....../images
   ....../javascript
   ....../view
   ........./smarty
   ........./xtemplate
   ......theme_info.xml

   Danach kann man sich Gedanken um Module machen.

Sonstiges
 - Das loggen der Hits, ja denke ich auch das es nicht sein muss, allerdings das
   loggen auf misses schon, den hier sieht man wenn etwas nicht stimmt.

 - der Einheitlichkeithalber sollten die *WWW_ROOT_* Konstanten ebenfalls mit Slash am ende
   gesetzt werden, wenn alle Pfad-Konstanten gleich definiert sind, macht man keine
   leichtsinnsfehler und muss nicht immer erst überlegen ob da nun nein slash hingehört oder nicht.
   Das aber nur am Rande.

Clansuite
Nein Clansuite setze ich nicht ein, aber ich Informiere mich ab und an mal was es neues gibt.
So bin ich letzte Woche auf clansuite gestossen und muss sagen die Idee dahinter gefällt mir,
vorallem weil sie im Prinzip meiner Einstellung eines guten CMS entspricht, zudem sehe ich sehr viel
Ähnlichkeiten in mein damals in PHP4 entwickeltes WCMS.

Allerdings spiele ich mit dem Gedanken evtl. clansuite abgespeckt für die Clan-Webseite, die ich
schon längst für meinem Sohn hätte machen sollen und aus Zeitgründen immer wieder verschoben
habe, einzusetzen

Um clansuite professionel einzusetzen fehlt es noch an vielem, vorallem an der konsequenten Rechte
Verwaltung und dem differenzierten User/Adminbereich. User ist ja nicht gleich Admin

Anmerkung
Das grösste Problem welches ich bei clansuite zur Zeit sehe ist die Installation und das es
danach nicht ohne einigen Aufwand sofort lauffähig ist, zur Zeit wenigstens noch nicht.

Mein Beitrag:
Ich setze mich mal hin und mach das mit der Konfiguration.
Wenn ich das fertig habe, schicke ich es hier als Anhang mit einer kurzen Erklärung,
damit du es in die aktuelle clansuite integrieren kannst.

Das Separieren nach der TemplateEngine erfordert allerdings weit mehr an Zeitaufwand und die
Änderung vieler Scripte. Dazu kommt, das ich clansuite noch nicht wirklich kenne um sagen zu können
wo was geändert werden muss.


gruss
Paul

[paulbr]

Ich hab das mit der Konfiguration mal umgesetzt, denke es sollte so funktionieren,
zumindest läuft clansuite nun bei mir so.

Erklärungen:

global.config.php
  1. Datei hinzugefügt
  2. Erklärungen sind denke ich ausreichend in der datei selbst.
     Wichtig nur wenn mehrere Programmierer mit unterschiedlichen Einstellungen arbeiten,
     sollte die variable $LocalUser definiert werden, also damit jeder Nutzer seine
     eigene ID hat.
     Anmerkung: Ich hab für gewöhnlich den $LocalUser in eine eigene localswitch.php gelegt,
     welche dann nicht ins svn geladen wurde (igno). Da ja sonst ständig jeder die Einstellungen
     der anderen hat. In dieser datei steht nur: $LocalUser = 1 bzw. die entsprechende User ID.
  3. Das Array $aDefaultSettings enthält ein paar Einstellungen die vorher nicht in
      clansuite.config.php definiert waren und Sinn machen.

clansuite.config.php
  1. [paths] definition gelöscht und bei den Konstanten in clansuite.application.php
     fest eingetragen. Ich bin der Meinung sowas ändert man nicht ständig um, von
     daher kann man es bei bedarf auch dort ändern. Wobei ich der Überzeugung bin
     das globale Pfade nicht geändert werden sollten.
     Der Grund ist nachfolgend ersichtlich.

clansuite.application.php
  1. Positionstausch in funktion: run()
      Reihenfolge: initialize_Paths(); initialize_Loader(); initialize_Config();
      Somit wird gewährleistet das im Loader bereits auf die Konstanten zugegriffen
      werden kann. Zudem muss der Loader vor der initialize_Config(); geladen werden.
  2. In der initialize_Config() ermittle ich zuerst den Servernamen.
      Abhängig von diesem wird das in der config.php deklarierte Array geladen.
      Es wird eine variable für den Zustand des Servers gesetzt (development|production|..).
      Ein paar neue Funktionen die diesen Zustand abfragen sind Eingefügt:
        + IsDevelopment() + IsProduction() + IsIntern() + IsStageing()
  3. Nachdem der Servername nun feststeht kann ich anhand der korrekten Definitionen die Daten
      übernehmen und in die clansuite.config.php schreiben.
  4. Da mich das immer gestört hat, das bei einer Debug-Ausgabe nie die konfiguration und die
      Konstanten definitionen mit angezeigt wurden, hab ich das mal mit eingefügt.
      Dazu ist die variable xdebug_outconfig gedacht. Ist diese in der config.php auf 1 gesetzt,
      wird im XDebug ein Block mit den konfigurationen und den Konstanten ausgegeben.

clansuite.loader.php
  1. Die Pfadangaben durch korrekte Konstanten ersetzt
  2. function autoload() wie in meinem ersten Post geändert

xdebug.core.php
  1. wie oben erwähnt um die Ausgaben der $config + Konstanten erweitert

router.core.php
  1. function route() erweiterung bzgl. der URI
      Es wird geprüft ob IsDevelopment() zutrifft, wenn nicht wird nix getan.
      Wenn zutrifft, wird aus der URI der Lokale Root entfernt.
      So das egal in welchem Unterordner nun die clansuite installiert ist,
      hier ausgelesen werden kann ob die uri '' oder '/' ist.
      Technik: in der config.php wird der Root-Pfad zur clansuite Installation,
      Relativ ausgehend com Apache DocumentRoot gesetzt. Somit kann mit der
      neuen funktion getsRoot() diese ausgelesen und die URI davon befreit werden.

OK das war's in kürze, bei Nachfragen einfach melden

gruss
Paul

PS:
  leider kann ich das gepackte rar nicht anhängen, da keine schreibrechte in dem Ordner
  gesetzt sind.
  Bitte das mal Prüfen, dann lade ich erneut hoch!

[Jens-A. Koch]

Der Upload sollte nun gehn.

Staging
Die Staging Idee ist super! D.h. man kann damit unterschiedliche Setups fahren ohne sich in die Quere zu kommen. (und wie oft wurde hier schon die config aus versehen committet... mann o mann)

Die Idee mit dem localswitch finde ich auch gut. Das könnte man auch über eine Methode machen setStageDevelopment($user_id) und die user_id zieht man über die besagte localswitch.php rein.
Dann ist nur eine Datei auf ignore - und die unterschiedlichen Configs unter Versionskontrolle.

Debugausgaben
Für Smarty gibts die debug.tpl. Es gibt auch eine alte Version davon mit allen Anzeigen des System - das hatte Florian irgendwann mal zu Smarty2-Zeiten für besseres Debugging gebaut. Habe seine Modifikationen noch nicht an die debug.tpl von Smarty3 angepasst. Muss ich mal diffen/mergen.

Daneben gibts auch noch die PHPDebugConsole. Das ist ein Vorfilter. Wenn dieser Filter aktiviert ist, dann bekommste eine kleine Debug-Toolbar an den oberen Bildschirmrand und kannst Konstanten, Files, Vars aufklappen und einsehen. Beispiel auf dieser Seite: http://www.php-debug.com/www/

Eine Erweiterung der Xdebug-Klasse ist ok. Xdebug müsste ja Funktionen für das Dumpen von Konstanten und Variablen haben.

Paths-Definitionen in der Config
Hast Recht - die ändert man eh nicht. Weniger Konfiguration, mehr Konvention. Hardcoden und fertig.

WWW_ROOT Konstanten
Sind nun mit Slash am Ende. In den Templates daher statt "{www_root_themes_core}/images..." nur noch "{www_root_themes_core}images...". Sieht etwas gewöhnungsbedürftig für mich aus.. mal schaun.


Morgen gehts weiter... Grüsse jensa

[paulbr]

Hallo jensa

hier das versprochene packet

gruss
Paul

[paulbr]

1. Fehlerbehebung

es ist mir grade aufgefallen das einige variablen für das catchen in der clansuite.config.php
fehlen, welche in modulen aber abgefragt werden.

Nachstehende Änderungen beheben die Fehlermeldungen:

global.config.php
  die $aDefaultSettings sollte nun so ausschauen

Code:

  $aDefaultSettings = array
  (
      # Fehlerbehandlung (mit debug ausgabe auch $config-array ausgeben)
      'xdebug_outconfig' => 1,

      # RenderEngine ( e.g. Smarty | XTemplate )
      # default = Smarty (wenn das feld "" ist wird in clansuite 'Smarty' als default gesetzt)
      'renderer_name' => "Smarty",

      # Server-Cache-Engine ( e.g. APC | MemCache | Aaccelerator | Xcache )
      'cacheengine' => null,

     # MemCache
      'memcached_autocompression' => 0,
      'memcached_lifetime' => 0,

      # Smarty Cache
      'smarty_caching' => 1,
      'smarty_cache_lifetime' => 0,

      # Routes Cache
      'cache_routes' => 0
  );

clansuite.application.php
  bei den Default settings in der function initialize_Config()
  bitte nach $aConfig[ 'cache' ][ 'cache' ] = $aDefaultSettings['cacheengine']; einfügen:

Code:

  $aConfig[ 'cache' ][ 'cache_routes' ] = $aDefaultSettings['cache_routes'];
  $aConfig[ 'cache' ][ 'smarty_caching' ] = $aDefaultSettings['smarty_caching'];
  $aConfig[ 'cache' ][ 'smarty_cache_lifetime' ] = $aDefaultSettings['smarty_cache_lifetime'];
  $aConfig[ 'cache' ][ 'memcached_lifetime' ] = $aDefaultSettings['memcached_lifetime'];
  $aConfig[ 'cache' ][ 'memcached_autocompression' ] = $aDefaultSettings['memcached_autocompression'];

1. Änderung
  Durch das hinzufügen der Einstellung bzgl. der RenderEngine in der global.config.php
  wäre es ja von Vorteil wenn man diese je nachdem welche RenderEngine man da auswählt,
  diese auch aktiviert wird. Dazu sollte folgende Änderung gemacht werden:

  modulecontroller.core.php
  Die function getRenderEngineName() ersetzen durch:
 

Code:

    public function getRenderEngineName()
    {
         $sName = '';

        # check if the requesttype is xmlhttprequest (ajax) is incomming, then we will return data in json format
        if(self::getHttpRequest()->isAjax() === true)
        {
            $sName = 'json';
        }

        # use smarty as default, if renderEngine is not set and it's not an ajax request
        if(empty($sName))
        {
            $sName = strtolower( RENDER_ENGINE );
        }

        # use smarty as default, if renderEngine is not set and it's not an ajax request
        if(empty($sName))
        {
            $sName = 'smarty';
        }

        $this->setRenderEngine($sName);

        return $this->renderEngineName;
    }
 

Nun kann ein wechsel der RenderEngine je nach gusto stattfinden, allerdings müssen
hierzu erst noch die strukturen geändert und smarty separiert werden.

So das war was mir grade so aufgefallen ist.

gruss
Paul

[Jens-A. Koch]

Danke dafür.

Auswahl der RenderEngine
Also Dein Weg ist, die RenderEngine über eine Konstante festzulegen.
Dann entsteht folgende Reihenfolge: zuerst die Config-Einstellung,
danach die User-Einstellung für das Theme und zuletzt dann der Fallback auf Smarty.

Mein Vorschlag dazu: Ich würde die RenderEngine aus der Config rauslassen.
Denn der Renderer kann sich ja je nach Theme ändern. D.h. die Theme-Auswahl des Users bestimmt über die Engine. Die RenderEngine bestimmt man dann anhand der Beschreibungsdatei des Themes  - oder man nimmt Deinen Ansatz mit festen Pfaden /themes/smarty; /themes/xtemplate, dann braucht man die Datei nich einlesen.

User-Session -> Theme-Einstellung holen -> Theme-Beschreibung auslesen -> Renderer setzen
Das könnte man im Dispatcher machen. Die entsprechende Variable für die RenderEngine hab ich dafür schon im TargetRoute-Objekt angedacht.

Pfade / initalize_paths() zuerst
- Pfad sind nun hardcoded - keine Config Werte mehr.
- Dadurch ist auch die Abhängigkeit der Methode initialize_paths von initialize_config aufgehoben und eine Initalisierung an erster Stelle in run() möglich.
- An einigen Stellen hatte ich getcwd() eingesetzt, um dieser Abhängigkeit aus dem Weg zu gehen und vorher schon Pfade bauen zu können. Diese Stellen hab ich mit den Konstanten ersetzt.

wird fortgesetzt...

[paulbr]

Ja klingt vernünftig!
Ein Auslesen der RenderEngine Modulbezogen aus der module config finde ich sogar noch
viel besser, da es viel flexibler ist.

Auf jedenfall denke ich das man feste Pfade machen sollte.
Den eine einheitliche Struktur erleichtert immer die Arbeit, egal ob man nun Templates für
Smarty, XTemplate oder einer anderen erstellt.
Was sich ändert sind ja nur die Templates, die Ordner: javascript|images|css bleiben direkt
im Theme Ordner des jeweiligen Themes, einzig die Templates sollten unter /view separiert werden.

Ich habe mal experiemtiert und die Pfade entsprechend geändert aber ich bekomme
keine Anzeige mehr, auch keine Error-Ausgabe, ich weiss nun nicht wo überall versteckt da noch
was geändert werden muss.
Pfadänderung hab ich gemacht in:
  - renderer.base.php
  - smarty.renderer.php
  - viewhelper/smarty/function.load_module.php
  - viewhelper/smarty/resource.fetch_module_templates.php
Eine Debug-Ausgabe des template_dir (smarty.renderer.php) war Ok und
zeigte die richtigen Pfad an.
Ebenso die Debug-Ausgabe der template_constants (renderer.base.php) alles Ok.

Dumm ist das ich dabei keinerlei Fehler oder Debug-Ausgaben erhalte, nur leere Seite
mit den XDebug Angaben.
Vielleicht kannst du mir mal sagen wo noch was geändert werden muss.
Oder besser noch vlt. kannst du das ja so verändern das die Templates sauber getrennt
unter /view in den themes + modules liegen


Was man evtl. in betracht ziehen könnte wäre ein flexibleres Layout-System.
Die Standard index.tpl ist da fest vorgegeben nach dem Muster:

BasisLayout-1 (default layout)
+--------------------------------+
|                  header                  |
+--------------------------------+
| col1 |        content         | col3 +
+--------------------------------+
|                  footer                   |
+--------------------------------+

BasisLayout-2                       BasisLayout-3                      BasisLayout-4
+-------------------------+  +-------------------------+  +-------------------------+
|             header              |  |             header              |  |            header              |
+-------------------------+  +-------------------------+  +-------------------------+
| col1 |    content             |  |            content    | col3 |  |             content            |
+-------------------------+  +-------------------------+  +-------------------------+
|             footer               |  |             footer               |  |             footer              |
+-------------------------+  +-------------------------+  +-------------------------+

Das gewünschte Layout dann ebenfalls in der Moduleconfig bzw. in den einzelnen widgets
je nachdem wo es mehr Sinn macht festlegen.
Je nach Seite will man ggfs. verschiedene Layouts haben, zumindest hab ich diese Erfahrung gemacht.

Im Anhang hab ich mal zur Info eine von mir eingesetzte Variante beigelegt.
Die Beispiele zeigen die 4 Layout Gerüste und müssen nie verändert werden, weil je nach Modul
nur der Inhalt der Cols geparst werden, so immer andere Inhalte haben können.
Interessant finde ich auch das CSS-Framework Yaml, welches bei mir zum Einsatz kommt, bei
den Info-Beispielen.

gruss
Paul

PS: Hoffe ich nerve net zuviel mit meinen Posts und Vorstellungen 

[paulbr]

ups...da war ich wohl zu schnell
hab doch glatt den Anhang vergessen

[Jens-A. Koch]

PS: Hoffe ich nerve net zuviel mit meinen Posts und Vorstellungen

Nö. Mach Dir keinen Kopf. Du bringst neue, gute Ideen ein und wieder etwas Schwung ins Projekt. Hoffentlich komme ich mit der Umsetzung hinterher..

Flexibleres Layout-System
Layout ist eigentlich Theme Sache. Du kannst Dir da gerne YAML reinpacken.
Das ist dann die Oberklasse eines Layoutsystems.

Aber YAML kann nicht zusammen mit Clansuite ins SVN wegen der Lizenz. Zusammen ausliefern geht auch nicht - hatte diesbezüglich schonmal eine Anfrage bei Herrn Jesse gestellt. Ein getrenntes Theme-Packet könnte man aber andenken.

Dann gehts noch um die Daten. Um an den entsprechenden Stellen Daten einzusetzen, müsste man das Verfahren, dass ich jetzt für Smarty verwende auf die anderen Renderer übertragen.
Also einmal einen Viewhelper für die "Widgets" (die Seitenelemente in den Cols) und für die Mitte natürlich den Module-"$content". Für Smarty gibts den Viewhelper load_module - der bindet die Widgets ein. {load_module name="gallery" action="widget_gallery"}

Das weiße Seite Problem...
Am besten sehr kleinschrittig Arbeiten oder mit nem Debugger durchsteppen und schauen, wann das Rendering abbricht.

Autoloader
- Loggen von Hits ist nun auskommentiert.
- Das mit den file_exists Checks vorher (Deine Variante) oder nachher (meine) nimmt sich nichts.
Deine Weg hat den Vorteil sofort auszusteigen, wenn die Datei gefunden wurde.
Meine Weg baut erst immer alle Pfade zum Durchtesten auf. Der file_exists() Check ist in der requireFileandMap() Methode enthalten. Letztlich würde ich das Problem eher vernachlässigen.
Wenn die Datei einmal gefunden wurde ist sie in der Map.

Man könnte das $filenames Array ersetzen durch Einzelaufrufe.
Ist schneller - doppelt aber den Codeabschnitt. Den Array-Durchlauf find ich etwas besser - druckt aber die Performance. Naja - ist Geschmackssache.

Code:

if(self::requireFileAndMap(ROOT_CORE . str_replace('_','',$filename) . '.core.php', $classname) === true)
{
    return true;
}

if(self::requireFileAndMap(ROOT_CORE . 'factories/' . str_replace('_','.',$filename) . '.php', $classname) === true)
{
    return true;
}

[paulbr]

Dann gehts noch um die Daten. Um an den entsprechenden Stellen Daten einzusetzen, müsste man das Verfahren, dass ich jetzt für Smarty verwende auf die anderen Renderer übertragen.
Also einmal einen Viewhelper für die "Widgets" (die Seitenelemente in den Cols) und für die Mitte natürlich den Module-"$content". Für Smarty gibts den Viewhelper load_module - der bindet die Widgets ein. {load_module name="gallery" action="widget_gallery"}

Nicht unbedingt, man kann doch z.b. die widgets wie sie jetzt auch definiert sind einfach in ein
navigations-template packen und im module ordner unter view ablegen, so wie die show.tpl auch.
In dem Basic template dann einfach includieren im linken oder rechten menü je nachdem.

So bleibt das Gerüst immer das gleiche nur der Inhalt ändert sich.
Das hat auch wiederum den Vorteil das nicht für jedes theme eine eigene index.tpl gemacht
werden muss.
Ich hab mal eine möglichkeit für 3spaltige ausgabe gemacht, allerdings kenne ich mich mit
Smarty nun mal überhaupt nicht aus, also da bist du schon gefragt ob das umsetzbar wäre.

Ich denke wenn man in der module configuration nicht nur die RenderEngine sondern auch
das Basistemplate angibt sollte das machbar sein.

Yaml
Ja hast recht das mit der Lizenz hab ich nicht berücksichtigt.
Aber ist ja auch nicht das Problem, denn das gesamte Yaml ist mir ehrlich gesagt viel zu
Serverlastig. Was ich meinte ist mehr die Definition und fixes für das basistemplate.
Beim Cachen denke ich mal wird Smarty genauso jedes template für sich catchen.
Wenn nun das Gerüst immer das gleiche ist fällt hier schon mal wieder etwas Serverlast weg
Man ersetzt ja lediglich immer nur linke + rechte Navigation (widgets) und den content.

Schau dir einfach mal das Gerüst an und die angedachte modul config.
Hier wäre es praktisch wenn man für jede Seite (Modul) evtl. eigene meta verwenden könnte.
Beim einlesen der module config braucht man die '3col' an 'Basic' anzuhängen und hat so den
namen des Basistemplates welches immer im core liegt.

includes innerhalb der templates müsste man doch entsprechend des namens laden können.
z.b.
   - clansuite_.... immer aus core/view laden
   - modulname_... immer aus dem view ordner des modules


gruss
Paul

[Jens-A. Koch]

Nicht unbedingt, man kann doch z.b. die widgets wie sie jetzt auch definiert sind einfach in ein
navigations-template packen und im module ordner unter view ablegen, so wie die show.tpl auch.
In dem Basic template dann einfach includieren im linken oder rechten menü je nachdem.

Ok - dann hast Du Inhalt aus der index.tpl in Untertemplates (index_navigation_left|right.tpl) ausgelagert.

Ich hab derzeit einige Grundannahmen:
a) ein Theme hat immer eine index.tpl, die das Gerüst definiert
b) ein Theme basiert nur auf einem Renderer (keine Durchmischung von Smarty und Xtemplate)

Wenn man jetzt auf Durchmischung aus ist, dann wirds technisch interessant.
Wenn ein Modul Xtemplate einsetzt, dann liefert es einen gerenderten HTML-Baustein für den Maincontent-Platzhalter (bspw. {$content}) zurück.
Wenn das Theme jetzt ein Smarty-Theme ist, dann müsste
a) die Theme-Config müsste sagen, wie der Main-Platzhalter sich nennt
b) und eine Methode in der Basisklasse aller Renderer existieren, für die Zuweisung mittels assign(html-modulcontent => main-platzhalterin)
Im Modul kannst Du auch jetzt schon die Ausgabe mit Xtemplate erzwingen und damit arbeiten. Das Einsetzen als Variable fehlt aber. Höchstens Inhalt auffangen und an Smarty assignen.

Das wäre der Content in der Mitte.
Bleiben noch die Cols.

Ich hab da ne Idee für ein Widget Modul. Nehmen wir mal an, man bindet
{load_module name="widget" action="leftCol"} in der index.tpl ein.
Das würde bedeuten das dort die leftCol.tpl des Widget-Moduls angezeigt wird.
Über das Widget-Modul könnte man dann auch komfortabel die Seitenelemente konfigurieren,
etwa per Drag'n'Drop so wie wir es früher hatten.

Unterschiedliche Layouts würde ich in der theme_config festlegen.

Code:

#Basis-Page-Layout festlegen ( 3col, 2col_left, 2col_right, 1col )
basis_layout = 3col

/theme/frontend/einTheme/basis_layout_3col.tpl

[paulbr]

Der Grundgedanke bei den Basis-Layout ist ja der, das man eben nicht pro theme ein eigenes gerüst hat,
sondenr 1 einheitliches für alles.
Das Gerüst macht ja nix anderes als was der Name schon sagt.
Innerhallb des Gerüstes kann alles ausgetauscht werden.

Ich hatte eigentlich den Gedanken dabei, das Gerüst unabhägig der RenderEngine zu gestalten.
Es ist reine definitionssache sowohl Smarty als auch Xtemplate beizubringen wo was includiert
bzw. geparst werden soll, wie mit kommentare zu verfahren ist etc.

Wenn man trennt zwischen den RenderEngines ist das Basis Gerüst ja auch für jede RenderEngine
in themes/core/rendername/  hinterlegt. Von daher ist es eigentlich nicht Nötig ein Basis Gerüst für
jedes Modul zu erstellen.

Die Methoden der RenderEngines sind ja durch die Renderer Base vorgegeben!
Innerhalb der Renderer können ja soviel eigene funktionen sein wie sie wollen.
Von daher kann man entsprechend die daten aufbereiten und gleich zur Verfügung stellen.
Also ->Display ->fetch ->assign  etc...

So braucht man nach aussen keine grossartigen Veränderungen für die Gestaltung der Templates.
Allerdings wenn man keine RenderEngine eigene Templates mehr benötigt, braucht man auch keine
verschiedenen RenderEngines

Der grosse Unterschied von Smarty zu XTemplate ist einzig der, das Smarty in den Templates
if... else usw. ausführen kann, XTemplate nicht. Das muss im vorfeld bereits beim aufbereiten
berücksichtigt werden.

Ich habe das ja bei meinem cms eingesetzt, die Klasse CModul ist hier für die Aufbereitung und
Ausgabe für alle Module verantwortlich (im Prinzip meine RenderEngine für XTemplate auf PHP4 basis).
Nun nicht direkt, den ich hab da meine eigene TemplateEngine erstellt (CTemplate), abgeleitet von XTemplate. Folgende Struktur im Template ist da möglich:

Code:

    Basisklasse für alle Module

    Die verwendeten Templates müssen folgende Struktur aufweisen, wobei
    Modul durch den jeweiligen Modulnamen zu ersetzen ist.

    <!-- BEGIN: main -->

        <!-- BEGIN: modul -->

            <!-- BEGIN: empty -->
            <!-- END: empty -->

            <!-- BEGIN: GROUP_group_begin -->
                <!-- BEGIN: groupvalue -->
                <!-- END: groupvalue -->
            <!-- END: GROUP_group_begin -->

            <!-- BEGIN: HEADER -->
            <!-- END: HEADER -->

            <!-- BEGIN: DATA{iRow} -->

                <!-- BEGIN: LEVEL{i} -->

                    <!-- BEGIN: ROW1 -->

                        <!-- BEGIN: COL1 -->

                            <!-- BEGIN: {modul_}{template}_begin -->
                            <!-- BEGIN: {modul_}{template}_end -->
                            <!-- BEGIN: {modul_}{template} -->

                                <!-- BEGIN: variable_header --><!-- END: variable_header -->
                                <!-- BEGIN: variable --><!-- END: variable -->
                                <!-- BEGIN: variable_empty --><!-- END: variable_empty -->
                                <!-- BEGIN: variable_begin --><!-- END: variable_begin -->
                                <!-- BEGIN: variable_end --><!-- END: variable_end -->
                                <!-- BEGIN: variable_footer --><!-- END: variable_footer -->

                            <!-- END: {template}_begin -->
                            <!-- END: {template}_end -->
                            <!-- END: {template} -->

                        <!-- END: COL1 -->

                        <!-- BEGIN: COL2 -->

                            <!-- BEGIN: {modul_}{template}_begin -->
                            <!-- BEGIN: {modul_}{template}_end -->
                            <!-- BEGIN: {modul_}{template} -->

                                <!-- BEGIN: variable_header --><!-- END: variable_header -->
                                <!-- BEGIN: variable --><!-- END: variable -->
                                <!-- BEGIN: variable_empty --><!-- END: variable_empty -->
                                <!-- BEGIN: variable_begin --><!-- END: variable_begin -->
                                <!-- BEGIN: variable_end --><!-- END: variable_end -->
                                <!-- BEGIN: variable_footer --><!-- END: variable_footer -->

                            <!-- END: {template}_begin -->
                            <!-- END: {template}_end -->
                            <!-- END: {template} -->

                        <!-- END: COL2 -->

                        <!-- BEGIN: BETWEEN -->
                        <!-- END: BETWEEN -->

                    <!-- END: ROW1 -->

                    <!-- BEGIN: ROW2 -->

                        <!-- BEGIN: COL1 -->

                            <!-- BEGIN: {modul_}{template}_begin -->
                            <!-- BEGIN: {modul_}{template}_end -->
                            <!-- BEGIN: {modul_}{template} -->

                                <!-- BEGIN: variable_header --><!-- END: variable_header -->
                                <!-- BEGIN: variable --><!-- END: variable -->
                                <!-- BEGIN: variable_empty --><!-- END: variable_empty -->
                                <!-- BEGIN: variable_begin --><!-- END: variable_begin -->
                                <!-- BEGIN: variable_end --><!-- END: variable_end -->
                                <!-- BEGIN: variable_footer --><!-- END: variable_footer -->

                            <!-- END: {template}_begin -->
                            <!-- END: {template}_end -->
                            <!-- END: {template} -->

                        <!-- END: COL1 -->

                        <!-- BEGIN: COL2 -->

                            <!-- BEGIN: {modul_}{template}_begin -->
                            <!-- BEGIN: {modul_}{template}_end -->
                            <!-- BEGIN: {modul_}{template} -->

                                <!-- BEGIN: variable_header --><!-- END: variable_header -->
                                <!-- BEGIN: variable --><!-- END: variable -->
                                <!-- BEGIN: variable_empty --><!-- END: variable_empty -->
                                <!-- BEGIN: variable_begin --><!-- END: variable_begin -->
                                <!-- BEGIN: variable_end --><!-- END: variable_end -->
                                <!-- BEGIN: variable_footer --><!-- END: variable_footer -->

                            <!-- END: {template}_begin -->
                            <!-- END: {template}_end -->
                            <!-- END: {template} -->

                        <!-- END: COL2 -->

                        <!-- BEGIN: COL2_empty -->

                            <!-- BEGIN: {modul_}{template}_begin -->
                            <!-- BEGIN: {modul_}{template}_end -->
                            <!-- BEGIN: {modul_}{template} -->

                            <!-- END: {template}_begin -->
                            <!-- END: {template}_end -->
                            <!-- END: {template} -->

                        <!-- END: COL2_empty -->

                    <!-- END: ROW2 -->

                <!-- END: LEVEL{i} -->

            <!-- END: DATA{iRow} -->

            <!-- BEGIN: FOOTER -->
            <!-- END: FOOTER -->

            <!-- BEGIN: GROUP_group_end -->
                <!-- BEGIN: groupvalue -->
                <!-- END: groupvalue -->
            <!-- END: GROUP_group_end -->

        <!-- End: modul -->

    <!-- END: main -->

Wenn ein Modul keine Group|header|footer benötigt braucht man dies im Template nicht angeben.
Hier ist nur eine vollständige Liste der Möglichkeiten.

- Damit ist es möglich, mehrere Module innerhalb eines Templates abzubilden.
   Hierfür ist die Funktion OutputTpl() vorgesehen
   (hier wird dann nur alles zwischen BEGIN: modul und END: modul geparst).

- Soll der Modul die Daten in ein eigenes Template ausgeben, so wird dazu Output() verwendet
  (hier wird alles zwischen BEGIN: main und END: main peparst).

- Empty wird geparst, wenn kein Datensatz gelesen wurde.

- Header und Footer werden nur geparst, wenn Daten vorhanden sind und keine Gruppen verwendet werden.

- ROW1 etc. wird nur dann geparst, wenn Section > 1 ist.
  Wenn Section = 5 ist, dann werden auch 5 ROW Sections vorausgesetzt.
  Ist Section = 1, dann wird nur DATA geparst.
  Zusätzlich zum Block DATA kann pro Datensatz ein eigener DATA Block definiert werden, der an
  Stelle von DATA für den aktuellen Datensatz geparst wird, falls dieser Block vorhanden ist.
  Andernfalls wird für diesen Datensatz DATA geparst.

- Ist ein DATA Block mit der laufenden Datensatznummer vorhanden (z.B. DATA1 für den ersten
  Datensatz), so wird hier für die Ausgabe der Block DATA1 an Stelle von DATA verwendet. So kann
  für bestimmte Datensätze ein anderer Block verwendet werden.

- Für jede Variable kann ein eigener Block angelgt werden, der nur dann geparst wird, wenn die
  Variable einen Wert enthält.
  Weiters wird (sofern die Variable einen Wert enthält) zusätzlich die beiden Blöcke variable_begin und variable_end geparst.

- Wird ein Bild mit PrepareImage() aufbereitet, steht der Pfad+Dateiname auch als variable_encoded zur Verfügung.

- Wird ein Text mit PrepareText() aufbereitet, steht er auch als variable_encoded zur Verfügung.

- Ist in einem Datensatz das Feld 'template' befüllt, wird davon ausgegangen, daß es im Template
  diesen Subblock gibt. So kann für einzelne Datensätze ein eigenes Layout verwendet werden. Das
  Feld template kann aber auch über aTemplates gefüllt werden.

- Ist in einem Datensatz das Feld 'level' befüllt, wird davon ausgegangen, daß es im Template diesen
  Subblock gibt. Diese Funktion kann für die Darstellung hierarchischer Strukturen verwendet werden.

- Für alle Spalten außer der ersten ist zusätzlich ein _empty Block anzugeben, der geparst wird, wenn
  zu wenig Datensätze vorhanden sind, um die Zeile vollständig mit Spalten zu füllen.

- Zwischen 2 Spalten und zwischen 2 Zeilen kann ein BETWEEN Block ausgegeben werden.

Kurz gesagt damit kann man Templates innerhalb Templates genauso wie mehrere verschiedene
Module innerhalb eines templates darstellen.

Wie gesagt es gibt viele Möglichkeiten wie man was nutzen kann.
Man sollte hier mal das für und wieder abwägen.

Das Prinzip des $content von Smarty ist nicht anders als das von XTemplate.
Bei XTemplate parse ich den Content der z.b. in einem anderen template liegt und füge den mittels assign im Basis Gerüst ein. der Content kann eine statische html seite als auch eine dynamisch
generierte sein.
Bei: header|linke spalte|rechte spalte|footer verhält es sich genauso.


Das mit der bestimmung der RenderEngine im module config sollte man machen.

Allerdings sollte auch trotz allem @todo erstmal die Template-Ablage sauber getrennt werden.
So kann man mit dem normalen 'Smarty' weiter entwickeln und nebenbei mit 'XTemplate'
experimentieren
Ich denke sogar das dies das wichtigste ist, je mehr module fertiggestellt werden desto aufwendiger
ist das separieren der templates.

Sonnige Grüsse
Paul

[Jens-A. Koch]

Unabhängiges Gerüst für Rendering
Die Idee mit dem unabhängigen Gerüst hatte ich auch - aber total abgetrennt von Layoutfragen.
Einerseits lässt sich sowas natürlich durch das native PHP Rendering machen.
Andererseits gibts es unter /core/viewhelper/ eine Klasse names "layout.core.php" für das Rendering von Baumstrukturen. Beim Rendering des Baums wird jeder Knoten (Ast; Blatt) durchlaufen und einzeln gerendert. Dabei setzt jeder Knoten eine render() Methode um. Wie dies konkret ausgestaltet ist, ist vom Knoten selbst abhängig. Mit anderen Worten: innerhalb jedes Knotens kann ein anderer Renderer zum Einsatz kommen. Der Inhalt geht zurück in den Baum und sollte unbedingt (teil-)gecached werden,
denn jedesmal die Äste/Blätter zu rendern is technisch möglich, aber performancemäßig ne Katastrophe.

Das Prinzip des $content von Smarty ist nicht anders als das von XTemplate.

Ja, is Platzhalterersetzung.

Allerdings sollte auch trotz allem @todo erstmal die Template-Ablage sauber getrennt werden.

Ist ja eine lange Liste mit Vorschlägen geworden. Ich versuch das der Reihe nach umzusetzen.
Um Pfade für die einzelnen Renderer umzusetzen wird die renderer.base.php verändert.
Bei den Theme- und Module-Templatepfaden wird der Renderer einfach mit in den Pfad aufgenommen.
Der Render ist über die Route verfügbar.
 
Router Uri Problem
Der Dirname wird nun von der RequestUri abgezogen auf localhost-Umgebungen.
Bitte mal testen und rückmelden.

Themes
Die Themes sind nun unterteilt in Frontend, Backend und Core.
Es wurden entsprechende neue Pfadkonstanten eingefügt.

Sonnige Grüsse
Paul

Du hasts gut - Arbeiten wo andere Urlaub machen

[paulbr]

Kleine Dinge: Nichts weltbewegendes nur was mir so aufgefallen ist:

modules/
  in fast allen modulen wird im controller bzgl. Clansuite_Breadcrumb::add(.....) ein '/' vor dem link gesetzt,
  das sollte ohne '/' sein den im breadcrumb.core.php wird der WWW_ROOT (hat ja ein slash am ende)
  vor dem link gesetzt.

Debug
  Was mir aufgefallen ist, das wenn man den Debug abschaltet, gar nichts mehr ausgegeben wird.
  Die Clansuite Webseite wird nur Ausgegeben wenn der Debug eingeschaltet ist.

Teamspeak
  bei Anzeige des ts3 ist der Block grösser als die 'Right Widget Bar', hier stimmt die breiten fixierung
  der Box nicht mehr. bei widget_ts3viewer.tpl sollte das: style="width: 100%;" entfernt werden,
  bei angabe 100% wird die breite immer nach dem Servernamen hier "Clansuite - just an eSport CMS"
  angepasst und so breiter dargestellt als der Rest der Widget Bar.

Render Engine + Lösungsvorschlag
Nochmal zur Trennung der Renderer auch wenn es euch vlt. langsam lästig wird.
Wie Ihr sicherlich aus meinen Posts entnommen habt lege ich persönlich sehr grossen
Wert auf eine möglichst saubere Struktur, jeder hat halt seine Eigenarten
Egal ob irgendwann einmal andere RenderEngines eingesetzt oder hinzugefügt werden oder nicht,
Fakt ist es das hier diese Möglichkeit angedacht und Integriert wurde. Von daher sollte es auch
berücksichtigung finden.

/themes/frontend
  hier braucht es keine berücksichtigung der RenderEngine, man kann ja ein frontend entsprechend
  erstellen.

/themes/backend
  hier braucht es keine berücksichtigung der RenderEngine, man kann ja ein backend entsprechend
  erstellen.

/themes/core
  hier einfach '/view' in '/smarty' ändern.
  So kann jederzeit auch '/xtemplate' oder irgendeine andere RenderEngine einzug halten

/modules
  hier einfach '/view' in '/smarty' ändern.
  /news
  .../controller
  .../css
  .../images
  .../javascript
  .../model
  .../smarty
  .../xtemplate
  .../menu.config.php
  .../menu.info.php
  .../menu.menu.php

Mein Vorschlag der 'Sauberen Struktur', ist die gesamten 'module' (wenn vorhanden) in einen Unterordner zu packen.
z.B. Backend
/admin
.../css
.../images
.../javascript
.../modules
......  /bbcode
.....  ./bugs
......  /-- usw. --
.../index.tpl
.../theme_info.xml

z.B. Frontend (wenn benötigt wird)
/standard
.../css
.../images
.../javascript
.../modules
.../index.tpl
.../theme_info.xml


Zusammenfassung der Änderungen

  clansuite.application.php

        define('ROOT_THEMES', ROOT . 'themes' . DS, false);
        define('ROOT_THEMES_BACKEND', ROOT . 'themes' . DS . 'backend' . DS, false);
        define('ROOT_THEMES_FRONTEND', ROOT . 'themes' . DS . 'frontend' . DS, false);
  in:
        define('ROOT_THEMES', ROOT . 'themes' . DS, false);
        define('ROOT_THEMES_CORE', ROOT_THEMES . 'core' . DS, false);
        define('ROOT_THEMES_BACKEND', ROOT_THEMES . 'backend' . DS, false);
        define('ROOT_THEMES_FRONTEND', ROOT_THEMES . 'frontend' . DS, false);

  und
        define('WWW_ROOT_THEMES', WWW_ROOT . 'themes' . '/', false);
        define('WWW_ROOT_THEMES_BACKEND', WWW_ROOT . 'themes/backend' . '/', false);
        define('WWW_ROOT_THEMES_FRONTEND', WWW_ROOT . 'themes/frontend' . '/', false);
        define('WWW_ROOT_THEMES_CORE', WWW_ROOT_THEMES . 'core' . '/', false);
  in:
        define('WWW_ROOT_THEMES', WWW_ROOT . 'themes' . '/', false);
        define('WWW_ROOT_THEMES_CORE', WWW_ROOT_THEMES . 'core' . '/', false);
        define('WWW_ROOT_THEMES_BACKEND', WWW_ROOT_THEMES . 'backend' . '/', false);
        define('WWW_ROOT_THEMES_FRONTEND', WWW_ROOT_THEMES . 'frontend' . '/', false);

  Die Pfade folgender Scripte (im Anhang):
    - renderer.base.php
    - smarty.renderer.php
    - viewhelper/smarty/function.load_module.php
  anpassen.

  Sonstiges:
  in allen Module-Ordner den Ordner 'view' durch 'smarty' ersetzen
  in 'themes/backend' + 'themes/frontend' die Struktur wie oben erwähnt ändern
  in 'themes/core' den Ordner 'view' durch 'smarty' ersetzen

  in der 'themes/frontend/standard/index.tpl' zeile: 49 ändern
  von:
    {* dynamic include is not working. <link rel="stylesheet" type="text/css" href="{$css}" /> *}
  in:
    <link rel="stylesheet" type="text/css" href="{$css}" />

  Schönheitsfehler in 'modules/teamspeakviewer/smarty/widget_ts3viewer.tpl' ausbessern:
  von:
     <div class="cell1" style="width: 100%;">
   in
     <div class="cell1">

That's all

Die Änderungen bedürfen kaum mehr als 30 Minuten Zeitaufwand!


Performance
  Zur Peformance bzgl. der Core-Optimierung möchte ich grad hier noch etwas anmerken!
  Es ist richtig das man den core jederzeit nachträglich Optimieren und verbessern kann,
  solange die Optimierung sich innerhalb der Core-Funktionen abspielen und keinen Einfluss
  auf Änderung nach Aussen auf nicht Core Klassen u. Funktionen haben.

  Trotzdem möchte ich hier erwähnen, mir ist aufgefallen, das viel zu häufig die konfigurationsdatei
  'clansuite.config.php' ausgelesen wird! Denke das muss gar nicht sein.

  Beim Script tracing ist mir aufgefallen das es unheimlich viele read Operationen dafür gibt.

  In der 'clansuite.application.php' gibt es die Funtion: getClansuiteConfig()
  Wenn nun anstatt z.B.:
     public function __construct(Clansuite_Config $config)
    {
        # Set Reference to Config
        self::$config = $config;

 nur:
    public function __construct()
    {
        # Set Reference to Config
        self::$config = Clansuite_CMS::getClansuiteConfig();

  definiert würde, muss die ini nicht jedesmal neu gelesen werden.
  Dazu kommt damit die ini gelesen wird, werden jede menge andere
  funktionen mit aufgerufen, was ebenfalls zu einen perfomance verlust führt.

  Ich denke das es nicht Notwendig ist die 'clansuite.application.php' andauernd
  auszulesen, den zur Laufzeit werden da ja wohl kaum änderungen gemacht werden
  und wenn doch wird die ini-datei ja jedesmal neu in der Clansuite_CMS ausgelesen.


Bitte nicht an der Formatierung der Scripte im Anhang stören lassen.
Da ich in der Programmierung nicht mit einer IDE arbeite sondern nur mit einem Texteditor,
ist es so für mich Übersichtlicher und das gesuchte schneller auffindbar.
Deshalb verwende ich Tab-Einzug anstatt leerzeichen und hebe die Funktionen
durch //---------------- hervor.

Du hasts gut - Arbeiten wo andere Urlaub machen

Nun Arbeiten muss man trotzdem, allerdings ist es schon erheblich angenehmer,
Morgens aufzustehn und die Sonne scheint 

gruss
paul

[Jens-A. Koch]

Vielen Dank! Das find ich super, dass Du Dir die Arbeit machst und Änderungen lieferst.

Clansuite_Breadcrumb::add(.....) ein '/' Slashes entfernt.

Clansuite Pfadkonstanten Sind eingefügt/geändert.

Teamspeak Geändert widget_ts3viewer.tpl.

Debug
  Was mir aufgefallen ist, das wenn man den Debug abschaltet, gar nichts mehr ausgegeben wird.
  Die Clansuite Webseite wird nur Ausgegeben wenn der Debug eingeschaltet ist.

Jupp. Das kommt von den nicht auskommentierten Clansuite_Debug::firebug() oder printR() Aufrufen im Router und quer durchs System. Die Clansuite_Debug wird nur geladen, wenn DEBUG true. Die Fehlermeldungen findest Du bei deaktiviertem Debug Modus in /logs/clansuite_errorlog.txt.

Submodule
Der folgende Abschnitt ist aus Deiner smarty.renderer.php #249ff.

@todo: submodul folder in module
       * Bei grösseren Modules-Projekte e.g. Auktionen, Online-Shops macht es Sinn
       * innerhalb des Modules weitere Unter-Ordner der Übersichtlichkeit halber anzulegen
       *  Namensgebung für SubFolder e.g.  getSubFolderName();  setSubFolderName()
       *  Ordner in .../modulname/ auslesen wenn vorhanden in template_dir integrieren
       *     "/themes/backend/theme_of_user_session/smarty/modulename/subfoldername/"  @todo
       *     "/themes/frontend/theme_of_user_session/smarty/modulename/subfoldername/"  @todo
       *     "/modules/modulename/view/smarty/subfoldername/"  @todo

Submodules werden im Bereich /controller mittels des Suffix unterschieden.
1) name.module.php ist ein normales Module - Frontend. Tpl = action_methodenname
2) name.admin.php ist immer das Backend des Moduls. Tpl = action_admin_methodenname
3) name.xy.php ist derzeit ein Submodul. Tpl = action_xy_methodenname
Submodule sollten eigentlich ganz rausfliegen. Dabei gibts natürlich das Problem mit dem action_admin... bisher ungelöst. Submodule sind nicht im Einsatz. Wie es hier weitergeht kann ich im Moment nich sagen.
Zwischenzeitlich hatte ich die Idee, einfach einen Verzeichnis /plugins anzulegen und die abgelegten Plugin_Actions per Decorator dem Module hinzuzufügen.
Insoweit kann man nochmal unterscheiden zwischen ganzen Submodulen und wohlmöglich "kleineren" Plugins.

Renderer Verzeichnisstruktur
Ich werde die /view Verzeichnisse drin lassen und ein jeweils ein Unterverzeichnis mit dem Renderernamen einfügen.
Modul Templates => /modules/module_name/view/smarty
Core Templates => /themes/core/view/smarty
Dann kann man bequem auch reine PHP-Tempates in /themes/core/view/php ablegen, ohne sich fragen zu müssen was das eigentlich ist.
Ist entsprechend geändert. Durch die Dateibewegeungen sind wahrscheinlich viele Image/Css-Pfade anzupassen.

Die Pfade im Renderer Smarty und in jedem anderen Renderer werden nun über die RendererBase-Methoden getModuleTemplatePaths() und getThemeTemplatePaths() ausgeliefert.
Vorher waren die Pfaddefinitionen sowohl in Smarty als auch im RendererBase enthalten.
Diese Dopplung wurde aufgehoben. Ich hab also Template-Existenz-Prüfung und Arraydefinitionen voneinander abgetrennt. Dadurch sind die Arraydefinitionen wiederverwendbar. 

Bei mir läuft das System mit den neuen Pfaden.
Sieht gut aus, und macht einen strukturierten Eindruck
Bitte mal testen...

Offen sind nun noch "Staging" und "nur einmal Config laden".

Grüße Jens

P.S. jQuery Popup ist in einem neuen Thread gelandet. Schau ich mir morgen mal an, wie man das hinbekommt.

[Jens-A. Koch]

Läuft das System nach den letzten Änderungen?

"nur einmal die Config laden"
Keine Ahnung wie ich dazu gekommen bin, den Constructor für das Laden zu verwenden.
Komme mir total blöd vor. Was ich dabei noch viel schlimmer finde: ich hab das ständige Laden gar nicht bemerkt. Wie hast Du das rausbekommen Paul?

Offen sind noch Dein "Staging" Vorschlag und das XTemplate-Theme, sowie die Initialisierung der RenderEngine im Dispatcher mittels der Daten vom ausgewählten Theme. Und gemäß Roadmap gehts weiter mit Gettext.

Gruß Jens

[paulbr]

Hallo jens

ich habe das aktuelle system ohne installation sofort zum laufen gebracht!

Das mit den popup's und smarty caching funktioniert noch nicht.
Im gegenteil, vor den änderungen konnte ich ein eigenes Layout-Template
in modules definieren, komischerweise wird das jetzt zwar auch geladen, aber es erfolgt
keine Ausgabe mehr. Ich kam noch nicht dazu, nachzuvollziehen an was das liegt.
Ein Aufruf mittels des standard Layout-Template funktioniert.

...ich hab das ständige Laden gar nicht bemerkt. Wie hast Du das rausbekommen Paul?

Ich habe mir eine Script Tracing Funktion eingebaut, um nachzuvollziehen was wann und wie häufig
durchlaufen wird. Hier kann man den grad der verfolgung selbst bestimmen, indem man ebend das
was unnötig ist zu verfolgen, einfach weglässt.

Im Anhang hab ich dir mal das snippet gehängt, habe das in der clansuite.application.php bei mir
eingebaut gehabt.

Dann einfach in jede Funktion die man überwachen will:
 - if( true === TRACING ) self::addTrace( debug_backtrace() );
    (innerhalb der clansuite.application.php)
   bzw.
 - if( true === TRACING ) Clansuite_CMS::addTrace( debug_backtrace());
     (in den anderen Files)

einfügen.

Je nachdem wo ich einen cut brauche, oder am ende in der function shutdown()
dann die Ausgabe:

  # Programmausführung abbrechen und Ausgabe des Script Tracing
  if( true === TRACING ) { Clansuite_CMS::getTraceOutput(); exit; }
  bzw.
  if( true === TRACING ) { self::getTraceOutput(); exit; }

Naja die Formatierung der Ausgabe ist nix optimales, soll ja auch nur einen Debug-Zweck erfüllen.

Wenn man das Script Tracing nicht haben will kann man das global in der clansuite.application.php
mittels der variablen:  private static $tracing = false dann ausschalten.

Hier noch zu erwähnen wäre, das man an dem addTrace( debug_backtrace())
noch parameter anhängen kann.
z.B.

public static function loadViaMapping($classname)
{
   if( true === TRACING ) Clansuite_CMS::addTrace( debug_backtrace(),$classname );
   bzw.
   if( true === TRACING ) Clansuite_CMS::addTrace( debug_backtrace(),'Class: '.$classname );

so sieht man nicht nur das die Funktion aufgerufen wurde, sondern auch gleich noch wie der
Parameter ist.

Submodule
In dem Abschnitt den du ansprichst, spreche ich nicht von Submodulen, sondern
von Subfolders.

Das dient der Übersichtlichkeit, wenn man ein grösseres Modul hat.
Es ist zweifelsfrei übersichtlicher dann die Templates in Unterordner zu packen, getrennt nach
ihrem Zweck, als 30 templates im view ordner zu haben.
z.B.

/modules
   /auction
      /controller
      /model
      /view
         /smarty
             /item
                /item
                   action_........
                   action_........
                   widget_........
                /forms
                   action_........
                   action_........
                   widget_........
usw.

Das ist wesentlich übersichtlicher als alles in einem ordner zu packen.
Das meinte ich in dem besagten Abschnitt.
Und ob dann Subfolders vorhanden sind und wie die heissen, könnte man in die config
so wie die widgets packen.
Dann eben bei der ->template_dir definition diese mit einlesen, wenn welche vorhanden sind.

Das ist aber nichts was aktuell berücksichtigt werden soll oder muss, ist nur ein @todo Vorschlag.

Offen sind noch Dein "Staging" Vorschlag und das XTemplate-Theme......

Auch das ist ja nichts was unmittelbar von wichtigkeit ist.
Wichtiger als Staging und XTemplate sehe ich andere Dinge, unter anderem das Rechte-System
und Userverwaltung.

Popup
Nochmal wegen dem Popup, der Grund warum ich mich damit mal beschäftigt hatte ist der,
mir gefällt irgendwie der Footer mit dem Copyright und logo in dieser Form nicht so.
Ich dachte mir, eine vernünftige Open-Source-Software sollte Infos für alle zur Verfügung
stellen.
Deswegen wollte ich mal ein klassisches About erstellen, welches in einem Popup angezeigt wird.
Ich habe das mal für die alte Clan Seite meines Sohnes gemacht, schau es dir mal an:
http://wow-rabenblut.de/
Am Fuss der Seite klick auf "Info".
Wobei hier noch ein Tab für die GPL-Lizenz angehängt werden sollte, welche als Textdatei eingelesen
und in dem tab pupliziert wird.
Die Module sind eh in der DB eingetragen, das gleiche könnte man für die Themen machen, bzw. die xml datei entsprechend auslesen.

Da man ja nicht alles sieht und fertig ist, kann man sich als aussenstehender mal ein Bild machen,
über Module, Themes, was es gibt und der Versionsstand etc.

Gettext
Du meinst damit, die languages files für die ganzen Module zu erzeugen, welche noch nicht
existieren?
Poedit liest das doch aus den Scripten aus, ist halt ne reine Fleissarbeit, diese dann zu übersetzen 


gruss
paul

Nachtrag
Die Breadcrumbs funktionieren nicht mehr!
Du hast die Parameter von ?mod=...&action=... auf ?mod=...&page=... geändert.
Allerdings nur bei einzelnen Seiten, die auch angezeigt werden.
Der Parameter: action=... funktioniert nicht mehr, weshalb nur noch Exceptions
geworfen werden.

[Jens-A. Koch]

Hallo Paul, Herzlichen Glückwunsch zum Geburtstag!

Breadcrumbs
Ja, ich habe die Linkangaben auf Slashes umgestellt und bin mit nem RegExp drüber gegangen.
Kann gut sein, dass ich ein paar Links verfehlt habe oder falsch umbenannt wurde.
Das "&page=" kommt höchstens bei StaticPages vor. Bitte mal eine Exception-Meldung posten oder screenshooten.

Popup / About
Das About-Popup auf der Gilden-Seite sieht nach Eqdkp-Plus ( http://www.eqdkp-plus.com/demo/ siehe Footer) aus. Ein Popup in dieser Richtung sollte sich machen lassen. Dieses Tab-Script haben wir auch am Start - es wird im Control-Center About eingesetzt; aber mit jQuery gehts sicherlich auch. Ich werde dazu ein About-Widget dem Index-Modul hinzufügen. Das kann man dann als Seitenelement einbinden - da gibts dann nur ein Logo und den Link für den Popup.

Tracing
Füge ich als Erweiterung der Debug-Klasse hinzu.

Gettext
Das System kommt später ohne PoEdit und msg* Shell-Kommandos aus. Eigentlich gehts nur darum den Scanner für die Translate-Tags fit zu machen und ein Modul mit Tabellendarstellung für die Translate-Elemente. Das soll erstmal nur soweit laufen, dass man das System per Knopfdruck immer mal wieder auf neue Translate-Tags scannen kann, um die Language Datei vom Core upzudaten. Für die Module wirds dann auch laufen. Das Übersetzen können dann die Nutzer machen.

Submodule / View Subfolder
Ah ok. Missverständnis. View Subfolder machen natürlich Sinn, aber den Grad an Komplexität im View haben wir erstmal noch nich erreicht. Für die (generierten) Forms könnte man eine HTML Ablage in nem eigenen Folder im View andenken (quasi Formcaching). Ist bislang nur ne Idee..

User-Verwaltung / Rechte-System
Also die User-Verwaltung ist deutlich einfacher als das Rechte-System.
- User: Account anlegen und löschen, User-Profil-Bearbeiten
- Rechte: Reaktivierung der Anmeldung (Session für einen registrierten User), dann das ACL-System, die entsprechenden Hooks, um Rechte zu prüfen und die Rechteprüfung, vor dem Dispatcher forward().

Soviel erstmal, Jens