PHP Engine als Basis neuer Projekte?

Hi,
(Soll keine Werbung sein, sondern nur der Wunsch nach Feedback)
ich wollte hier auch mal Fragen was Ihr davon haltet. Auszug aus der Umfrage in meinem Projekt (vor allem interessieren würde es mich natürlich, hätte sowas Zukunft?):
Vor allem möchte ich meine Engine von meinem derzeitigen Projekt komplett trennen, sodass Sie von dem Projekt zwar genutzt wird, aber alle projektbezogenen Dinge nicht mit der Engine vermischt werden, sodass Sie jederzeit alleine lauffähig und für andere Projekte benutzbar ist.
Die Leistungen der ersten Version der Engine würden dann in etwa sein:

Systemcore (Einzigartige Objekte des Systems mit Zentralem Zugriff)

Zentraler Zugriff auf Einstellungen mit Cachefunktion
Datenbankverbindung und Ausführen von SQL Statements
Zugriff auf Daten und Kapselung dieser der Cookies und der Session
Erstellung der Datenbankstruktur und Zugriff auf die Datentypen der Spalten in denTabellen
Verwaltung der Events, welche nach einer definierten Zeit einer Benutzeraktion ausgeführt werden
Sprachunterstützung auf Zugriff verschiedene Sprachvariablen der eingestellten Sprache
Seitenaufbau mit einer variablen Template Klasse mit dessen HTML Grundstruktur
Verwaltung der verschiedenen Inhaltsseiten über bis zu 4 Hierarchieebenen und Zugriffsrechte (Unterscheidung Besucher und Mitglied)
Database (Tabellenbeschreibung jeder Tabelle der Datenbank)
Zugriff und Manipulation jedes beliebigen Datensatzes über PHP Objekte mit
Hilfe der Angabe über den Primärschlüssel des Datensatzes. Des weiteren eine
automatische Erstellung der kompletten Datenbankstruktur mit allen Tabellen
Pluginclass
Jedes Plugin stellt eine Inhaltsseite dar, welche eine Ausgabe besitzt. Die
Informationen über jedes Plugin, dessen Name und Zugriffrechte werden dabei
in einer Baumstruktur in der Einstellungsdatei hinterlegt

Moduleclass
Alle Module werden auf jeder Seite abhängig vom Zugriffsrecht auf einer fest
definierten Position im Template angezeigt. Dabei gibt es folgende Module:
Inhaltsbereich, der die Ausgabe des aktuell gewählten Plugin anzeigt
Footer, der Informationen über das Projekt und sonstige wichtige Dinge zeigt
Seitennavigation mit der Navigation aller Plugin
Topnavigation mit der Navigation aller Seitenteile
Helpclass
Ausführen von SQL Statements und dessen Ausnahmebehandlung und Auswertung
Logfunktionen zum Loggen von System- und Benutzeraktionen
Klassen zum Anzeigen und Validieren verschiedener Daten
Klassen zum Zusammenbau von XML und HTML Dokumente
Navigationen und Datentabellen über eine Klasse vereinfacht definieren
Unit Tests zur Definierung von Tests für einzelne Klassen
Definierung von Formularen für Benutzereingaben und automatischer Validierung und Überprüfung dieser Eingaben
Vorraussetungen der Engine an einen Entwickler:

• PHP 5 ist Mindestvoraussetzung, da die Engine Objektorientierung und Exception Handling besitzt
• Umgang mit Klassen und Exceptions sollten kein Problem sein (Jedes Modul und jedes Plugin ist eine Klasse)
• Einhaltung der Strukturen für neue Plugin, Module, Einstellungsdateien, Sprachdateien (Verzeichnisstruktur und Schnittstellen)
• Zusammenbau des fertigen HTML Dokumentes mit einer Writer Klasse

Weitere Dinge die ich bei der Engine machen will (falls Sie von anderen Projekten benutzt wird):

• Jede einzelne Datei (Klasse, Einstellung, Sprachdatei) ist unabhängig der Engine im eigenen Projekt überschreibbar, ohne die Engine ändern zu müssen
• Jeder Offizielle Benutzer wird über Neuerungen, Sicherheitsupdates und Fehlerbereinigungen informiert
• Von den einzelnen Versionen wird es Update Pakete geben, mit den geänderten Dateien
• Zwischen den Versionen gibt es kleinere Pakete (oder auch komplette Versionen) bei kritischen Fehlern oder Sicherheitslücken
• Organisation der Engine mit News, Bugtracker und Forum ist getrennt von den Projekten

Mmh ich spreche jetzt von meiner Warte aus
und halte das für kompletten Unsinn.
Wieso will man denn unbedingt immer ein neues PHP in PHP implementieren ?
Wieso immer schwierig wenns auch einfach geht ?
Bringen die 100 Klassen wirklich so viele Vorteile und Übersichtlichkeit ?
Ich kann mich da immer nicht rein versetzen.
Liegt vielleicht daran das ich Betriebswirt und kein Informatiker bin.

Wenn ich statt 20 Zeilen HTML und 30 Zeilen PHP nur noch 5 Zeilen PHP Code brauche um ein Formular zu erstellen und die Benutzereingaben zu überprüfen halte ich das nicht für unsinnig.
Wenn ich um auf die Daten des aktuellen Benutzers zugreifen, einfach das registrierte Objekt nehme mit $member->email; (welches nur einmal geladen wird pro Session) statt extra einzeln aus der Datenbank laden zu müssen wenn ich was brauch ist das für mich ne große Performanceersparnis.
Wenn ich zum Ändern der E-Mail Adresse eines Benutzers einfach nur die ID und die neue E-Mail Adresse der Klasse übergeben muss ist das für mich auch sehr schön:

$member = new MemberDatabase(1);

$member->email = "[email protected]";
try
{
$member->save();
} catch(StatementException $exception)
{
print $exception;
}
und und und, was die Engine leistet ist ja beschrieben. Also warum das Rad jedesmal neu erfinden, wenn ein Großteil der Arbeiten einer dynamischen Webseite eh immer gleich aussieht. Als Anwender nimmt man zum Erstellen von Homepages ja auch lieber ein CMS das einem die Arbeit abnimmt als dass man den HTML Code tippselt.
Nicht jeder Entwickler mag diese Dinge gerne anderen überlassen. Aber es ist nicht so dass man ein unveränderliches Paket bekommt. Jede Klasse kann vom Benutzer außerhalb der Engine überladen werden und ich bin über jeden Wunsch erfreut der die Engine vorantreibt. Aber der Größte Vorteil wie bei allen Bibliotheken ist, wenn es viele benutzen, hat es im Durchschnitt weniger Fehler als wenn man was eigenes macht.
Von meiner Seite her wird es ein kostenloses Angebot sein, wer es will kann es annehmen, wer nicht bin ich auch nicht böse. Ich mache dies ja nicht nur um es unbedingt vertreiben zu wollen, sondern weil ich gemerkt habe, dass es für mein Browsergame wesentlich eleganter ist, die Dinge einmal zu definieren und später wenn es um die Inhalte geht, einfach anwenden zu können.

Irgendwo hast du den Code fürs Formular und die Validierung ja auch stehen.
Genau wie ich auch, nur brauche ich da aber keine verwirrenden Konstrukte aus 10 Klassen um das zu realisieren.
Versteh ich nicht, zauberst du die Email mit deinen Objekten einfach her oder was ?
Du musst sie auch irgendwo auslesen.
Performanceersparnis ? Je weiter du abstrahierst desto mehr geht in die Performance in den Keller !
Ist ja auch irgendwie logisch !
Um eine Mailadresse zu ändern übergeb ich auch nur die ID und neue Mail an ein
SQL Query ?!
Na ja ich will dich nicht bekehren...
Nur nicht alles was du irgendwo in tollen Lehrbüchern liest muss in der Praxis auch toll sein.

Amun hat, vor allem was den Perfomance-anteil angeht, meine vollste unterstützung. Abstraktionen sind schön und gut, aber nur wenn sie wirklich was ersparen. Und sobald man das ganze so Dynamisch macht, das das Design usw. auch komplett variabel ist, kann es von der Perfomance her nur noch furchtbar sein.
Also wenn du sowas schreibst für dich - sehr schön. Aber alles was so Allgemein gehalten wird, das man ev. statt mysql direkt das dateisystem benutzen kann (wer weiß...?), ist einfach von der Perfomance her verdammt.

Ich hab mir mal schnell n extrem künstliches Beispiel aus den Fingern gesogen.
Apache Benchmark: ab -k -n 100000 -c 100

echo 'Hallo Welt';
?>
mehrmals getestet im Schnitt lag ein Request bei 0.811 ms.

class Hallo {
function print_hallo() {

echo 'Hallo Welt';

}
}
$hallo = new Hallo();
$hallo->print_hallo();
?>
im Schnitt lag ein Request hier bei 0.894 ms.
Rechne mal durch das sind 10% Performanceunterschied !
Kumuliere das mal auf ne riesen Anwendung in PHP
in der du alles "zwanghaft" mit Klassen machst.
PHP ist in meinen Augen einfach nicht die optimale Sprache für OOP.
Die OOP Features wurden alle nachträglich implementiert.

Original von Amun Ra
Irgendwo hast du den Code fürs Formular und die Validierung ja auch stehen.
Genau wie ich auch, nur brauche ich da aber keine verwirrenden Konstrukte aus 10 Klassen um das zu realisieren.

Ja klar, nur hab ich den Code halt nur einmal irgendwo stehen und jeder der ein Formular machen will hat weniger Arbeit damit ein Formular zu erstellen.
Beispiel mal Schemenhaft wie das bei mir funktioniert:

$formular = new Formular('action.php', 'login');

$formular->addElement(new TextFieldElement('benutzer'));
$formular->addElement(new TextFieldElement('kennwort'));
if($formular->valid())
{
print $formular->benutzer . ' ' . $formular->kennwort;
}
Sowas ist mir tausend mal lieber als jedesmal das HTML schreiben zu müssen oder die Daten selbst zu validieren. Buttons werden automatisch hinzugefügt (kann auch manuell Beschriftet oder ganz abgeschaltet werden für einzelne Formulare), Benutzerhinweise über falsche Eingaben, Beschriftungen etc. aus den Sprachdateien geladen.

Original von Amun Ra

Versteh ich nicht, zauberst du die Email mit deinen Objekten einfach her oder was ?
Du musst sie auch irgendwo auslesen.
Beim ersten Zugriff auf eine Registriertes Element wird es aus der DB geladen. Wird es zwischendurch mehrmals geändert, wird es am Ende in die DB einmal gespeichert.

Original von Amun Ra

Performanceersparnis ? Je weiter du abstrahierst desto mehr geht in die Performance in den Keller !
Ist ja auch irgendwie logisch !
Geb ich dir auch vollkommen Recht. Die Performance ist ein Nachteil. Nur selbst bei großen Projekten (und gerade da) kann man sehr viel schneller und übersichtlicher seine Sachen entwickeln und hat hinterher noch mehr Zeit Performance Lücken zu finden. Der Performance Verlust mag dann vielleicht bei 10%-20% sein, aber wenn ich dadurch mehr Sicherheit und eine wesentlich elegantere Möglichkeit habe meine Sachen zu entwickeln und vor allem weiterzuentwickeln später hin, was ist mir da lieber?
Und meistens sind es nicht solche Dinge, die die Performance den Bach runter gehen lassen. Wer sehr viel Wert auf Performance legt sollte keinerlei Abstraktionen verwenden, das ist klar, aber vor allem auch kein PHP. Und in 99% der Fälle ist es auch sicher nicht die Performance, an dem ein Projekt scheitert. Lieber ein gut Designtes Projekt optimieren, als eines was weniger Übersichtlich ist ausbessern oder weiterentwickeln zu müssen.

Original von Amun Ra

Um eine Mailadresse zu ändern übergeb ich auch nur die ID und neue Mail an ein
SQL Query ?!
Bei jedem Statement wo ich mir spar weiß ich, ich hab ein Statement weniger, das ich falsch machen kann. Und wenn ich 10 Sachen am Benutzer an 10 verschiedenen Stellen ändern will, brauch ich trotzdem nur 1 Statement, welches ausgeführt wird. Aber klar, nicht alle Statements werden eingespart, es bleibt jedem offen wann er die Tabellenklassen benutzt und wann nicht.

Original von Amun Ra

Na ja ich will dich nicht bekehren...
Nur nicht alles was du irgendwo in tollen Lehrbüchern liest muss in der Praxis auch toll sein.
Ich bin über dein Feedback sehr dankbar und Kritik ist mir wesentlich lieber als blinde Akzeptanz, nur so sehe ich, wo die Schwachstellen zu finden sind und was ich verbessern müsste.
Und Performance ist ein Punkt, an dem man viel verbessern kann, nur ich finde man kann es wesentlich besser verbessern, wenn man an wenigen Stellen Änderungen dafür vornehmen muss, als wenn man nur Skripte verwendet und an vielen Stellen aufpassen muss was man ändert.
Bei mir ist aber ganz klar die Sicherheit und die elegante Programmierung wichtiger als die Performance. Auch ist das Projekt noch am Anfang, von daher ist es natürlich noch langsamer als vielleicht in ein paar Jahren.
PS: Im Beruf sehe ich, wohin es führt, wenn man lieber etwas zwei mal macht als einmal zuviel abstrahiert. Unsre Software ist 10 Jahre lang gewachsen (9 ohne mich ) und vor dem Neuschreiben ging 80% der Entwicklungszeit darauf, Fehler zu beheben, und oft auch Fehler die an 5 andren Stellen schon mal behoben wurden.

Original von Nuky
Amun hat, vor allem was den Perfomance-anteil angeht, meine vollste unterstützung. Abstraktionen sind schön und gut, aber nur wenn sie wirklich was ersparen. Und sobald man das ganze so Dynamisch macht, das das Design usw. auch komplett variabel ist, kann es von der Perfomance her nur noch furchtbar sein.
Also wenn du sowas schreibst für dich - sehr schön. Aber alles was so Allgemein gehalten wird, das man ev. statt mysql direkt das dateisystem benutzen kann (wer weiß...?), ist einfach von der Perfomance her verdammt.

Mein Design ist nicht soo Variable, es hat klare Strukturen. Nur da, wo es dem Benutzer sehr viel Arbeit abnehmen kann, wird es auch getan. Ich sehe kein Sinn daran etwas soweit zu abstrahieren, dass es egal ist, ob Daten aus der DB kommen oder aus einem Dateisystem (höchstens soweit, dass es egal ist aus welchem DB System).
Ich hab soweit abstrahiert, dass es einfach ist die Sachen zu benutzen und an den Stellen wo es sinnvoll ist neue Sachen hinzuzufügen (Formularelemente zum Beispiel) wurde es auch soweit flexible gehalten, dass es ohne Probleme möglich ist.
Und jeder der MVC Konzept benutzt, legt ja schließlich auch mehr Wert auf Flexibilität als auf Performance. Meins geht halt einen Schritt weiter, aber nicht immer unbedingt im Negativem Sinne.
Nichts in meiner Engine ist sinnlos enthalten. Und alles was nicht gebraucht wird, wird auch nicht geladen oder erzeugt in irgendeiner Weise Overhead.

Hey das ist der Sinn des Forums,
gegenseitig helfen und Feedback geben.
Ich bin halt nur Hobbycoder,
bin aber schon lange dabei.
Gerade im Bereich Browsergame ist Performance
und Skalierbarkeit sehr wichtig
und da mach ich mir schon ewig Gedanken drüber
und benchmarke was das Zeug hält.
Findest du das dein Codeschnipsel für ein Formular
einfacher ist, als das Formular einfach in
plain HTML schreiben ? Ich nicht...
Auch du musst irgendwo abfragen,
ob ein Formular gesendet wurde oder nicht.
Auch du musst dann irgendwo Methoden aufrufen.
Warum nicht gleich ein preg_match('...', $user_name) ?
Jedes mal die Email aus der DB ziehen,
obwohl ich sie gar nicht überall brauche ?
Das ist auch keine elegante Art zu programmieren.
Wo sparst du den SQL Statements ?
Ich speichere was und du auch 1 = 1.
Für mich ist PHP schon das was du dir da bauen willst.
Ne riesige Anhäufung an fertigen Funktionen.
Warum um jede PHP Funktion noch ein Wrapper schreiben,
weils cool ist ?
Ich mach das einfach so:

require './includes/config.php';

require './includes/initiate.php';
require './includes/database.php';
require './includes/session.php';
Am Anfang jedes Scripts werden diese vier Files geladen.
Die Funktionen sollten selbsterklärend sein.
In den Dateien ist alles funktional.
Nicht eine einzige Klasse,
hab einfach keinen Mehrwert dadurch.

require './templates/header_internal.php';

Dann kommt das header Template.
Danach alle benötigten Berechnungen.

require './templates/footer.php';

Danach der Footer.
Ende.

Original von Amun Ra
Gerade im Bereich Browsergame ist Performance
und Skalierbarkeit sehr wichtig
und da mach ich mir schon ewig Gedanken drüber
und benchmarke was das Zeug hält.
Findest du das dein Codeschnipsel für ein Formular
einfacher ist, als das Formular einfach in
plain HTML schreiben ? Ich nicht...

Aber bei weitem. Wenn diese fünf Zeilen (oder wie viele es waren) mir die Arbeit abnehmen, wofür ich 30 bräuchte, dann ist es natürlich einfacher. Vor allem kannst du beim Validieren wenig falsch machen, weil du gar nichts machen musst. Und selbst wenn meine Engine falsch validieren würde, egal, kann man ohne Probleme an einer Stelle ändern.

Original von Amun Ra

Auch du musst irgendwo abfragen,
ob ein Formular gesendet wurde oder nicht.
Auch du musst dann irgendwo Methoden aufrufen.
Warum nicht gleich ein preg_match('...', $user_name) ?
Natürlich, ich muss genau das machen, was du auch machst. Nur dass ich es an einer Stelle mache und du dann bei jedem Formular. Und dort dann mit preg_match arbeiten? Das doch arg unflexible, jede Änderung an alle Stellen übernehmen, vielleicht mal eine vergessen. Also da sollte mindestens eine Funktion her.

Original von Amun Ra

Jedes mal die Email aus der DB ziehen,
obwohl ich sie gar nicht überall brauche ?
Das ist auch keine elegante Art zu programmieren.
Jain, es liegt in der Entscheidung des Anwenders, welche Daten er herholt. Nur ich finde es wesentlich schöner beim ersten Zugriff alle Spalten zu haben und keine sonst zu gebrauchen, als nur eine Spalte zu holen und danach weitere Statements zu gebrauchen um andere Informationen zu holen.

Original von Amun Ra

Wo sparst du den SQL Statements ?
Ich speichere was und du auch 1 = 1.
War auf das Beispiel bezogen, wenn du an zwei verschiedenen Stellen etwas am aktuellen Benutzer änderst, brauchst du zwei Statements. Bei mir werden beide Änderung am Objekt des Benutzers festgehalten und am Ende, wenn es eine Änderung gegeben hat, werden auch genau diese zwei Änderungen in der DB aktualisiert. Daher für mich nur ein Statement.

Original von Amun Ra

Für mich ist PHP schon das was du dir da bauen willst.
Ne riesige Anhäufung an fertigen Funktionen.
Warum um jede PHP Funktion noch ein Wrapper schreiben,
weils cool ist ?
PHP ist für mich eine Sammlung von allen Funktionen, die ich benötige. Ich bringe diese nur in die gewünschte Form, wie ich diese benötige.
Oder benutzt du etwa direkt "mysql_query"? Solang du ganz genau sicher sein kannst, dass du kein SQL Statement falsch machst oder jedes falsche gleich beim Test entdeckt wird, spricht nichts dagegen. Aber kannst du das? Ich nicht, ich bin nicht perfekt, ich vertippe mich des öfteren. Aber allein schon wenn du das Ausführen des Statements in eine Funktion packst und bei einem Fehler diesen Fehler in die Datenbank speicherst, kannst du sicher sein, dass jeder SQL Fehler auch aufgezeigt wird und behoben werden kann. Die meisten Benutzer werden wohl nicht einfach den Fehler dir melden, sondern eher wegklicken. Zumal ein Benutzer keine Detailinformationen über einen Fehler bekommen sollte und es somit schwer ist den Fehler nachzuvollziehen, wenn er nicht immer auftritt.
So gibt es viele Stellen, wo man sich einfach das Leben einfacher und sicherer macht. Ich habe lange dagegen gekämpft Klassen zu benutzen, einmal probiert und seitdem sehe ich immer mehr Vorteile darin. Wenn dafür etwas Performance benötigt wird, ist für mich kein Problem. Wenn ich meinen Benutzer schnell ein neues Feature ohne große Änderungen einbauen kann, wie automatische Handelsrouten um ein Beispiel zu nennen, und diese weniger rum klicken müssen, sind Sie glücklicher und ich hab weniger Serverlast.
PS: Die größe des Projektes spielt für mich eigentlich keine Rolle, da nur die aktuell ausgewählte Seite instanziert wird. Daher egal wie viele Seiten es gibt. Höchstens für den Zusammenbau des Menüs interessant. Das einzige was eine Rolle spielt sind große Nutzerzahlen. Und ich habe nur sehr selten (wenn überhaupt, kann mich an keines erinnern) von einem Projekt gehört, dass wegen Performance den Bach runter ging, weil es zuviel Abstraktion oder ähnliches verwendet hat. Aber es gab schon massig Projekte, die wegen Bugs und ähnlichem verschwunden sind, weil es einfach nicht mehr möglich war, die vielen Stellen an denen die Bugs auftraten ohne weitere Folgefehler beheben zu können.

Oh man Drake, schreib mal nur die Hälfte,
da muss ich ja immer mit nem Roman antworten
Name:
Passwort:

$formular = new Formular('action.php', 'login');
$formular->addElement(new TextFieldElement('benutzer'));
$formular->addElement(new TextFieldElement('kennwort'));
Na ja... sind 4 Zeilen mehr.
In meinem config array steht user_preg => '...', pass_preg => '...', usw.
Nur an einer einzigen Stelle.
Wieso noch ne Funktion, preg_match ist doch die Funktion.
preg_match($config['user_preg'], $user_name)
Ich weiss vorher welche Spalten ich brauche und hole nur diese.
Und nein ich habe Funktionen für den Zugriff auf die DB.

Original von Amun Ra
Oh man Drake, schreib mal nur die Hälfte,
da muss ich ja immer mit nem Roman antworten

Ich bin ein sehr schreibfreudiger Mensch, und Beispiele der einzelnen Bestandteile der Engine gebe ich gerne, trägt auch etwas zum Verständnis bei was die Engine macht und vielleicht sieht der ein oder andere die Vorzüge davon.
(War vielleicht schon eine Vorahnung, dass ich hier ziemlich viel schreibe und es eine größere Diskussion in dieser Form geben wird, ein Grund warum es hier unter Spam steht.)

Original von Amun Ra

Name:
Passwort:

$formular = new Formular('action.php', 'login');
$formular->addElement(new TextFieldElement('benutzer'));
$formular->addElement(new TextFieldElement('kennwort'));
Na ja... sind 4 Zeilen mehr.
Und wie viel Zeilen musst du nun ändern, um die Semantik deiner HTML Dokumente zu korrigieren? Beschriftungen für Controls sollten als Label definiert werden um besser von Screenreadern geparst werden zu können.

Original von Amun Ra

In meinem config array steht user_preg => '...', pass_preg => '...', usw.
Nur an einer einzigen Stelle.
Wieso noch ne Funktion, preg_match ist doch die Funktion.
preg_match($config['user_preg'], $user_name)
Ich weiss vorher welche Spalten ich brauche und hole nur diese.
Ich nutz normal kein "preg_match", nur für E-Mail Adressen zu validieren. Kann aber jederzeit meine Validierung ändern oder neue Elemente mit gemeinsamer Schnittstelle definieren.

Original von Amun Ra

Und nein ich habe Funktionen für den Zugriff auf die DB.
Ich eine Klasse (ha, wen wundert es ) und auch wenn es vielleicht schon nervt, würde ich an der Stelle gerne ein Beispiel posten (gehört ja eh zum Threadthema, ist Bestandteil der Engine):

try

{
$statement = new Statement('select * from tabelle');
while($row = $statement->row())
{
print $row['spalte'];
}
}
Was unterscheidet das von den normalen mysql Funktionen? Ganz klar, um eine andere Datenbank zu benutzen, tausche ich einfach die Connection Klasse aus (Klassiker, warum man hier gerne kapselt). SQL Fehler werden automatisch geloggt (um genau zu sein wird eigentlich nur eine Exception geworfen. Aber alle Exception werden in der Entwicklung angezeigt und in der laufenden Version in der DB geloggt, falls dies bei dem Exceptiontyp nicht abgeschaltet wurde.) und nach dem durchgehen der Zeilen wird das Result freigegeben.
Wenn man nur die erste Spalte der ersten Zeile braucht (Klassiker wäre ein "select count(*)"), oder nur wissen muss, wie viele Datensätze das "update" oder "delete" Statement aktualisiert oder gelöscht wurden bzw. die ID vom Auto_Increment beim Insert, geht das ganze noch einfacher:

try

{
$statement = new Statement('insert into...');
//Falls vorhanden wird die ID des Auto_Increment zurück gegeben,
//ansonsten die Anzahl der eingefügten Datensätze
print $statement->simple();
}
Eleganter kann ich mir den Umgang mit SQL Statements nicht mehr vorstellen. Ansonsten würde ich es implementieren. Mit Funktionen wäre dies nur möglich, wenn ich das result nach außen zurück gebe, was der Datenkapselung widerspricht und für mich daher nicht in Frage kommt.

Also ich fände das ganze nicht so interessant. Und das aus einem ganz einfachen Grund: es gibt es schon in zig Variationen. Und hinter diesen Projekten steht meist mehr Manpower und Knowledge, als bei Deiner Engine. Darüber hinaus würden noch einige Sachen fehlen, die wichtig sind. So lese ich heraus, dass Du kein RBAC System hast.
Du kannst es gerne Versuchen, aber sich gegen andere Systeme oder Systemkombinationen durchzusetzen, wird sehr schwer sein.

Original von Agmemon
Also ich fände das ganze nicht so interessant. Und das aus einem ganz einfachen Grund: es gibt es schon in zig Variationen. Und hinter diesen Projekten steht meist mehr Manpower und Knowledge, als bei Deiner Engine. Darüber hinaus würden noch einige Sachen fehlen, die wichtig sind. So lese ich heraus, dass Du kein RBAC System hast.

In welcher Form denn Rollen? Für die spätere Benutzerverwaltung? Naja, die Engine wird ja jetzt nicht fertig gemacht und dann weggelegt. Sondern je nachdem was die Projekte, die Sie benutzen noch brauchen und was ich noch brauche, was Allgemein nützlich wäre, wird diese natürlich erweitert.

Original von Agmemon

Du kannst es gerne Versuchen, aber sich gegen andere Systeme oder Systemkombinationen durchzusetzen, wird sehr schwer sein.
a) Ich kenne kein System, das die Leistungen besitzt, die ich haben will und mir vorstelle. Eine Kompination halte ich für nicht sehr sinnvoll. Allein, wenn ich an das Exception Handling denke, da will ich doch ein einheitliches System haben und nicht noch Wrapper um die einzelnen Bibliotheken bauen müssen, damit ich dies habe.
b) Ich will mit den Projekten, die die Engine benutzen zusammenarbeiten und auf deren Wünsche reagieren solang sich diese nicht widersprechen (wenn doch kann eine individuelle Anpassung vorgenommen werden per Überladen der Allgemeinen Engine Klasse). Also sowas was ich von meiner Firma schon gewohnt bin.

Original von DrakeL
In welcher Form denn Rollen? Für die spätere Benutzerverwaltung? Naja, die Engine wird ja jetzt nicht fertig gemacht und dann weggelegt. Sondern je nachdem was die Projekte, die Sie benutzen noch brauchen und was ich noch brauche, was Allgemein nützlich wäre, wird diese natürlich erweitert.

Deine Beschreibung las sich so, als würden nur zwei Gruppen unterstützt werden.

Original von DrakeL

Kombination halte ich für nicht sehr sinnvoll. Allein, wenn ich an das Exception Handling denke, da will ich doch ein einheitliches System haben...
Das Verstehe ich nicht. Was ist denn an Exceptions nicht einheitlich?

Original von Agmemon
Deine Beschreibung las sich so, als würden nur zwei Gruppen unterstützt werden.

Von der Engine vordefiniert ja, lässt sich aber beliebig erweitern.

Original von Agmemon

Das Verstehe ich nicht. Was ist denn an Exceptions nicht einheitlich?
Ehrlich gesagt, ich kenn bisher nur PEAR wirklich gut wo ich paar Dinge mal genauer angeschaut hatte. Die Bibliotheken dort sind meist für PHP 4 geschrieben, daher benutzen diese keinerlei Exceptions. Auch andere Systeme, die ich mal angetestet hatte, haben keinerlei Ausnahmebehandlung implementiert gehabt (wegen Kompatibilität zu PHP 4)

Naja, es gibt ja schon noch große Unterschiede zwischen dem was Du kennst, und was es alles gibt. Nimm z.B. das Zend Framework, volles PHP5 inkl. Exceptions.

Ich muss da nichts korrigieren, also keine...
Du nutzt kein preg_match - was denn dann ?
Wenn ich eine andere DB verwenden wollte,
würde ich auch nur die eine Datei ändern.
Ist ja im Grunde auch egal.
Die Diskussion ist im Spamforum gut aufgehoben.

Um mal eine Lanze für die OOP zu brechen. Also ich halte es für sehr sinnvoll ein größeres Projekt OO zu programmieren.
Klar für 2 SQL Statements und 3 echos macht es wenig Sinn, aber für komplexere Probleme, Datenbank Transaktionen o.ä. nutze ich dankbar Möglichkeiten und Entwurfsmuster der OOP.
Aber DrakeL leider muss ich dir sagen, dass Agmemon recht hat, und es das was du vorstellst schon mit nahezu allem was du dir vorstellst in Form des Zend Frameworks gibt.
Wo ich Amun Ra allerdings Recht geben muss (und auch dem Zend Framework Ansatz kritisiere) ist, dass es wirklich keinen Sinn macht jedes Komma in eine Klasse zu packen. Bei Verwendung von Templates macht es wenig Sinn HTML-Elemente in PHP-Klassen zu kapseln (außer an dem Formular hängen umfangreiche AJAX-Skripte dran, die zentral pflegen möchte)
@Amun Ra
Du nutzt preg_match, obwohl du auf jede ms achtest? Du weißt schon das reguläre ausdrücke als Performance Fresser berühmt sind?
Sie auch hier : preg_match Performance
Oder lässt du das preg_match über die ganze Datei laufen?

Ja das weiss ich
Momentan lass ich als Nutzername nur wenige Zeichen zu.
Kann sich ja noch ändern...
Deshalb sieht mein Pattern so aus /^[0-9a-z ._-]+$/i und das nur beim Login, Registrierung usw. also nichts was die inGame Performance angeht.
Numerische IDs sichere ich z. Bsp. so
$page = isset($_GET['page']) ? intval($_GET['page']) : 1;
EDIT: Ok ich seh gerade das ich beim Senden einer inGame Nachricht auch noch ein preg_match habe...
Wird sofort geändert

omg, also ich finde dein system viel zu oversized, zumidnest für php, wo man wirklich versuchen sollte/muss jedes fünkchen code zu optimieren, der performance zu liebe...
ich selbst progge auch sehe gerne und oft OOP und deswegen habe ich quasi fast den kompletten code von albental von funktionen über ein ordentliches orm und ein datenmodell in oop umgeschrieben...
aber mehr braucht man dann auch eigentlich nicht: orm + datenmodell und gut ist!
only my 2 cents,
fatal
p.s.
ich bastel mir selbst gerade eine MMPOG-Engine, aber in java und deshalb 100% OOP, da macht sowas auch sinn und durch die laufzeit-optimierung des hotspots ist das verhätlniss von performance-verlust wegen höherer abstraktion im vergleich zum nutzen durch schnellere entwicklung sehr ausgewogen!

Original von Amun Ra
Ich muss da nichts korrigieren, also keine...

Klar, müssen tust du gar nichts. Du kannst Überschriften auch mit Div Containern formatieren statt den Tags. Kommt halt darauf an, ob man Semantisch korrekt arbeiten will. Syntax ist bei dir in Ordnung, aber die Semantik ist (zumindest an der Stelle) falsch. Wenn du damit leben kannst von mir aus.

Original von Amun Ra

Du nutzt kein preg_match - was denn dann ?
Bei einem String wird nach der Länge geschaut, ob die im gewollten Bereich ist, alles numerische wird per "is_numeric()" geprüft und auf Nachkommastellen. Datum und Zeitangaben mit den entsprechenden Funktionen von PHP. Auswahllisten per Whitelist. E-Mail wie gesagt als Ausnahme mit Regex (um mal die wichtigsten Elemente zu nennen).

Original von Amun Ra

Die Diskussion ist im Spamforum gut aufgehoben.
Da ist sie ja auch.
@Elliot:
Ich werde mir das Zend Framework mal anschauen, bisher noch keinen Kontakt damit gehabt.
Ich Kapsel im übrigen nicht jedes Komma oder jeden Tag in andere Klassen, sondern da wo es sinnvoll ist. Und bei Formularen oder auch HTML Tabellen zur Darstellung von Daten halte ich es für sehr sinnvoll, da man sehr viel Arbeit nur einmal definieren muss und vor allem als Benutzer dann (egal, ob vom eigenen System oder einem fremden Framework) viele Dinge dem System dann überlassen kann ohne sich groß Gedanken darüber machen zu müssen. Ich kann als Benutzer meiner Engine sagen was ich will und die Engine kümmert sich darum umzusetzen, wie es gemacht wird.
@fatal_error:
Ich werde in PHP nicht um jedes bisschen Performance ringen, weil das für mich ein Widerspruch ist, sondern an den Stellen optimieren, wo die Performance wirklich ein größeres Problem ist. Wenn mir Performance das wichtigste wäre, würde ich Java benutzen.
In Java sind mir aber noch einige Dinge im Bezug auf Servlets sehr unklar und mir meine Zeit zu schade meine Engine ohne Nutzung wieder wegzuwerfen. Ich will ganz klar in die Servlets Welt intensiver rein schauen, aber bisher fehlt mir die Zeit und die Nerven mich Tagelang in die Thematik einzulesen wie der Tomcat funktioniert und ich ein Servlet überhaupt aufbauen kann.

Ich Kapsel im übrigen nicht jedes Komma oder jeden Tag in andere Klassen, sondern da wo es sinnvoll ist.

Das mit dem "jedes Komma" bezog sich nicht direkt auf dich, ich habe schon Leute gesehen, die begonnen hatten b und h1 in Klassen zu kapseln

Und bei Formularen oder auch HTML Tabellen zur Darstellung von Daten halte ich es für sehr sinnvoll, da man sehr viel Arbeit nur einmal definieren muss und vor allem als Benutzer dann (egal, ob vom eigenen System oder einem fremden Framework) viele Dinge dem System dann überlassen kann ohne sich groß Gedanken darüber machen zu müssen.
hier stimme ich nur begrenzt zu, denn entweder man hat Standart Formulare und da ist die Tipparbeit nun fast identisch zum Funktionsaufruf oder aber man hat Sonderfälle und dann muss es entweder eine sehr umfangreiche Klasse schreiben oder man kann bei Sonderfällen die Klasse nicht nutzen.
Ich finde bei Verwendung eines Templatesystems ist es hier überflüssig Klassen zu verwenden. Aber das ist dann im Endeffekt Geschmackssache

Original von Elliot
Das mit dem "jedes Komma" bezog sich nicht direkt auf dich, ich habe schon Leute gesehen, die begonnen hatten b und h1 in Klassen zu kapseln

Halte ich für total unsinnig, sehe ich auch kein Vorteil darin. Außer du willst irgendwann ändern, dass statt h1 dann h2 genommen wird (so als Beispiel). Aber da gibt es wesentlich effektivere Möglichkeiten, wie XSLT.

Außer du willst irgendwann ändern, dass statt h1 dann h2 genommen wird (so als Beispiel). Aber da gibt es wesentlich effektivere Möglichkeiten, wie XSLT.

aber was machst du wenn du sagen wir nur die hälfte ändern willst? Dann musst du entweder überall die Klasse ändern oder (bei Templates) das Template. Da hilft auch XSLT nur begrenzt

Original von Elliot
aber was machst du wenn du sagen wir nur die hälfte ändern willst? Dann musst du entweder überall die Klasse ändern oder (bei Templates) das Template. Da hilft auch XSLT nur begrenzt

Aus welchem Grunde würde man nur die Hälfte ändern wollen?
Mir würde nur der Grund einfallen, dass du ein Element (Beispiel h1) für zwei verschiedene Anwendungszwecke verwendet hast. Aber wenn ich schon XSLT verwende, würde ich für jeden Anwendungsfall (z.B. Überschrift Seiten und Überschrift Absätze) zwei verschiedene XML Tags verwenden, die beide mittels XSLT zu h1 umgesetzt werden. So kann ich verschiedene Anwendungszwecke getrennt voneinander ändern. Und nur die Hälfte der Seitenüberschriften ändern macht meiner Meinung nach zumindest kein Sinn.

yet another php framework?
deine idee ist weder neu noch selten
und wie agmemon schon anmerkte können diese projekte von einem soloprogrammierer durschnittlicher erfahrung nicht konkurriert werden
anbei eine unvollständige liste von php frameworks:
www.phpwact.org/php/mvc_frameworks