"Templatesystem" so okay?

[ghostgambler]

OffTopic:

---

Original geschrieben von onemorenerd
na irgend ne Zahl größer Null

man kann gucken in wieweit andere Seiten schneller sind, z.B. http://animexx.4players.de/forum/?forum=1&kategorie=12 ich sehe da, dass da ungefähr soviel passiert, wie auf meiner Forenübersicht, aber ich sehe auch, dass das gesamte Skript wesentlich langsamer ist, ungefähr 0.4 Sekunden...abgesehen davon, dass der Server mehr zu leisten hat (okay, dafür hat mangacarta nichtmal annähernd soviel Power zu verfügung), ist das Skript auch an sich langsam, weil der Programmierer da eine Datei einbindet, die auf einem Netzwerklaufwerk liegt (Dateisystem vergessen ...kannte ich aber nicht), warum das getan wird konnte mir der andere Programmierer nicht sagen

---

[onemorenerd]

OffTopic:

---

man kann gucken ... schön und gut, aber wen außer dir interessiert das denn?

---

[ghostgambler]

OffTopic:

---

Original geschrieben von onemorenerd
man kann gucken ... schön und gut, aber wen außer dir interessiert das denn?

Wenn jeder so denken würde, dann könnte ich es auch weg lassen.
Weil ich dann nicht mit anderen Seiten vergleichen könnte

---

[daniel987]

Also wies aussieht, muss man Schleifen momentan noch so eingeben weil ich das Replacen nicht hinbekomme. Wird jetzt wahrscheinlich auch doch noch en bisschen dauern, weil jetzt noch was privates dazwischengekommen is. Sorry.

[mrhappiness]

Kein Problem, hab derweil 'ne andere Engine eingebaut; die erste, die per Formular gekommen ist *freu*


Bin aber nach wie vor gespannt auf deine

[daniel987]

Ich hab dir jetzt doch mal eine Alpha Version meiner Engine zu kommen lassen. Die Cache Funktion habe ich aber berreits implentiert sie würde bei deinem Pseudo Code auch berreits in Kraft treten. Genaueres steht dann in der E-Mail.

[mrhappiness]

Bin dabei mich durchzuwühlen, deine Cache-Funktion werde ich aber wohl deaktivieren (bzw. einen Extra-Benchmark machen für Engines die das können)

Grund: Du speicherst ja die komplette Ausgabe, die an den Browser geschickt wird und innerhalb deines Cache-Zeitraums kannsich an den ggf. dynamischen Daten soviel ändern wie nur irgend geht, der Benutzer bekommt nichts davon mit.

Wie gesagt: Das Cachen ist erstmal deaktiviert, genutzt wird aber natürlich weiterhin weiterhin die Prüfung, ob erneut kompiliert werden muss oder ob sich deine Engine die Zeit sparen kann.

Kann ich bei deinem jetztigen Cache-System denn noch die von dir erwähnten variablenTeile ins Template einbauen? Es wird doch alles gecached, oder?

Ach ja: Noch ist das nur lokal bei mir, kannst dir ja überlegen, wann du was online sehen willst:
- Variablenersetzung?
- Schleifen? (Jetzt? Später, wenn das Replacen klappt?)
- Alles erst später, wenn's fertig ist?

--------------

Tipps:

echo "$varname"; 

ist nicht schön, lass die $ doch weg, oder warum sind die da?

Du solltest irgendwie dafür sorgen, dass nicht vorhandene Variablen keine Fehlermeldungen auslösen.

echo "$mich_gibts_nur_im_template_mir_wird_aber_kein_wert_zugewiesen"; 

[daniel987]

Na die $ Zeichen sind da weil so gut wie immer nur die Templates vom Compile Cache geladen werden und ich nicht was weis ich wie oft str_replace() für jede Variable einmal einzusetzen brauche. Außerdem kann es ja sein, das Variblen assigned wurden die gar nicht im Template vorkommen für dies würde dann normal auch extra nochmal str_replace aufgerufen.

Das man beim Cachen gar nichts mehr verändern kann stimmt so nicht, ich bin halt davon ausgegangen, das man die wichtigen Variablen bei
display() als zweiten Parameter in durch | getrennte Gruppen übermittelt. Und dann immer wenn sich was ändert, die jeweilige Cache Gruppe leert.
Muss man sich halt bei der Planung eines Projektes überlegen welche Variablen das sind, wenn man faul ist, kann man auch einfach den QUERY_STRING ordnen und dann als Cache string verwenden.
Bei mir habe ich das von Anfang mit eingeplant, da ich komplett alles für Mod_Rewrite optimiert habe, gibt es nur 7 immer gleichnamige Variablen die per get Übertragen werden können sie zu ordnen ist natürlich ein leichtes.
Achso Sortiereinstellungen und so ordne ich und füge sie als letzte Gruppe an, somit ist jede Möglichkeit abgedeckt.
Wenn man jetzt noch die is_cached() Funktion implentiert, und dann noch viele Querie etc einsparen kann, gibt das einen performance Vorteil der nicht zu unterschätzen ist.

Achso das mit der Fehlermeldung habe ich noch vergessen danke für den Hinweis ich werde dann noch eine Debug Variable einführen mit der Error Reporting abgestellt wird.

ps.: Die maximal Performance erreicht man nach meinen Messungen & solange viel verschiedene Cache Gruppen da sind, wenn man sich einen mysql Cache Handler schreibt und dann für jede Cache Gruppe ein eigenes Unique Feld festlegt (um REPLACE INTO zu benutzen), allerdings erhält man dann halt schnell große Datenmengen weshalb es optimal wäre, wenn man noch gzip oder zip oder sowas anwenden könnte (habe ja hier schonmal eine Anfrage diesbezüglich gestellt).

[mrhappiness]

Original geschrieben von daniel987
Na die $ Zeichen

sorry, meinte natürlich die "

Das man beim Cachen gar nichts mehr verändern kann stimmt so nicht, ich bin halt davon ausgegangen, das man die wichtigen Variablen bei
display() als zweiten Parameter in durch | getrennte Gruppen übermittelt. Und dann immer wenn sich was ändert, die jeweilige Cache Gruppe leert.

das wäre dann in einer späteren version drin?
inklusive steuerung im template, in dem man dann festlegen kann, was zu welcher gruppe/welchen gruppen gehört?

Achso das mit der Fehlermeldung habe ich noch vergessen danke für den Hinweis ich werde dann noch eine Debug Variable einführen mit der Error Reporting abgestellt wird.

oder mit isset prüfen, bleibt dir überlassen

ps.: [...]

vorschlag meinerseits:
beschäftige dich mit dem einbauen von schleifen und überlege dir, wie ausgefelt dein cache-system sein soll/kann.

wenn du das hast, kannst du dich mit den verschiedenen "cache-handlern" befassen, schließlich geht's ja erstmal um die grundlegende funktionalität an sich (deine Engine kann Schleifen; deine Engine kann cachen, ...) und danach um die anzahl der verschiedenen ausprägungen (deine Engine kann den Cache in eine Datei schreiben, deine Engine kann den Cache in eine Datenbank schreiben, deine Engine kann den Cache komprimiert speichern, ...)


Wo wir gerade dabei sind:
Wenn du die Sache mit dem Cachen in der DB verwirklichen willst, solltest du folgendes bedenken:

Wenn ich mit einem Cache arbeite, dann doch deswegen, weil ichmir die ganzen aufwendigen Datenbankoperationen sparen, ich prüfe also im Skript zuerst, ob ich die Daten neu ermitteln muss.
Wenn ich merke, dass der Cache noch aktuell ist, muss ich bei dir dann trotzdem eine Vebrindung zur DB aufbauen und den Cache lesen, ein Teil dessen, was ich mir gespart habe, kommt also durch die evtl. durch die Hintertür wieder rein.

Wenn du den Cache in die DB schreiben willst, musst du deine Template-Engine noch um einen DB-Layer erweitern. Warum sollte derjenige, der mit deiner Engine arbeitet, nicht so mit der DB arbeiten, wie er es schon die ganze Zeit tut?

Vorschlag:
Die 3 Funktion is_cached(), store_cache() und read_cache() sollten callbackfunktionen sein. Du bietest in der Template-Engine selbst nur eine "Schnittstelle"

function user_defined_is_cached($tpl, $cache_expiration, &$engine) {
  //Hier kann der Entwickler, der deine Engine nutzt, sich austoben
  //$result = true oder false
  return $result;
}

//Zuweisung im Skript
$tpl->set_is_cached('user_defined_is_cached');

//Die Methode set_is_cached
function set_is_cached($func = NULL) {
  if (is_string($func)) {
    $this->is_cached = serialize(strtolower($function));
  elseif (is_array($function))
    $this->is_cached = array_map('strtolower', $function);
  else
    $this->is_cached = array($this, 'default_is_cached_handler');
}

function check_is_cached() {
  if (is_callable(unserialize($this->is_cached), false, $is_cached))
    return $is_cached($this->tpl_name, $this->cache_expiration, $this);
  return false;
} 

so irgendwie könntest du's machen, damit überlasst du's dem nutzer deiner engine, wie und wo er seine caches verwalten will

[daniel987]

Nein das mit den Cache Gruppen ist schon jetzt drin. geht auch in dem Beispiel schon gib mal testweise als zweiten Parameter 'sport/baskettball' an, und schau dann in den Cache Ordner . Oder reden wir jetzt aneinader Vorbei, ich versteh nicht ganz wie man die Cache Gruppe im Template festlegen soll, woher soll denn der Designer wissen welche Variablen der Coder verwenden wird? Außerdem kann er ja Ordner in seinen Templates verwenden, diese werden beim cachen natürlich berrücksichtigt.

Im Ordner modules befinden sich doch die ganzen Handler mit diesen lässt sich das komplette Verhalten steuern. Wenn jemand mit seiner bisherigen DB abstraktion arbeiten will okay dann schaut er sich einfach eines der berreits vorhandenen Module an, und und schreibt sich ein eigenes. Anschließend brauch er bloß noch beim Initalisieren den Namen seines Cache Handler Modules oder seines Template Hander Modules angeben.

Im Cache Handler Modul befinden sich auch genau die 3 Methoden die du benutzerdefinieren willst. Ich dachte halt das es so besser ist, da so auch andere Entwickler leicht Erweiterungsmodule erstellen können die auch von unerfahrenen Nutzer leicht eingebunden werden können.

Wenn ich die Variablen mit isset überprüfen würde, dann wäre kein Debug Modus mehr möglich (es sei denn man würde den Compile Cache neugenerieren), deshalb finde ich es eigentlich so ideal.

Die "" Zeichen könnte ich noch entfernen mal schauen.

Nochmal zu dem Cache System, wenn man seine Seite Modular aufbaut (was ja momentan sowie Standard ist ) dann kann man so (so mach ich das) eine Methode basteln die statisch aufgerufen werden kann einen für das Modul benötigten Cache String ausgeben. So braucht man falls schon eine gecachte Version existiert nicht mal das eigentliche Modul initialisieren und das bringt einiges. Davon abgesehen benötigt die is_cached Methode nun wirklich nicht lang in dem Verhältniss was sie einbringt.

[mrhappiness]

Ich habe das so verstanden (Beispieltemplate):

{cachegroup userlist}
{loop users}
  {if _first}<ul>{endif}
    <li>{nachname}, {vorname}</li>
  {if _last}</ul>{endif}
{endloop}
{endcachegroup}
Heute ist der {_date dateformat "d.m.Y"}, es ist {_time dateformat "H:i:s"}

Die Benutzerliste wird einmalig generiert (ist ja in der cachegroup), der Teil untendrunter wird jedesmal neu ermittelt.
So würde es beim ersten Aufrufen der Seite etwas länger dauern, da die Liste mit Benutzern aufgebaut wird, bei jedem folgenden Aufruf, muss die Schleife nicht mehr abgearbeitet werden.

Wenn das so sein soll, muss der Templateschreiber ja die Möglichkeit haben, zu definieren, was im Cache landen soll und was nicht.

Oder wie hast du das gemeint?



Zu deinem modules-Ordner:
Ich finde die Namensgebung etwas ungünstig.
Vorschlag: Lege Ordner für jede Art von Modul an

• modules/cache
• modules/modifiers
• ...

Dann kannst du das schonmal besser ordnen.
Die Dateien würde ich so nennen: dt<version>_<function>_<name>.php (dt = Daniel Template)
Beispiel: dt0-1_cache_file.php, dt0-1_modifier_dateformat.php, ...

Für die Funktionsnamen gilt das gleiche.

In deiner Template-Engine definierst du den Versionsstring, der genutzt werden soll (kann ja sein, dass 0.5 beta mit dem gleichen Funktionsaufbau zurechtkommt wie deine 0.1 alpha