Mailinglisten-Archive |
Ralf, auch diese Antwort drückt sich etwas herum. Ralf Geschke wrote: > > Ulf Wendel wrote: > > > das ist irrelevant, kannst Du beim kompilieren weglassen, was Du nicht > > brauchst. Du argumentierst gerade gegen eines der wichtigsten > > Designprinzipien von PHP: Modularität. > > Noe, da hast Du mich falsch verstanden. > Es geht mir nicht um die Kompilierung oder die Groesse des > PHP-Moduls, sondern darum, dass da bald keiner mehr > durchsteigt (oder mit dem Schreiben des Manuals nachkommt ;-) ). > Dennoch fehlen einige IMHO wichtigere Module - etwa > ein natives Template-Modul. Momentan gibt es ein Dutzend > oder mehr konkurrierende, aber nichts davon gehoert > zum "Lieferumfang" von PHP4. Jeder frickelt ausserdem Naja, ich kann ja IT[X] in PEAR einchecken... > an eigenen Formular-Klassen /-Funktionen / -APIs > zur Verarbeitung, Validierung etc. In PEAR habe ich > dazu bislang nichts gefunden (ok, laenger nicht > reingeschaut...). Keine Angst da ist was drin. Wo willst Du hin zu den Microsoft WebForms, die sind mit AppServer drin, ohne kaum. > Siehe Kongress, der Tanz von Twisd mit C++ und APL. Hmm, das Problem liegt nicht darin, das es keine PEAR Quellen gab auf die man zurückgreifen konnte. Was willst Du hier sagen? > > Die Datenbank spielt keine entscheidende Rolle. PHP 4 hat Overhead durch > > Ohh doch, das tut sie. ;-) Nicht bei der Diskussion über den PHP Interpreter. Willst Du hier zum Ausdruck bringen, daß Du gerne einen Proxy für die Datenbank bekommen würdest, der möglich wird, wenn Du einen AppServer hast, oder spielst Du aus MySQL vs. Oracle an. Für die DB kann PHP nun aber eigentlich wahrlich nichts. > Oder Prozesse, die ich in den Hintergrund schieben > kann und sage "Mach' mal dies und jenes...". Prozesse oder Threads? Ulf
php::bar PHP Wiki - Listenarchive