phpbar.de logo

Mailinglisten-Archive

[php] Projektankündigung: DotWeb

[php] Projektankündigung: DotWeb

Andreas Heck aheck at mozilla-center.de
Die Jul 20 02:56:36 CEST 2004


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