Beiträge von Alvaran

    Hallo Ulle, danke für die schnelle Antwort.

    Erstmal, "single Session" eine einzelne Sitzung, also ein ganz normaler Zugriff auf das CMS.

    PHP 5 ist ja nun Objektorientiert. Ein Segen für uns Entwickler. Wir können Vererben, Ableiten, Überladen. Naja, Überladen geht bei PHP noch nicht, soll es aber bald geben. Der Fluch der Geschichte ist der Speicherverbrauch. Es wird nicht nur das Objekt geladen, sondern alle seine Eltern (Parents).

    Dann nutze ich gerne die Smarty-Engin ( Die Dokumentation dazu ) um den Designern eine Werkzeug in die Hand zu geben ihren Part zu machen. Die Datenbank soll über eine Abstraktionsschicht angebunden werden - ich nutze adodb_lite, unterstützt MySQL, SQLite, Postgres, ORACLE, MSSQL und noch weitere die mir jetzt nicht einfallen -, damit ich nicht auf eine SQL-Datenbank beschränkt bin. Denn ich weiß nie, was der Kunde an Infrastruktur hat.

    All das frist Speicher ohne Ende.

    Währe schön zu sehen, wenn jemand einfach mal einen anderen Ansatz findet. Als Entwickler ist Man(n) ja ab und an mal ein bisschen Blind. Hat eine Lösung gefunden, aber vieleicht gibt es eine viel bessere.

    Ich weiss nicht, wie wichtig das Aussehen und die visualisierte Sprache ist? Für mich ist immer die Funktion das wichtigste. Wie verhält sich das CMS unter Last? Was für ein Speicherrbedarf hat das CMS an sich, was eine single Session? Wie Modular ist es aufgebaut, sprich hat es ein Plugin-Interface? Ist es als reines Contentsystem gedacht oder unterstützt es auch interaktive Blocks?
    Zur Speicherung der CSSs:
    Ich persönlich verwende CMS-MadeSimple, ein OpenSource CMS, als Framework. Da habe ich die Möglichkeit, entweder einen Verweiss auf ein Include, oder das Include selber in der Datenbank zu speichern. Der Vorteil des Verweises ist gerade in der Entwicklung. Schnell mal was in der Datei geändert und geschaut, was raus kommt. Wenn eine Sache abgeschlossen ist, wird sie in die Datenbank importiert. Damit weiss ich, das ich mit den Datenbank-Sicherungen auch alle Includes mitgesichert habe. Sprich, Datenbank bring Sicherheit.
    Wie die Sache realisiert wurde, kannst du dir ja ansehen, wenn du dir die Quellen runterlädst.

    Download Quelltext CMS-Madesiple

    Mal noch ein Gerücht streuen will. C# ist das bessere Delphi.

    Nach meinen Infos (die nicht unbedingt richtig sein müssen, ansonten währen es Wahrheiten und keine Gerüchte) ist einer der Chefentwickler von Delphi zu MS gewechselt. Erster Schritt war, Java und Delphi zu analysieren und stärken und schwächen zu suchen. Daraus ist ersteinmal die CLR (Common Language Runtime) entstanden. Die ersten beiden Sprachen, die in der Lage waren IL Assemblys für die CLR zu erstellen waren VB .Net und C#. Beide erzeugen fast identischen IL Code und es liegt am Geschmack der Entwicklers, was er nutzt. Mittlerweile gibt es unheimlich viele Sprachen, die in der Lage sind IL Assemblys zu erzeugen.

    Den riesen Vorteil den ich in IL-Sprachen (.net/mono) sehe ist, das ich die Sprache nehmen kann, die für meine Schicht die richtige ist. C++ .net wenn ich Sachen implementieren will die Krank sind, da ich selber aus der C++ Ecke komme, kommt das ab und an mal vor. F#, Cobol für Buisinessschicht. Die Presentationsschicht würde ich immer mit C# machen. Das liegt aber daran, das ich die Sprache mittlerweile richtig mag.

    Oh ha, na dann lade ich mir mal alle Parameter beim Start und schön ist es.

    Threadsicherheit ade, über Multiuser denken wir erst garnicht nach.

    Die Lebensdauer einer Variable ist so kurz wie möglich zu halten, weil sie ist variabel, sprich, sie kann sich ändern. Und das nicht nur durch mich. Folglich, wenn ich sie brauche, wird sie gelesen, wenn ich sie geändert habe, sofort weggeschrieben. Und jetzt sind wir wieder bei den gettern und settern.

    Damit habe ich nicht nur die Möglichkeit, 'ne Plausi zu machen. Ohne nachdenken kann ich bei einer geebten, includierten Klasse die Variable nutzen. Das Lesen und Schreiben, woher und wohin auch immer, implementiere ich in den Properities.