[cologne-pm] Template tool / AJAX etc.

Aristoteles Pagaltzis pagaltzis at gmx.de
So Mär 16 06:32:45 PDT 2008


* Patrick Krusenotto <pkruseno at t-online.de> [2008-03-16 02:20]:
> Dennoch habe ich schon Frameworks gesehen, die ähnliches
> leisten und die schneller angewendet werden können. Ich habe
> mich mal mit dem AppServer Zope befasst: Obwohl ich viele Jahre
> Perl Erfehrung und viel weniger Python-Erfahrung habe, kann ich
> sagen, daß ich mit Zope schneller zurecht kam.

Ja, einfache Dinge sind in Zope sehr viel einfacher. Wie es in
der anderen Richtung aussieht, dazu lasse ich mich an dieser
Stelle nicht aus…

> Django (ebenfalls ein Python-FW) hat auch einiges zu bieten.

Django ist wirklich gut; während mich Rails nicht ansatzweise
reizt, schiele ich zu Django gelegentlich hinüber. Ein Jammer,
dass es in Python geschrieben ist… die Sprache liegt mir auf
Biegen und Brechen einfach nicht.

> Natürlich hast Du recht, wenn Du sagst, daß jedes Framework
> Einarbeitungszeit braucht, aber es geht, wie ich glaube, auch
> leichter.

Das liegt bei Catalyst mMn vor allem an der dürren, verworrenen
Dokumentation. Das Framework selbst finde ich ziemlich eingängig,
wenn man erst einmal an die nötige Information gekommen ist. Der
Einstieg in Catalyst kann also leicht weiter verbessert werden,
und in der Tat hat sich gegenüber den ursprünglichen Zuständen
schon sehr viel getan.

> Wenn Perl erstmal Continuations kann, werden noch viel bessere
> Konzepte die Runde machen.

Schon längst der Fall. http://search.cpan.org/dist/Continuity/

Continuations halte ich selber aber für den falschen Ansatz als
Basis für Webanwendungen.

> Deutet aber diese Tatsache nicht an, daß die Grenzen zwischen
> M, V, und C in der Praxis schwer zu ziehen sind?

Vor allem deutet sie an, dass MVC für Desktop-GUI-Anwendungen
konzipiert wurde, wo der View nicht bloss einmal gerendert wird
und dann dümmlich herumsitzt, bis der Benutzer eine neue Seite
reinklickt, sondern direkt und selbständig auf Änderungen im
Model reagieren kann. ZB.: Benutzer legt in Fenster 2 neuen
Datensatz an; Liste in Fenster 1 aktualisiert sich automatisch.
Sowas geht bei Webanwendungen nicht in derselben Form wie bei
dem Smalltalk-GUIs, wofür MVC erfunden wurde. (Mittlerweile kann
man mit Ajax bzw Comet da ein bisschen nachbessern, aber das hat
immer noch nichts wirklich mit MVC gemein.)

Die Django-Leute haben daher anfangs ihr Framework-Pattern auch
nicht als MVC sondern als MTV bezeichnet (Model/Template/View).
Irgendwann haben sie aber nachgegeben, weil das marketing-
technisch ein Schuss in den Ofen war: viele Leser sahen sich
dadurch zu dem Schluss veranlasst, dass Django nicht die Sachen
könne, die *richtige* MVC-Frameworks könnten.

Andy Wardley, der Autor von Template Toolkit, hat mal eine Tirade
zum Thema »MVC in Webframeworks« geschrieben, die ich an dieser
Stelle empfehlen kann: http://wardley.org/computers/web/mvc.html

> Ich habe noch keine View gesehen, die ich aus einer
> Forensoftware rausnehmen und fuer eine Kalendersofteare
> verwenden könnte.

Äh, und? Das zu leisten ist nicht Zweck der MVC-Aufgabenteilung.

> Ich sehe den Vorteil von MVC eher darin, daß es dem Team hilft,
> auf oberster Ebene in drei Konzeptionen zu denken. Weniger
> darin, daß MVC sein eigentliches Versprechen einlöst.

Mit Verlaub, ich glaube, dass liegt eher daran, dass du das
eigentliche Versprechen von MVC gar nicht kennst.

Gruß,
-- 
Aristoteles Pagaltzis // <http://plasmasturm.org/>