Hallo,

@alcaeus: Nicht nötig, ist auch nicht so wichtig.

@himitsu: Ich weiß gar nicht wie man auf 200-300 MB pro CMS kommt. PHP-, HTML-, JavaScript und CSS-Code ist klein und lässt sich über Packer sehr stark komprimieren. 200-300 Megabyte sind wahrscheinlich noch hunderte unnötige Design, Dokumentationen, Bilder, usw. Scheue dich nicht dafür für dein "kleines CMS" 200 PHP-Dateien und Ordner zu erstellen. Ein inode auf der Festplatte kostet nicht die Welt an Speicher. Der Aufwand eine viele tausende Zeilen große Datei zu managen schon.

Und übrigens: OOP ist für mich nicht die Verwendung der MySQLi-Klassen. OOP ist, wenn du's selber machst. Viele schöne Klassen, Interfaces, Vererbungen, Abstraktionen oder finale Klassen. Sowas macht den Reiz aus.

Ich kann dir als Referenz auch noch das Zend Framework empfehlen. Jenes ist zwar sehr langsam, als technischer Ansatz aber sicher einen Blick wert. Deren API, die abstrakte Implementation und das gesamte Konzept ist sehr gut Durchdacht und meiner Meinung nach echt lobenswert.

Liebe Grüße,
Valle

OK, das war vielleicht ein bissl übertrieben, aber es gibt ja einige "Webseiten", wo das ganze System, alleine schon in der Grundausstattung, mindestens 30-50 MB belegte (jedenfalls war das letztes Jahr noch so ... hab grade nachgesehn und dieses komische Joomla scheint geschrumpft zu sein )


Das php = PHP4 wurde damals so belassen, als PHP 5 eingebaut wurde, damit es halt keine Probleme mit alten Sachen gibt und alles Problemlos weiterlief.

Für den Webspace ist eigentlich schon lange eine Umstellung geplant.
Erstmal sehn, ob/wie ich wenigstens einige der alten Sachen so umstelle, daß sie unter PHP 5 laufen würden ... ist aber nicht mehr viel Altes vorhanden ... das ändern der Serverkonfiguration für .php = PHP5 wäre schnell erledigt, aber ich wüßte nicht, was an index.php5 soooooo schlimm sein sollte?
(wäre doch letztendlich eh hinter 'nem ModRewrite verschwunden )

Zitat:

OOP ist für mich nicht die Verwendung der MySQLi-Klassen. OOP ist, wenn du's selber machst.

ähhhhhh?

Ich lerne grade mal die Anfänge von PHP 5 kennen ... ist nicht grade einfach das Ganze.





Aber über meine Session/Keks-Verwaltung sagt keiner was :heul:
Wisst ihr wie schwer das war die Session/Kese nur zu erstellen/verwenden, wenn die wirklich benötgt werden? (nach dem Einloggen oder Umstellen der Anzeigesprache)
Also standardmäig bekommt man von dem Script keinen Keks verpaßt.

Das ist mein Beitrag zur Entmüllung des Internets/Browsers.

Das ist auch nicht so sehr verschieden vom OOP anderer Programmiersprachen (klar gibt es auch hier Ausnahmen).
Es gibt aber einige gute Tutorials bzgl. OOP in PHP5. Vielleicht ist das hier einen Blick wert.

Meinen Vorrednern kann ich mich anschließen.
Gute Ansätze hast du in deinem CMS, aber man kann noch viel machen, um es zukunftsfähiger auszurichten.

Hätte da noch eine Verständnisfrage.

Ich weiß zwar, daß es so richtig ist, aber ich versteh nicht ganz warum.
Es steht auch überall erklart, daß man es so macht ... nur halt immer ohne Begründung.

Es geht um überschriebene Methoden und den Aufruf der Originals (quasi delphis Inherited)

markieren

PHP-Quellcode:

function MyMethod() {
  ...
  parent::MyMethod();
}

Im Grunde ist es ja so:

markieren

PHP-Quellcode:

Class::StaticMethod();
Object->Method();

, also müßte ich doch theoretisch eigentlich parent->MyMethod(); aufrufen?

Für die eigene Klasse gibt es ja auch self::StaticMethod(); und $this->Method(); ,
aber für parent:: scheint es kein $parent-> oder Ähnliches zu geben.

Nja, es funktioniert ja, egal ob die Methode nun statisch ist oder nicht,
aber ich find's einfach nicht logisch.

Willkommen in der Welt von PHP. Da ist schon mehr unlogisch.
Aber ja, der Aufruf einer Funktion der Parent-Klasse wird mit parent::foo() erledigt. Dies gilt allerdings nur, wenn du foo() ueberschrieben hast und das Original aufrufen willst. Alle anderen Faelle kannst du mit $this->foo() abdecken.

Greetz
alcaeus

PS: ich weiss nicht was passiert wenn du parent::foo() ausserhalb von foo() aufrufst. Wenn du das machen musst, solltest du schleunigst den Code schreddern und von vorne anfangen.

Zitat von alcaeus:

Aber ja, der Aufruf einer Funktion der Parent-Klasse wird mit parent::foo() erledigt. Dies gilt allerdings nur, wenn du foo() ueberschrieben hast und das Original aufrufen willst. Alle anderen Faelle kannst du mit $this->foo() abdecken.

Das ist schon klar und für genau für solche Fälle nutze ich es auch.

hab ja nun 'ne Menge OOP-Zeugs und vorallem Vererbung verbaut,
da ist sowas ja wohl nützlich/angebracht

Zitat von alcaeus:

PS: ich weiss nicht was passiert wenn du parent::foo() ausserhalb von foo() aufrufst.

also ich kann auch in "bar" parent::foo() aufrufen (wenn Beide oder mindestens foo überschrieben sind)

schon komisch, daß alle Foo/Bar für ihre Beispiele nutzen

Wie gesagt, extrem schnelle Ausführungsgeschwindigkeiten werd ich wohl eh nicht, für meine Zwecke, benötigen.

Ich glaub ich hab jetzt meine MySQL-Klasse soweit umgestellt, so daß jetzt MySQLi verwendet wird und dazu auch noch die prepared Statements (oder wie auch immer die nochmal heißen) verwendet werden.

In meinem Query sind jetzt prepare+bind_param+execute, multi_query und das normale query gekapselt und werden automatisch ausgewählt.
Wobei query hierbei ein real_query mit einem speziellem store_result sind, damit die Result-Klasse ausgetauscht werden kann,
welche dann das free_result automatisch aufruft, wenn das Result-Objekt freigegeben wird.

Hab nun auch mal angefangen dieses PHPDoc zu verwenden.
(das macht sich, z.B. bei der Autovervolständigung in NetBeans, richtig gut )

also mir gefällt's so schon irgendwie
und aus diesem

markieren

PHP-Quellcode:

$Var1 = 'abc';
$Var2 = 123;
//$Result = $DB->Query('INSERT INTO `#PrefixMyTable` (`Field1`, `Field2`) VALUES (?, ?)',
// array($Var1, $Var2), array('#Prefix' => 'xxx'));
# das #Prefix ist schon vordefiniert enthalten
$Result = $DB->Query('INSERT INTO `#PrefixMyTable` (`Field1`, `Field2`) VALUES (?, ?)', array($Var1, $Var2));

wird dann intern das gemacht

markieren

PHP-Quellcode:

$Var1 = 'abc';
$Var2 = 123;
$State = $DB->prepare('INSERT INTO `xxxMyTable` (`Field1`, `Field2`) VALUES (?, ?)');
$State->bind_param('si', $Var1, $Var2);
$Result = $State->execute();

wobei es auch so ginge

markieren

PHP-Quellcode:

$Var1 = 'abc';
$Result = $DB->Insert('MyTable', array('Field1' => $Var1, 'Field2' => 123));

Bei diesem Preparedzeugs fehlte mir etwas, womit man auch mal normalen Text einfügen kann und nicht nur ganze Parameter.



Auch wenn's böse aussieht, fand es so letztendlich aber einfacher ... im __construct hol ich die Configuration nun direkt aus einem Config-Objekt, anstatt diese weiterhin via Parameter zu übergeben.

Warum nimmst du nicht einfach ein fertiges Framework wie z.B. Zend.
Bei Zend kann man auch nur einzelne Klassen nutzen, wie die ZendDB.

Zitat von Valle:

Ich kann dir als Referenz auch noch das Zend Framework empfehlen. Jenes ist zwar sehr langsam, als technischer Ansatz aber sicher einen Blick wert. Deren API, die abstrakte Implementation und das gesamte Konzept ist sehr gut Durchdacht und meiner Meinung nach echt lobenswert.

*hust* Da geht sie dahin, die Einigkeit. ZF ist nicht langsam - es hat aber einen gewissen Overhead wie jedes andere Full-Stack-Framework auch. Auf normaler Hardware und mit nem Opcode-Cache (aptitude install php-apc) ist die Performance sehr gut. Im Zweifel schicke ich dir mal ein paar Infos zu ZF-Applikationen mit denen ich beruflich zu tun habe. Da aenderst du dann gerne deine Meinung

Um noch kurz ein paar allgemeine Worte zum ZF zu verlieren: es verfolgt zwar denselben Ansatz wie Symfony (Full-Stack MVC-Framework), aber auf eine ganz andere Art und Weise (Symfony setzt auf Code Generation, Zend Framework laesst dich alles selbst machen). Fuer den Einstieg wuerde ich auf alle Faelle Symfony empfehlen, behalte aber die Ideen und Konzepte von ZF im Blick.

@himitsu: wenn du gerade erst PHP5 lernst, dann nutze die Chance und fang gleich mit MVC an. Dieses bisherige include functions.php Gefrickel ist Schnee von Gestern

Greetz
alcaeus

Was wäre denn heutzutage die Alternative zu diesem "include-Gefrickel"?
Also wie kann ich mir die Umsetzung von MVC an dieser Stelle vorstellen?


Grüße,
Frederic