Wicket-artiges komponentenbasiertes Rahmenwerk: Sinnvoll?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Beitragvon Darii » Dienstag 5. Mai 2009, 19:51

derdon hat geschrieben:
Darii hat geschrieben:HTML verlangt sowieso nur die Existenz eines doctypes und <title>, mehr ist überflüssig ;) *scnr*


Wo ist der Witz?
Dass das wirklich so ist, sma hatte das ja mehr Scherzhaft gemeint und dann gibts ja noch die shorttags, damit lassen sich recht krude, aber valide Dokumente basteln. Also am besten einfach vergessen, was du über HTML gelernt hast – es stimmt nicht ;)
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Dienstag 5. Mai 2009, 22:20

Das wird mir hier alles zu unübersichtlich. Daher ein Beispiel, um zu zeigen, dass man das HTML für ein Page-Objekt natürlich auch extern als Datei verwalten kann:

Code: Alles auswählen

# example/pages.py
class TemplatePage(web.Page):
    @property
    def html(self):
        d = os.path.splitext(sys.modules[self.__class__.__module__].__file__)[0]
        with os.path.join(d, self.__class__.__name__ + ".html") as f:
            return f.read()

class Welcome(TemplatePage):
    def create(self):
        self.add(web.Label("message", "Hello, World!"))


Code: Alles auswählen

<!-- example/pages/Welcome.html -->
<html>
  <head>
    <title>Example</title>
    <style type="text/css">
      ...
    </style>
  </head>
  <body>
    <h1 web:id="message">greeting...</h1>
  </body>
</html>


Alternativ kann ich Layouts einführen, die noch mal Gemeinsamkeiten verschiedener Seiten zusammenfassen. Ich verweise da auf die Wicket-Dokumentation.

Stefan
Benutzeravatar
Hyperion
Moderator
Beiträge: 7471
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Beitragvon Hyperion » Dienstag 5. Mai 2009, 22:30

Gibts einen Grund, wieso Du das Templating selber implementierst? Evtl. beantwortet das die Frage, wieso z.B. jinja2 da keine Option für eine Trennung von Code und HTML ist.
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Beitragvon Darii » Dienstag 5. Mai 2009, 22:34

Um das ganze „pythonischer“ zu machen könnte man da auch Mixins über Mehrfachvererbung nutzen.

Code: Alles auswählen

class Welcome(web.Page, AutoTemplate): pass


ich fänds zumindest von der Objekthierarchie schöner.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Donnerstag 7. Mai 2009, 10:26

Mixins waren tatsächlich ebenfalls meine erste Idee, ich fand's für die Diskussion aber mit einer einfachen Unterklasse verständlicher.

Hyperion, Jinja verhält sich nicht wie Wicket und genau das habe ich ja nachbauen wollen. Daher kann ich Jinja auch nicht einsetzen.

Schließlich fing ich an, Gefallen an der Idee zu finden, auf diese Weise ein Web-Rahmenwerk für Python 3 (ich fragte vor einiger Zeit ja mal danach) zu bekommen, welches möglichst keine externen Abhängigkeiten haben sollte, damit ich das mit meinem eigenen Python-Interpreter (wenn ich ihn dann weitergebaut habe) laufen lassen kann. Steht aber alles in meinem "Wicket in Python"-Artikel am Ende von http://gist.github.com/106070

Stefan
deamon
User
Beiträge: 63
Registriert: Mittwoch 8. Oktober 2008, 11:14

Beitragvon deamon » Dienstag 12. Mai 2009, 19:23

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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Mittwoch 13. Mai 2009, 19:32

deamon hat geschrieben: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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 13. Mai 2009, 22:37

sma hat geschrieben: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)?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Beitragvon Darii » Donnerstag 14. Mai 2009, 09:19

deamon hat geschrieben: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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Donnerstag 14. Mai 2009, 12:06

Leonidas hat geschrieben: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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Donnerstag 14. Mai 2009, 12:21

Darii hat geschrieben: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
User
Beiträge: 3
Registriert: Donnerstag 3. September 2009, 10:39

Beitragvon kieselsteini » Donnerstag 3. September 2009, 10:52

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 :D
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Donnerstag 3. September 2009, 20:41

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

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder