[php] Projektankündigung: DotWeb

[Enrico Weigelt]

* Andreas Heck <aheck at mozilla-center.de> schrieb:

moin,

> 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 ?

<snip>
> Konkret kann man damit Templates anlegen und bei Bedarf die einzelnen
> HTML-Tags und Formularelemente als Objekte ansprechen, wie man das aus
> der GUI-Programmierung gewohnt ist und man kann Events definieren, die
> ausgelößt werden wenn z.B. die Variable action den Wert view hat und
> dann wird eine vorher festgelegte Funktion ausgeführt.
hmm. klingt nicht schlecht. 
wäre schön, wenn das bei der Gelegenheit auch gleich mit XUL ginge.

<snip>
> Falls euch das jetzt interessiert solltet ihr euch am besten mal das
> Tutorial unter http://dotweb.berlios.de/tutorial.html anschauen.

Falls Du schon eine Maillist dazu hast, dann trag mich bitte mit ein.

btw ist mir beim Durchlesen der Seite folgendes aufgefallen:

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.
Beipiel: Du hast ein Seitenelement, das nur unter einer bestimmten
Bedingung eingeschaltet wird (z.b. Account-Daten wenn eingeloggt).
Hier schaltet man einfach ein Template ein und füllt es mit den
nötigen Daten. Soweit ja noch kein Problem bei dotweb - geht da
sicher auch. Aber: nun kommt der Layouter auf die Idee, auf
der ganzen Seite verteilt das an mehreren Stellen ("fettzenweise")
darstellen zu wollen. Bei Deiner API muß man dann mehrere solche 
solche Widgets bauen, die dann einzeln gefüttert werden müssen.
Bei der patTemplate geht das alles den Anwendungsentwickler nichts
mehr an - der Layouter kann das selbst definieren. (grade bei 
Anwendungsdiensten ist das von großem Vorteil).

Zudem bist Du bei Deiner API direkt an einzelnene Elemente 
festgenagelt und kannst die nur einzeln beeinflussen. Dabei muß 
aber der Programmierer genau wissen bzw. genau festlegen, wie die 
Seitenstruktur auszusehen hat. Zwar macht das gewisse Dinge 
einfacher, wenn man *nur* darauf aus ist, klassische GUIs per
Web nachzubauen (was ich nicht unbedingt für sinnvoll halte),
aber bei der Konfektionierbarkeit mußt Du damit große 
Abstriche machen.

Semantisch scheint mir Deine Template-Engine eine Teilmenge von
patTemplate zu sein, d.h. sie ließe sich mit einem angepaßten
Template-Parser auch mit patTemplate simulieren: Dein Template
wird zunächst als großes Einzeltemplate geparsed. Alle 
beeinflußbaren Attribute (sicher auch die content-section ;-)) 
der dotweb-Elemente werden dann durch passende Variablen ersetzt
(die im Template definierten Daten werden dann als Standardwerte
geladen). Man könnte sich hierfür sicher einfache ein Mapping 
von dotweb-Elementattributen auf Variablennamen überlegen
(z.b. "DOTWEB:"<Element-ID>":"<Attribut-Name>). Nach genau diesem
Mapping greift auch die dotweb-API auf die Elemente zu 
(genaugenommen greif sie nicht wirklich auf die Elemente, sondern
nur auf die entsprechenden Inhalte - die DOM-Struktur gibt es
ja innerhalb patTempalte dann nicht mehr).

IMHO sollte das eigentlich ganz gut funktionieren und auch beide
Ansätze innerhalb einer Anwendung verfügbar machen (den Layouter
wirds freuen ;-)).

Würde mich freuen, wenn wir diesen Weg gemeinsam implementieren
könnten.

Zum Event-Handling und Sitestruktur: 
Ich hab dazu ein eigenes Framework (einst aus dem Modulsystem 
des C*B hervorgegangen ...), das nicht nur die Seiten in Boxen
modelliert und einzelne Seiten über einen "Multiplexer"
abbildet (die loader-Box hat eine Tabelle mit ladbaren 
Boxen, die anhand eines URI-Parameters selektiert werden).
Derzeit arbeite ich auch daran, das ganze mit einem URI-
Handler derart zu verbacken, daß man den Boxnamen aus aus
dem URL-Part statt der Query holen kann, z.b. 
http://foo.org/seite1/
http://foo.org/seite2/
...

Die einzelne Box bekommt dann auch den action-Parameter in ihrer
Box-Config übergeben, ergo kann man da doch einfach ein switch()
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 ...

./modules/box.foo/
    -> box_display.inc		=> normaler Code zur Anzeige
    -> actions.db		=> definiert die möglichen actions
    
actions.db
-----------
action:		validate_form
source:		$(action).inc
handler:	foobox_handle_$(action)
--  
action:		store_data
source:		$(action).inc
handler:	foobox_handle_$(action)
-- 
...


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 ...


Etwas Dokuemtation zu meinem Framework findet sich hier:
http://nibiru.borg.metux.de:7000/wiki/index.php/BTPL2

(das wiki wird irgentwann wohl auch mal damit realisiert ;-))


cu

PS: bevor jetzt jemand nach Smarty schreit - IMHO sind die beiden
engines sogut wie gleichwertig und können sich gegenseitig simulieren.
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------