Wicket-artiges komponentenbasiertes Rahmenwerk: Sinnvoll?

[deamon]

Als Anstifter zur Diskussion über Python-Wicket muss ich mich jetzt auch mal zu Wort melden. Es kommt immer wieder zur Sprache, warum Stefan nicht einfach Template-System X nimmt. Es wurde auch schon ein paar mal auf die wesentlichen Unterschiede zu Wicket eingegangen, aber da ich Wicket kenne, fühle ich mich dazu berufen, mich hier noch mal einzuklinken.

* Ein ganz zentraler Unterschied ist, dass bei Wicket keine Logik (Verzweigungen, Schleifen usw.) im Template vorkommen, dort stehen wirklich nur Element-IDs und ggf. ein paar Spezialtags, etwa zum Gruppieren bei Vererbung.

* Die Komponenten sind nach dem Entwurfsmuster Kompositum aufgebaut. Das bedeutet, dass man sie praktisch beliebig in einander verschachteln kann.

* Darauf folgt dann auch, dass die Struktur nicht flach wie bei normalen Templates ist, sondern ein Komponentenbaum.

* Dadurch kann man auch sehr leicht wiederverwendbare Komponenten erstellen. Man könnte z. B. ein TabbedPanel definieren, dem man die Tabs übergibt, zwischen denen mit Reitern umgeschaltet werden kann. Dieses Panel kann man bequem immer wieder verwenden.

* Die Komponenten reagieren auf Ereignisse, damit ist der HTTP-bedingte Bruch praktisch weg. GUI-Komponenten können über Methoden ihr Verhalten/Aussehen ändern.

* Es ist komplett objektorientiert. Normalerweise hört die Objektorientierung in den Templates auf. Man kann von einer Seite zur nächsten über Objekte kommen und braucht keine HTTP-Parameter. Beispiel: setResponsePage(new BestellFormular(kunde))

* Wenn man es zu Ende bringt, integriert sich AJAX ganz natürlich in die Anwendung.

Das fällt mir jetzt spontan ein. Wer interesse hat, spielt am besten mal etwas mit den Wicket-Beispielen, dann versteht man es besser.

Noch eine Anmerkung zu Stefans Frage nach der Zustandsspeicherung. Wicket speichert die Zustände der zuvor besuchten Seiten nur teilweise in der Session, ältere Zustände werden auf der Festplatte, in einer Datenbank oder wo auch immer gespeichert. Das kann man konfigurieren oder auch selbst einen Speicher implementieren.

Allerdings gibt es ein Problem, wenn man auch alle verbundenen Modelobjekte mitspeichert, denn dann wird es sehr schnell eng mit dem Hauptspeicher. Dafür gibt es bei Wicket LoadableDetachableModels, die nur eine ID beinhalten und beim Zugriff die Daten aus der DB laden. Hilfreich sind dann Pufferspeicher des Persistenz-Frameworks (wie Hibernate oder bei Python SQLAlchemy).

Ich glaube, so ein Framework für Python hätte extrem viel Potenzial, denn sowas gibt es bisher für Skriptsprachen meines Wissen nach nicht und wenn man sich von dem klassischen MVC-Modell gelöst hat, programmiert es sich irgendwie "natürlicher" damit.

[sma]

Ich glaube, so ein Framework für Python hätte extrem viel Potenzial, denn sowas gibt es bisher für Skriptsprachen meines Wissen nach nicht

Seaside basiert auch auf einem Komponentenmodell. Allerdings ohne Templates. Hier wird das HTML per "DSL" aus Smalltalk heraus erzeugt. So etwas wäre in Python allerdings ausgesprochen sperrig und IMHO kein Vorteil. Die Komponenten, da stimme ich dir zu, sind auch hier ein Vorteil. Besonders, wenn man "klassische" GUI-Programmierung gewohnt ist.

Ich bin ein bisschen von Python und meinen Experimenten abgekommen, aber ich werde das demnächst noch mal fortsetzen. Wicket habe ich jedoch das letzte Mal vor über 3 Jahren eingesetzt, so genau kenne ich da die Details nicht.

Stefan

[Leonidas]

Hier wird das HTML per "DSL" aus Smalltalk heraus erzeugt. So etwas wäre in Python allerdings ausgesprochen sperrig und IMHO kein Vorteil.

Du meinst sowas wie Nevow Stan oder Breve (und im Scheme-Umfeld übliche HTML-Makros)?

[Darii]

Ich glaube, so ein Framework für Python hätte extrem viel Potenzial, denn sowas gibt es bisher für Skriptsprachen meines Wissen nach nicht und wenn man sich von dem klassischen MVC-Modell gelöst hat, programmiert es sich irgendwie "natürlicher" damit.

Da ist die Frage, was „klassisches MVC“ ist. Klassisches MVC auf dem Desktop funktioniert ja ähnlich wie Wicket.

Ganz interessant finde ich auch den Ansatz von Sproutcore, da läuft der Großteil der Logik im Browser ab.

[sma]

Du meinst sowas wie Nevow Stan oder Breve (und im Scheme-Umfeld übliche HTML-Makros)?

Seaside nutzt Smalltalk-Blöcke, um HTML zu schachteln:

Code: Alles auswählen

renderContentOn: html
    html div id: #header; with: [
        html heading with: [
            self hasImage ifTrue: [html image: '...']; text: self title
        ]
    ]

Noch eleganter ist IMHO Markaby für Ruby:

Code: Alles auswählen

def render(html)
  html do
    div.header! do
      if self.has_image? then image "..." end; text self.title
    end
  end

Der Weg in Python wäre entweder `with` zu benutzen oder eine funktionale Variante wie die von dir erwähnten Beispiele zu fahren:

Code: Alles auswählen

def content(self, html):
    return \
    html.div(id="header")[
        html.heading[
            html.WHEN(lambda: self.has_image)[
                html.image("...")
            ],
            html.text(self.title),
        ],
    ]

Nachteil hierbei: Man kann nicht einfach if, while, usw. benutzen, sondern muss funktionale Äquivalente finden. Das ist eine Einschränkung und man erfindet wieder eine Sprache, wo Seaside einfach Smalltalk benutzt.

Man könnte sich vielleicht überlegen, es so zu schreiben:

Code: Alles auswählen

def render(self):
    +'<div id="header">'
    if self.has_image:
        +'<img src="%s"/>' % self.image_url
    +'</div>'

Und dann den Bytecode einer solchen Methode zu transformieren, dass jedes unäre "+" sein Argument zu einem Ergebnisstring addiert. Elegant ist aber auch etwas anderes. Scala oder JavaScript mit E4X machen's eigentlich ganz nett. Dort kann man XML-Ausdrücke direkt als Literale benutzen. Löst aber auch nicht das Problem, wie man den Seiteneffekt nutzen kann.

Bei Ioke hatte ich eine schöne Idee gesehen. Der Compiler erzeugt für ein Literal automatisch eine "create"-Methode, die intern aufgerufen wird und innerhalb einer Methode oder eines Blocks dann überschrieben werden kann. Dafür ist die restliche Syntax eher ungewöhnlich, eine Melange aus Io und Ruby mit einer Prise Smalltalk und Scheme.

Worauf wollte ich eigentlich hinaus? Egal :)

Stefan

[sma]

Da ist die Frage, was „klassisches MVC“ ist.

Das ist das, was 1978 von Trygve fürs Smalltalk-UI erfunden wurde. Gerne lasse ich auch noch mit mir über MVP als modernere Variante (ursprünglich aus dem Taligent-Projekt in C++, später in Dolphin Smalltalk umgesetzt) reden, aber Webanwendungen haben den Begriff MVC eigentlich gestohlen und umdefiniert. Auch dort passt er, aber eben mit einer anderen Bedeutung. Besser wäre gewesen, sich einen neuen Begriff (MVT wie Django es hat?) auszudenken. Naja, zu spät.

Stefan

[kieselsteini]

Hallo zusammen.

Ich bin ziemlich neu in Python und fange gerade erst mit der Sprache an. Allerdings habe ich davor sehr viel im Java Webbereich programmiert und vorallem mit Wicket. Ein Wicket ähnliches Framework für Python wäre der Hammer. Ich weiß dieser Thread ist etwas alt, aber falls ihr noch einen Freiwilligen sucht, der euch da etwas helfen kann. Lasst es mich wissen. Ich schau mir jedenfalls mal heute Abend den Code an und dann sehe ich ja, ab ich davon was verstehe oder nicht

[sma]

Hi kieselsteini, willkommen.

Ob Wicket ein gutes Vorbild für ein Python-Rahmenwerk ist, ist für mich nach wie vor eine offene Frage. Wicket setzt sehr stark auf anonyme innere Klassen und das ist in Python eher doof, weil es da keine so kompakte Form gibt. Ruby (dank Code-Blöcken) wäre glaube ich überlegen. Vielleicht kannst du da ja deine Meinung mitteilen. Sie würde mich interessieren.

Irgendwo in diesem Forum müsste auch noch etwas von mir zum Thema Seaside für Python stehen - das Rahmenwerk ist ebenfalls komponentenbasiert und durchaus ähnlich zu Wicket. Kennst du eigentlich auch Tapestry? Die 5er Version soll ja auch ganz gut sein, aber ich habe nur divuse Kenntnisse zu Version 3.

Meinen Prototyp ist übrigens noch ein bisschen umfangreicher, als was ich hier gepostet habe, aber bei weitem noch kein vollständiges Wicket.

Stefan