Mailinglisten-Archive |
Hallo, On Mon, Jul 19, 2004 at 12:33:06PM +0200, Enrico Weigelt wrote: > > ich habe unter http://dotweb.berlios.de/ ein Projekt gestartet, um die > > Features von ASP.NET in PHP zu implementieren. > hmm, welche wären das ? Hauptsächlich die unten genannten. > wäre schön, wenn das bei der Gelegenheit auch gleich mit XUL ginge. Wäre eventuell ne Idee für die Zukunft aber jetzt bin ich erstmal froh, dass ich die meisten HTML Tags in Klassen gekapselt habe ;) > Falls Du schon eine Maillist dazu hast, dann trag mich bitte mit ein. Habe ich vorhin angelegt. Sobald sie aktiv ist, werde ich dich eintragen. > Die Struktur ist zwar recht "sauber" aber auch recht beschränkt, > da Du immer nur ein bestimmtes Element manipulierst. patTemplate > verfolgt ja einen rein Textuellen Ansatz - und dort können z.b. > verschiedene Teil-Templates sich ihren Variablen-Scope teilen. Wenn ich das richtig verstehe, dann ist dein Problem, dass jeder Tag bei DotWeb nur einmal existieren kann. Du willst also dass auch sowas möglich ist: <p> {$name} </p> <p> {$name} </p> ... Solche einfachen Platzhalter sind für das nächste Release geplant. Wird Wahrscheinlich so aussehen: <dotweb:text name="name"/> oder so ähnlich. Allerdings ist genau dieses GUI-artige das eigentliche Hauptfeature von DotWeb und auch von ASP.NET. Du kannst jetzt auf dein Template zugreifen und musst dich zur Generierung deiner Formulare und anderer HTML Tags nicht mehr selbst mit HTML rumschlagen. Ich bin zwar weit davon entfernt etwas anderes als vim an meine Templates heranzulassen aber es ist schon ein enormer Vorteil, in seinen PHP Skripten keinen HTML-Code mehr generieren zu müssen. Deshalb habe ich früher Smarty verwendet aber dort hat man das mindestens genauso große Problem, dass man wieder einen großen Teil der Logik im Template hat. Schleifen und ähnliches im Template und dafür ne eigene Programmiersprache mit eigener Syntax nur für die Templates ist eben auch nicht der Weißheit letzter Schluß. Also genaugenommen funktioniert DotWeb so: Zuerst wird das Template geparst und dann wird für jeden DotWeb Tag die entsprechende Klasse aus dem Verzeichnis htmlcontrols gesucht und ein Objekt davon generiert. Dieses Objekt wird mit den HTML-Attributen des Tags (class, style, href etc.) gefüttert. Intern werden alle diese Objekte in einem assoziativen Array gespeichert, wobei die id gleichzeitig der Schlüssel ist. Jetzt kann man die Objekte mit den entsprechenden Methoden manipulieren. Wird das Template dann ausgegeben, dann ruft die Template Engine für jedes Objekt die Methode getCode() auf und setzt die Ausgabe (der HTML Code) an die Stelle, wo im Template der DotWeb Tag steht. > IMHO sollte das eigentlich ganz gut funktionieren und auch beide > Ansätze innerhalb einer Anwendung verfügbar machen (den Layouter > wirds freuen ;-)). An den Layouter habe ich noch garnicht gedacht also ein Punkt den man auf jedenfall noch angehen muss. > Würde mich freuen, wenn wir diesen Weg gemeinsam implementieren > könnten. Über Mitarbeit und konstruktive Kritik freue ich mich immer :) Das können wir gerne weiter besprechen aber irgendwie habe ich grade das Gefühl, dass wir aneinander vorbeireden. > zur Auswertung nehmen. Handler-Routinen erst zu registrieren halte > ich ehrlichgesagt für unnötige Kosmetik. > Da wäre es eher sinnvoll, zum Modul-Code auch noch eine Tabelle > mit möglichen Actions und deren Handlern beizulegen. Dort kann > man später dann auch noch andere Informationen, z.b. fürs > permission handling beilegen ... Ich finde das registrieren eigentlich sehr übersichtlich. Man könnte aber eine optionale Methode hinzufügen, die ein assoziatives Array erwartet, in dem sämtliche Events enthalten sind oder die das aus nem extra File liest. > Mit etwas Hirnschmalz kann man da auch sicher gleich noch multiple views > und Hilfsmittel für mehrseitige Assistenten und dergleichen mit reinbringen. > Sowas sollte IMHO dann alles gleich vom Boxloader erschlagen werden, damit > es nicht nochmal neu programmieren muß. Dazu gehört auch ein > standardisiertes Handling von Durchschleifparametern. Je mehr solche Sachen > abstrahiert werden, um so weniger Gedanken muß man sich dann als > Modulentwickler um lokale Gegebenheiten wie URL-Aufbau, session-handling, > usw machen ... Prinzipiell will ich das ganze in zwei Teile aufteilen. Erstmal den Basic Teil, der Hauptsächlich HTML-Elemente, Event-Handling und Validierung macht. Der Full oder Advanced Teil oder wie auch immer man ihn nennen will, soll ich dann um genau solche Features kümmern. Dazu gehören dann auch Tabellen, die sich direkt in einer Datenbank bedienen und die Ergebnisse wie bei Google auf mehreren Seiten darstellen. Da gibt es sicher noch eine Menge weiterer Ideen. > Etwas Dokuemtation zu meinem Framework findet sich hier: > http://nibiru.borg.metux.de:7000/wiki/index.php/BTPL2 Ich werde es mir morgen mal anschauen. > PS: bevor jetzt jemand nach Smarty schreit - IMHO sind die beiden > engines sogut wie gleichwertig und können sich gegenseitig simulieren. Hat sich da irgendwas getan bei den Template Engines so in Richtung Logik raus aus den Templates? Also ich habe vor zwei Jahren zuletzt ernsthaft mit Smarty gearbeitet aber es hat mich zuletzt nur noch genervt, dass das Skript kaum noch Kontrolle über die Webseite hat und nur noch Daten anliefert. In DotWeb liegt die Kontrolle dann halt komplett im Skript und das erscheint mir ein wesentlich besserer Ansatz zu sein. Andreas -- http://www.mozilla-center.de/ - Deutsche Mozilla News http://dotweb.berlios.de/ - Webforms for PHP
php::bar PHP Wiki - Listenarchive