PYJAMAS Build und Start Hilfstool

Michael Schneider · Sonntag 31. Oktober 2010, 21:17

Hallo,

ich habe gestern begonnen, mich in Pyjamas einzuarbeiten und bin spontan begeistert. Kurz zuvor hatte ich mir GWT und Java angesehen und dabei mal wieder das kalte Grauen ob dieser einengenden, rückständigen Sprachstruktur und vor allem Syntax bekommen. Ich hoffe, dass sich Pyjamas bald weit verbreiten wird, weil es einfach das bessere Toolkit ist und mit einem einfachen Designer und einer umfangreicheren Bibliothek dem GXT auch in nichts nachstehen sollte.

Aber zurück zum Tool:
http://skylet.de/pyjamas/buildstart.pyw
Evtl. die Dateinamenserweiterung in .py umbenennen. Auf dem Server werden .py-Dateien über mod_python gleich ausgeführt, darum konnte ich die Datei nicht mit .py speichern.

Einfach in ein Verzeichnis kopieren und mit "python buildstart.pyw" oder Doppelklick starten.

Infos zur GUI und Anwendung:
- im oberen Bereich finden sich zwei Eingabefelder
- das obere gibt den Pfad des Builders (pyjsbuild) an
- der untere den Pfad des auszuführenden Anwendungsskripts
- über die Buttons können die Dateien auch per Dialogbox gewählt werden.
- der Pfad des Builders erlaubt die Eingabe von Parametern nach dem Dateinamen
- ist die Eingabe keine existierende Datei, wird das Eingabefeld rot hinterlegt

- unter den Eingabefeldern befindet sich der Knopf zum Starten der Konvertierung
- darunter des Infofenster
- Fehler werden im Infofenster rot hinterlegt
- bei Klick auf den Knopf
-- werden die eingegebenen Dateipfade in einer Datei "conf.dat" gespeichert
-- wird das Infofenster automatisch gelöscht und der Fortschritt angezeigt
-- wird nach erfolgreicher Konvertierung die erzeugte html-Datei im Standardbrowser geöffnet

Ich freue mich über Kommentare und Bug-Reports.

LG,
Michael

bittner · Montag 1. November 2010, 07:26

Hallo Michael,

ich habe Dein Tool unter Ubuntu Lucid ausprobiert. Damit es dort läuft, muss man 2 Dinge im Script ändern:

Zeilen 2 und 191: popen2 wird unter Python > 2.6 als deprecated gemeldet, daher ersetzen durch:
Code: Alles auswählen
```
from subprocess import Popen
```
... und auf Zeile 191 entsprechend korrigieren (Popen ist dann keine function/def mehr, sondern eine Klasse. Siehe Dokumentation)
Zeile 99: builder_filepath ist leer beim Starten, daher die Zeile builder_filepath = builder_filepath.split()[0] ersetzen durch:
Code: Alles auswählen
```
        if len(builder_filepath) > 0:
            builder_filepath = builder_filepath.split()[0] # cut params, if existing
```

Starten tut's damit einmal unter Ubuntu. Ausprobiert habe ich noch nicht viel, bin nämlich auch ein Pyjamas-Neuling.

Den Test auf Existenz des Files muss Du nötigenfalls überarbeiten: Wenn ein Leerzeichen im Dateinamen vorkommt, bleibt das Feld nämlich auch rot (weil wegen dem split() der Dateiname nur bis zum Leerzeichen geht, der Rest dahinter wird als Parameter betrachtet, klar).

Liebe Grüße!

Michael Schneider · Montag 1. November 2010, 09:15

Hallo,

vielen Dank für den Test und die schnelle Antwort!

bittner hat geschrieben:
Zeilen 2 und 191: popen2 wird unter Python > 2.6 als deprecated gemeldet, daher ersetzen durch:
Code: Alles auswählen
from subprocess import Popen
... und auf Zeile 191 entsprechend korrigieren (Popen ist dann keine function/def mehr, sondern eine Klasse. Siehe Dokumentation)

Ich war mir nicht sicher wegen der Rückwärtskompatibilität und nutze derzeit hauptsächlich Python 2.5. Aber da es das Modul ja schon seit 2.4 gibt, ist das natürlich eine gute Alternative.

bittner hat geschrieben:
Zeile 99: builder_filepath ist leer beim Starten, daher die Zeile builder_filepath = builder_filepath.split()[0] ersetzen durch:
Code: Alles auswählen
        if len(builder_filepath) > 0:
            builder_filepath = builder_filepath.split()[0] # cut params, if existing

Na sowas, man lernt eben täglich dazu. Ich dachte, dass ein leeres Split auf einen Leerstring ein Element zurückgibt. Aber das split() liefert tatsächlich eine leere Liste. Sowas Dummes aber auch.

Das kommt davon, wenn man in Version 1.1 'mal schnell' noch ein paar Dinge einbauen will.

bittner hat geschrieben:Den Test auf Existenz des Files muss Du nötigenfalls überarbeiten: Wenn ein Leerzeichen im Dateinamen vorkommt, bleibt das Feld nämlich auch rot (weil wegen dem split() der Dateiname nur bis zum Leerzeichen geht, der Rest dahinter wird als Parameter betrachtet, klar).

Leerzeichen im Dateipfad? Wer macht denn sowas??

Mal ehrlich, wer die grundlegendsten Konventionen ignoriert, ist doch selbst schuld, oder? :K
lool

Also gut, ich habe jetzt eine recht umständliche und daher potenziell fehleranfällige Quote-Analyse eingebaut. Danke nochmal für die wertvollen Hinweise!

LG,
Michael

sma · Montag 1. November 2010, 10:44

Michael Schneider hat geschrieben:Ich hoffe, dass sich Pyjamas bald weit verbreiten wird

Was nicht ist, kann natürlich noch werden, aber Pyjamas dümpelt schon seit über 4 Jahren vor sich hin und hat IMHO keine signifikante Community um sich versammeln können, so dass ich da ein bisschen skeptisch bin. Schon bei GWT würde ich sagen, dass der Ansatz umstritten ist, und das Gros der Entwickler lieber direkt JavaScript benutzt. Was ich bei GXT (und GWT) praktisch fand, war die statische Typisierung. Ich habe beim Ausprobieren von Ext nicht eine Zeile ohne blöden Syntaxfehler geschrieben und musste laufend die ungewohnte Microsoft-artige Dokumentation heranziehen, um Kleinigkeiten nachzuschlagen. Das war frustrierend. Mit GXT konnte ich die Code-Completion meiner Java-IDE benutzen und das ganze fühlte sich viel produktiver an. Diesen Vorteil hat Pyjamas nicht. Zumal ist die Dokumentation lückenhaft. Warum soll ich da nicht direkt JavaScript benutzen? Welchen Vorteil habe ich durch Python plus eigene GUI- Komponenten? Will ich ein mächtiges Desktop-artiges UI (und stört mich die Lizenz nicht) kann ich Ext direkt benutzen und habe auch noch ca. 30.000 andere Leute in der "Community". Bei GXT wären es zumindest noch ein paar Tausend andere. Bei Pyjamas sind es gefühlt nur ein paar Hundert - maximal.

Stefan

BlackJack · Montag 1. November 2010, 12:25

@Michael Schneider: Was meinst Du mit Quote-Analyse? Hast Du vielleicht das `shlex`-Modul aus der Standardbibliothek nachgebaut?

Michael Schneider · Montag 1. November 2010, 19:20

BlackJack hat geschrieben:@Michael Schneider: Was meinst Du mit Quote-Analyse? Hast Du vielleicht das `shlex`-Modul aus der Standardbibliothek nachgebaut?

Aaahhm, ne. Meins ist wohl komplizierter und fehleranfälliger.

Aber ich musste gerade lesen, dass shlex kein Unicode-Input unterstützt. Und wenn Leute schon Leerzeichen in ihre Dateipfade packen, dann schaffen sie auch Umlaute. Weißt Du, ob shlex mit latin-1 umgehen kann?

BlackJack · Montag 1. November 2010, 19:46

@Michael Schneider: Hast Du denn an der Stelle überhaupt Unicode? Ich glaube Du bringst da gerade Unicode und UTF-8 durcheinander. `shlex` will Bytes. Also bei Python 2.x den Datentyp `str`. Ob da nun etwas drinsteht das mit UTF-8, Latin-1, oder sonstwas dekodiert werden müsste, ist dem Modul ziemlich egal.

Michael Schneider · Montag 1. November 2010, 19:53

Moin Stefan!

sma hat geschrieben:
Michael Schneider hat geschrieben:Ich hoffe, dass sich Pyjamas bald weit verbreiten wird
Was nicht ist, kann natürlich noch werden, aber Pyjamas dümpelt schon seit über 4 Jahren vor sich hin und hat IMHO keine signifikante Community um sich versammeln können, so dass ich da ein bisschen skeptisch bin. Schon bei GWT würde ich sagen, dass der Ansatz umstritten ist, und das Gros der Entwickler lieber direkt JavaScript benutzt.

Ich kenne dazu keine Statistiken oder Umfragen. Aber wer heute noch JavaScript browserspezifisch (sagen wir mal nur für die gängigsten 5 bis 7 Browser) programmiert und sich all den möglichen Besonderheiten auskennt, der hat meine tiefste Bewunderung. In der Regel werden ohnehin kleine oder größere JavaScript-Frameworks wie JQuery oder Mootools verwendet, die sich darum kümmern.

Trotzdem halte ich nicht für realistisch, dass man auf diesem Weg produktiv eine Client-Anwendung entwickeln kann, die nur beim Laden der HTML-Seite geladen wird und sich dann komplett um den Auf- und Abbau der GUI zur Laufzeit kümmert. Eben eine RMI, und nicht nur html-Seiten mit ein bisschen Interoperabilität.

sma hat geschrieben: Was ich bei GXT (und GWT) praktisch fand, war die statische Typisierung. Ich habe beim Ausprobieren von Ext nicht eine Zeile ohne blöden Syntaxfehler geschrieben und musste laufend die ungewohnte Microsoft-artige Dokumentation heranziehen, um Kleinigkeiten nachzuschlagen. Das war frustrierend. Mit GXT konnte ich die Code-Completion meiner Java-IDE benutzen und das ganze fühlte sich viel produktiver an. Diesen Vorteil hat Pyjamas nicht.

Ja, autocompletion funktioniert mit JAVA besser, aber die gibt es auch für Python und Pyjamas. Soll es zumindest laut Wikipedia.

sma hat geschrieben:Zumal ist die Dokumentation lückenhaft. Warum soll ich da nicht direkt JavaScript benutzen?

JavaScript wegen den vielen vielen Eigensinnigkeiten der verschiedenen Versionen auf verschiedenen Browsern und der recht umständlichen Programmierung... naja, siehe oben.

Und was meinst Du mit lückenhafter Dokumentation? Ok, sie hat scheinbar keine ganz so klare Linie, aber was genau fehlt Dir?

sma hat geschrieben:Welchen Vorteil habe ich durch Python plus eigene GUI- Komponenten?

Ich hoffe, Du hast Deine Frage nach dem Vorteil von Python vor dem Hintergrund einer völlig überladenen Java-Alternative nicht wirklich ernst gemeint.

Also wenn ich Dir darauf tatsächlich antworten muss/soll, werde ich das natürlich tun...

Auf jeden Fall gibt es keine wirklichen Nachteile, denn die Pyjamas Widgets sind aus GWT fast 1:1 portiert. Das heißt nach der Generierung der APP gilt auch das mit am häufigsten benannte Java-Argument des versteckten know-hows nicht mehr.

Ich denke, der Hauptgrund warum Durchschnittsnutzer und Noobs sich für GWT entscheiden, ist einfach das große blendende Angebot an new-style Widgets (EXT) und der wysiwyg Editor für Eclipse. Wenige wissen es, aber es gibt auch einen solchen Editor für Pyjamas, pyjsglade.

Aufgrund dieser augenscheinlichen Leichtigkeit, mit der die Widgets auf Googles Beispielseite präsentiert werden, werden viele User getäuscht und stehen dann ganz plötzlich vor verwirrenden Java-Klassen mitten im Quellcode und müssen sich Gedanken machen, wie sie ihre Daten denn am besten mit Java verarbeiten. Sie quälen sich in diese einengende Sprache, ohne zu wissen, wie frei und einfach sie dasselbe mit Python erreichen könnten. Ich gebe ja zu, dass auch Java, gerade bei der verteilten Entwicklung, seine Vorzüge hat. Das ist aber nicht der Kontext, in dem das Gros der potenziellen User arbeitet, das sich entscheiden kann (und nicht vom Arbeitgeber GWT vorgesetzt bekommt).

sma hat geschrieben:Will ich ein mächtiges Desktop-artiges UI (und stört mich die Lizenz nicht) kann ich Ext direkt benutzen und habe auch noch ca. 30.000 andere Leute in der "Community". Bei GXT wären es zumindest noch ein paar Tausend andere. Bei Pyjamas sind es gefühlt nur ein paar Hundert - maximal.

Mal eine Frage: würdest Du in einem großen Konzern lieber einer der 30000 armen Sklaven sein, oder einer von den 100 Managern?

Wir reden jetzt mal nicht von so bescheidenen Musterunternehmen wie der Bahn oder DB.

LG,
Michael

Michael Schneider · Montag 1. November 2010, 19:57

BlackJack hat geschrieben:@Michael Schneider: Hast Du denn an der Stelle überhaupt Unicode? Ich glaube Du bringst da gerade Unicode und UTF-8 durcheinander. `shlex` will Bytes.

Nein, bringe ich nicht. Sonst würde ich nicht zwischen Unicode und einem 7/8-Bit kodierten Zeichensatz unterscheiden. Mir war aber nicht klar, als was Python die Daten zurückgibt. Aber wo Du es sagst, gehe ich mal davon aus, dass Tkinter.StringVar zumindest einen normalen String zurückgibt, auch wenn er in utf-8 oder latin-1 kodiert ist.