[Cologne-pm] Release meines Web-Frameworks Konstrukt 0.5 beta 6

[Thomas Wittek]

Joachim Zobel schrieb:
> Weiterhin habe ich festgestellt, das Du ein sql Plugin
> http://gedankenkonstrukt.de/konstrukt-doc/Konstrukt/Doc/FunctionPlugins.html#sql hast. Daz gibt es mehrere Einwände:

Tatsächlich ist das noch ein Relikt aus frühen Tagen des Frameworks. Ich
benutze es auch gar nicht.

Ich bin nämlich (zu) der Meinung (gekommen), dass man mit einer
Tag-Sprache nicht versuchen sollte, Logik zu implementieren. Dafür sind
Programmiersprachen (Perl) wesentlich besser geeignet. Vielleicht sollte
ich dieses "Paradigma" prominenter in der Dokumentation klarstellen.

Daher sind die "größeren" Application Plugins (
http://gedankenkonstrukt.de/konstrukt-doc/Konstrukt/Doc/ApplicationPlugins.html
) auch vollständig in Perl realisiert und nutzen eigene Backend-Module,
die DBI nutzen.

Die Tag-Schnittstelle soll dazu dienen:

a) Die Präsentation abzuwickeln. Dazu werden hauptsächlich die "Function
Plugins" benutzt:
http://gedankenkonstrukt.de/konstrukt-doc/Konstrukt/Doc/FunctionPlugins.html
Also template, if, uriencode, perl, ... .

b) Die Anwendungen in die Webseiten einzubinden. Siehe z.B.
http://gedankenkonstrukt.de/konstrukt-doc/Konstrukt/Doc/Tutorial/Usage/Blog.html

> 1. Du benutzt  SQL im Attribut. Da aber komplexe Abfragen schnell 25
> Zeilen erreichen können, führt das zu ziemlich langen Attributen.

Das stimmt. Es wäre besser, die Abfrage in den Inhalt des Tags zu verlegen.

Allerdings ist das Plugin ohnehin nicht für komplexe Abfragen gedacht.
Wer komplexe Abfragen hat, wird oft auch komplexe Anwendungen haben, die
man generell nicht mit einer Tag-Sprache, sondern einer
Programmiersprache entwickeln will. Da kommt das SQL-Plugin also ohnehin
nicht in Frage.

> Evtl möchtest Du etwas wie SQIL 
> http://www.heute-morgen.de/modules/mod_sqil/
> benutzen.

Das Ergebnis war ursprünglich sehr ähnlich. Das sql-Plugin gab Tags aus,
die man in Verbindung mit Templates nutzen also damit darstellen konnte.

Allerdings war das relativ inperformant und das Plugin wurde wegen
mangelnder Verwendung nicht wirklich weiterentwickelt.

> 2. Dein sql Plgin kann Daten ändern. Das führt sehr leicht dazu, das
> Seitenaufrufe (GET) schreibend auf daten zugreifen. Das ist böse:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1

Das sollte demjenigen, der das Plugin einsetzt bewusst sein, da er dazu
explizit GET-Werte (z.B. über das param-Plugin) in das sql-Plugin
einsetzen muss. Der Client selbst kann nicht automatisch über
GET-Anfragen die SQL-Abfrage beeinflussen.

-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: streawkceur at jabber.i-pobox.net