[PHP5] Eigene Sriptsprache...

**Griecherus** · 31.01.2008, 00:46

Re: [PHP5] Eigene Sriptsprache...

Original geschrieben von GELight
Kleines Beispiel:

Die Menüpunkte meines Hauptmenüs kommen zB. aus der DB.
Für jeden Punkt habe ich eine Spalte "ONCLICK", in die ich meine Aktion schreiben will. Eine solche Aktion sieht "derzeit" ganz easy zB. so aus.

newWindow( 100, 100 );
oder
link( ordner/main.php?test=1 );

Ich bin mir nicht sicher, ob ich dein Beispiel richtig verstanden habe, aber was soll die Scriptsprache bezwecken, das PHP nicht besser könnte? Beispielsweise durch (Helper-)Funktionen?

Du solltest dir zuallerst über folgendes im Klaren sein:
Eine eigene "Scriptsprache" zu schreiben ist sehr kompliziert. Einen gescheiten Parser zu basteln ist meiner Meinung nach eine ordentliche Herausforderung, auch wenn ich diesen Themenbereich selbst sehr interessant finde. Für einen Einblick in die Komplexität wirds Typo3s TypoScript-Parser tun, denke ich.
Und das ist noch nicht alles. Deine Scriptsprache hätte noch einen Nachteil: die Performance.

Grüße

**onemorenerd** · 31.01.2008, 01:21

Dieser Ansatz scheint mir sehr unflexibel zu sein, teilweise spürst du das ja bereits.

Man kommt ja öfter mal in die Verlegenheit, Funktionalitäten an DB-Items zu koppeln. Dein Menü mit onClick-Events ist da ein gutes Beispiel.
Ich bevorzuge bei sowas immer die Standardlösung: Callbacks.
Meine DB für ein Menü sähe etwa so aus:

Code:

menu(id, parent, child, name, path, callback, arguments, ...)
-------------------------------------------------------------
1, 0, 0, 'Home', '/',         NULL,        NULL;
2, 1, 0, 'News', '/news.php', 'newWindow', 'a:2:{i:100;i:100;}';
3, 1, 1, 'Poll', '#',         'newWindow', 'a:1:{s:9:"/poll.php";}';

Die ersten 3 Spalten ermöglichen Hierarchien (Nested Set). Wer es nicht braucht, kann parent und child weglassen.
name ist das innerHTML des generierten a-Tags und path ist der Wert des href-Parameters, z.B. <a href="/">Home</a>. Natürlich kann man auch HTML-Code in name hinterlegen und somit z.B. Bilder verlinken (grafisches Menü).
Die Spalten callback und arguments werden beim Rendern des jeweiligen Links in einen PHP-Funktionsaufruf mit entsprechenden Argumenten umgesetzt.

PHP-Code:


while ($item = db_fetch_assoc($resultset)) {

    if ($item->callback) {

        $item->arguments = $item->arguments ? unserialze($item->arguments) : array();

        $item->extra = call_user_func_array($item->callback, $item->arguments);

    }

    //...

}

Die Callback-Funktion generiert das gewünschte Javascript, HTML oder was auch immer.
Wenn man oo programmiert, ist der Callback natürlich eine Methode der Menu-Renderer-Klasse.

Das ist nur ein einfaches Beispiel. Man kann es beliebig erweitern. Ich würde z.B. im DB-Design noch zwischen HTML-Argumenten und Callback-Argumenten unterscheiden und das Array für die Callback-Argumente so strukturieren, dass man einzelnen Einträgen ansehen kann, dass sie server- oder clientseitig evaluiert werden sollen.
Nur eines würde ich lassen: Callback-Argumente sollten niemals selbst wieder Callbacks sein. Damit kommst du in Teufels Küche und kein Debugger kann dir mehr helfen.

**GELight** · 31.01.2008, 08:33

[PHP5] Scriptsprache

Guten Morgen,

Also ich dank euch erstmal für eure Meinungen und Erfahrungen diesbezüglich. Mir war schon irgendwie klar, dass sowas nicht ohne wäre. Bei den echten Sprachen steckt da ja oft die übelste Compliertechnik etc. dahinter... vondaher meinte ich auch, dass es erstmal nur Gedanken sind.

Ich glaube ich versuche meine eigene kleine Variante so weiter zu fahren, wie ich angefangen habe.
Einfach eine Liste an Methoden, die mit bestimmten Befehlen aufgerufen werden und diese einfach nur in echte JavascriptBefehle oder Links umwandeln. Sehr viel mehr braucht man ja meist eh nicht.

Ohne das ich gleich den nächsten neuen Post aufmachen will, hätte ich gleich noch eine Frage bezüglich dem serialisieren.
Kurz und knapp: Spricht etwas dagegen, ein erzeugtes "object" zu serialisieren und in der DB oder Session zu speichern? ( zb: um dieses wieder auf die nächste Seite zu bringen. Am meisten habe ich immer damit zu kämpfen, wie ich meine Daten so zur nächsten Seite bekomme, dass es auch noch relativ sicher bleibt. Hab ja nur GET, POST und die Session zur Verfügung ( cookies hab ich noch nicht so verwendet )

Also was würde für sowas und was gegen sowas sprechen?

Dank euch... Mario

**PHP-Desaster** · 31.01.2008, 09:56

Gegen die Ablage in der Datenbank spricht meistens die Normalisierung, für spricht das Caching. Du musst halt abwägen, wie du damit umgehst. Es ist zum Beispiel super dreckig, ein serialisiertes Array der IDs deiner User auf der Freundschaftsliste direkt in der User-Tabelle abzulegen.
Ich weiß auch nicht, ob ich mit dem arguments-Feld so arbeiten würde wie onemorenerd das macht. Aus Normalisierungssicht wäre eine zweite Tabelle angebrachter oder ich würde eine kommaseparierte Liste verwenden. Aber ein serialisiertes Array ist im PhpMyAdmin etwas ekelig zu editieren...

**combie** · 31.01.2008, 12:53

Serialisierte Array in DBs wiedersprechen schon der ersten Normalform. Von daher braucht es SEHR gute Gründe, um sowas zu tun.

Und bei dem Menubeispiel, sehe ich den Grund nicht.

**TobiaZ** · 31.01.2008, 13:13

db4o

**onemorenerd** · 31.01.2008, 22:20

Das soll nicht 1.NF sein? Das sehe ich aber anders!
Arguments ist ein String, also ein atomares Attribut. Der Inhalt dieser Strings ist aus DB-Sicht völlig belanglos. Das Attribut wird niemals als Selektions- oder Joinkriterium benutzt. Es ist einfach nur ein Anhängsel ... könnte ebensogut ein MD5-Hash sein.

**combie** · 31.01.2008, 22:47

Wenn du es als einen Wert siehst, gut...
Aber es ist doch nur ein String, weil du das Array nicht anders da rein bekommst.

**PHP-Desaster** · 31.01.2008, 23:29

Arguments ist ein String, also ein atomares Attribut.

Naja, es ist schon ein Array, sonst macht der Aufruf mit call_user_func_array wenig Sinn. Als 100%ig Normalisiert würde ich die Tabelle nicht bezeichnen, würde es in diesem Falle aber zulassen!

**onemorenerd** · 01.02.2008, 10:32

Combie, PHP-Desaster, ihr habt mich nicht verstanden.

Ihr schaut durch die PHP-Brille auf die Attributwerte, seht serialisierte Arrays und sagt "das hat Struktur, das muß normalisiert werden".

1. Da liegt ihr falsch, es hat keine Struktur. Ich habe nämlich semantisch definiert, dass es keine hat.
2. Selbst wenn es Struktur hätte, wäre das kein Verstoß gegen die 1.NF. Es wäre erst dann kein atomares Attribut mehr, wenn ich mehrere serialisierte Variablen in einem Feld speichern würde, also z.B. "'i:100','i:100'".

Übrigens habt ihr beide bestimmt schon mal eine DB entworfen, in der URIs gespeichert wurden. Für Zugriffsstatistiken oder was auch immer. Dabei habt ihr die URI sicher komplett in eine Spalte gepumpt.

stats (id, uri) = {(1, 'http://example.com/foo/bar.html?x=1&y=2')}

Setzt ihr jetzt die RFC-2396-Brille auf und sagt "URIs sind strukturiert, das muß normalisiert werden"?

**PHP-Desaster** · 01.02.2008, 10:48

Ok, du hast schon recht, du hast es ja als String definiert. Können wir uns drauf einigen

**combie** · 01.02.2008, 12:43

Du hast jetzt gute Gründe genannt, warum es keinen Schaden anrichtet. Aber leider noch keine, warum es notwendig ist es so abzuhandeln.....

Ich möchte nur zu bedenken geben, dass man sich damit einige Möglichkeiten verbaut. Ich weiß, dass du Ahnung hast. Aber ich habe schon dutzende von Abfängern in vergleichbare Fallen tappen sehen.

Irgendwann könnten solche Fragen auftauchen:

Gib mich alle Fenster, die in der Linken oberen Ecke entstehen
Gib mich alle Fenster, die poll.php benutzen
Ruckel bitte alle Fenster 10px nach links

Sorry, aber das sind so Probleme, die mir beim betrachten einer solchen Lösung sofort ins Auge springen. Was zum großen Teil daran liegt, dass ich auch schon in solche Fallen tappen durfte.
Konkreter: Ja, es ist durchaus möglich, dass sich das Anforderungsprofil einer Applikation nach der Entwurfsphase noch ändert. Und sei es erst nach Jahren.

Betrachte meine Einwände bitte nicht so sehr als Kritik dir gegenüber, sondern mehr als Warnung für Anfänger.

**onemorenerd** · 01.02.2008, 17:52

Oh keine Sorge, ich fühle mich nicht angegriffen.

Du hast jetzt gute Gründe genannt, warum es keinen Schaden anrichtet. Aber leider noch keine, warum es notwendig ist es so abzuhandeln.....

Mein Vorschlag ist nicht notwendig, aber das ausnormalisieren ebenfalls nicht. In dieser Hinsicht gibt es also keine "bessere" Lösung.
Meine ist aber performanter. Ich brauche keine JOINs.

Irgendwann könnten solche Fragen auftauchen:

* Gib mich alle Fenster, die in der Linken oberen Ecke entstehen
* Gib mich alle Fenster, die poll.php benutzen
* Ruckel bitte alle Fenster 10px nach links

Wie ich schon sagte, soll mein Beispiel nur den Ansatz verdeutlichen. Tatsächlich würde ich es so implementieren, dass ich in arguments nur Arrays mit benannten Indizes speichere. Dann kann man solche Fragen auch einigermaßen performant beantworten.

Diese Queries beziehen sich jetzt auf das Beispiel von oben ohne Indizes:
SELECT * FROM table WHERE arguments LIKE 'i:100;i:100;'
SELECT * FROM table WHERE arguments LIKE 's:9:"/poll.php";'
Die 3. Frage währe ein Update mit Where-Klausel ähnlich dem ersten Select. Allerdings könnte man das auch prima in die Callback-Funktion integrieren.

**3DMax** · 01.02.2008, 17:57

Original geschrieben von combie

Gib mich alle Fenster, die in der Linken oberen Ecke entstehen
Gib mich alle Fenster, die poll.php benutzen
Ruckel bitte alle Fenster 10px nach links

Sorry, aber das sind so Probleme, die mir beim betrachten einer solchen Lösung sofort ins Auge springen.

OffTopic:
ja, da springt einem das "mich" in der tat ins auge

[PHP5] Eigene Sriptsprache...