ubuntuusers.de

Hallo,

mein aktuelles Perlprojekt ist ein Zeitmanagement-Tool, das natürlich eine grafische Oberfläche haben sollte, damit ich es eines Tages anderen herzeigen und zum Testen geben kann (selbst hätte ich kein Problem, fürs Terminal zu schreiben). Problem dabei ist, dass ich nicht viel Lust habe, mich mit GUI-Programmierung tiefgehend zu befassen. Schon Toolkits wie WxWidgets/WxPerl haben für mich etwas abstoßendes. Und da denk ich mir, habe ja Ahnung von HTML, CSS und Javascript, warum nicht den Browser verwenden? Aber dazu brauche ich einen Webserver. Wobei mir vielleicht auch ein Miniwebserver reicht, sowas wie HTTP::Server::Simple oder Mojolicious::Lite? Sehr wichtig ist mir, dass man den Server an localhost binden kann, so dass er nicht auf Anfragen von außen reagiert, ja nicht mal sichtbar ist.

Gibt es bei diesem Ansatz irgendwelche Probleme, die ich außer Acht lasse? Gibt es andere ebenso einfache und portable Möglichkeiten gutaussehende GUIs umzusetzen, ohne dass man zu einem Dutzend-KByte-Progrämmchen Megabytes an Abhängigkeiten installieren muss?

Ich find es ist Zeit, dass man in die Adresszeile des Browsers sowas eingeben kann wie program://time-man:6617/list-most-urgent?tasks=10 (Programmname:PID), soviel anders als http://localhost:12345/... ist das ja auch nicht, es würde halt der Programmname stets drinstehen. (Also nur falls jemand das liest, der Lust hat sowas umzusetzen, meine Ambitionen gehören besagtem Zeitmanager.)

Viele Grüße
FLoH.tar

Wie Du schon richtig erkannt hast, bekommst Du bei einem Webansatz immer eine Netzwerkkomponente in Dein Programm - das ist in gewisser Hinsicht immer eine potenzielle Gefahr und zudem mit einem Haufen Abhängigkeiten verbunden. Qt und Gtk haben die meisten (Linux-)Benutzer eh schon installiert; da tun die Bindings - sofern die noch fehlen - nicht mehr wirklich weh. Das Programm an sich bleibt dann schön schlank und kann auf Serverprozesse verzichten.

Wenn Du alleine mit JavaScript arbeitest, könntest Du auch HTML als UI nutzen, ohne eine Webserverkomponente in Dein Programm-Stack zu integrieren. Allerdings musst Du dann noch das IO-Problem lösen 😉

Der üblichere Weg wäre für mich: file:///home/track/test.html im Browser (genau das trägt er dort ein, wenn Du auf eine lokale HTML-Datei klickst !), und dann die Logik innerhalb der HTML-Datei ausführen. Dieser Weg über eine HTML-Oberfläche ist ja auch in der Industrie üblich, wo Portabilität gefragt ist ...

Praktisch hieße das, dass die Logik dann hinter den Links liegen muss, klar. (und an der Stelle sind meine Vorkenntnisse auch schon fast zu Ende)

Ist man hier tatsächlich auf eine "Serverkomponente" angewiesen, oder kann man da nicht auch andere Skripte starten ?

track

track schrieb:

Ist man hier tatsächlich auf eine "Serverkomponente" angewiesen, oder kann man da nicht auch andere Skripte starten ?

Klar, Du kannst das im Browser mit JavaScript erledigen. Dann muss die JavaScript-Engine allerdings Zugriff auf das lokale Dateisystem bekommen. Wie das geregelt wird, weiß ich nicht. Normalerweise laufen die ja in einer Sandbox, damit sie keinen Schaden anrichten können.

Ciao

robert

Lysander schrieb:

Qt und Gtk haben die meisten (Linux-)Benutzer eh schon installiert; da tun die Bindings - sofern die noch fehlen - nicht mehr wirklich weh.

Naja, bei diesem zugegeben naheliegenden Ansatz sehe ich mehrere Probleme:

• Linuxnutzer haben, so vermute ich, meist nur eines der beiden installiert, da sie etwa bei Unity bleiben, wie meine engsten Arbeitskollegen, die ich als freiwillige Tester als erste ins Auge fasse. Wenn ich Glück habe, testet vielleicht einer oder zwei von denen das Tool. Früher oder später muss ich mit meinem Programm ja doch an die Öffentlichkeit (Linux-Community), und da ist es sicherlich ein Hindernis, wenn man erst die jeweils andere Desktopumgebung oder zumindest einen Teil davon installieren muss.

• Qt gäbe es allerdings auch für Windows, Gtk mittlerweile auch, unabhängig davon sehe ich aber große Probleme auf mich zukommen. Okay, dafür lerne ich Qt/Gtk, das ist auch nicht zu unterschätzen, aber bis ich dann überhaupt an das eingemachte, an die Programmlogik des Zeitmanagers gehen kann, hab ich mein eigentliches Ziel womöglich aus dem Auge verloren.

• Wenn ich gleich den Netzwerkansatz verfolge, könnte man es theoretisch leichter zu einem Webservice ausbauen. Da Zeitplanung allerdings in puncto Datenschutz sensibel zu behandeln ist, steht dieses Argument auf tönernen Füßen.

Wenn Du alleine mit JavaScript arbeitest, könntest Du auch HTML als UI nutzen, ohne eine Webserverkomponente in Dein Programm-Stack zu integrieren. Allerdings musst Du dann noch das IO-Problem lösen 😉

Das ist wie gesagt ein Perlprojekt. Perl ist nun mal meine Leib-und-Magen-Programmiersprache, ich beherrsche sie meiner Ansicht nach gut bis sehr gut. Habe bereits überlegt, ob ich das mit Node.js aufziehe und meine Javascriptkenntnisse ausbaue, für Bedienungskomfort von Webseiten mögen sie taugen, nicht jedoch datenbankgebundene Programmlogik etc. Doch ist auch das ein höherer Zeit&Lernaufwand als bei dem zu bleiben, was ich bereits kann. Letztendlich eine philosophische Frage: Ob man sich selbst der Situation anpasst oder versucht, die Situation der eigenen Kompetenz anzupassen. Trainiert man die Arme* oder erfindet man Flugzeuge?

Seufz, ich sehe schon, ich bin mit meiner Programmiersprachenwahl an das Terminal gebunden.

[EDIT, *) ein Hinweis für Kinder, bitte lesen, bevor ihr aufs Fensterbrett steigt: Arme trainieren ist immer gut. Sobald ihr ausgewachsene Bäume eigenhändig ausreißen könnt, erst dann, könnt ihr mit dem Fliegenlernen anfangen. Falls ihr denn noch lebt und die Muskulatur nicht die lebenswichtigen Organe zerquetscht hat 😉 ]

Ich sehe das Problem nicht so recht. Es ist ja kein besonders großer Akt, ein Perl Programm zu zu erweitern, dass es auf einen Port horcht und dort HTTP-Anfragen bedient. Auch HTML dynamisch zu generieren ist kein großes Problem für Perl. Du bekommst dadurch keine zusätzlichen Abhängigkeiten, bist Plattform-Neutral und Netzwerk-Transparenz bekommste auch noch geschenkt.

Besonders viel auf der Javascript-Seite muss da auch nicht passieren; das hängt davon ab, wie dynamisch das Ganze sein soll. Aber im „schlimmsten” Fall, setzt du einfach ein paar Ajax-Requests ab und die Perl-Seite macht das ganze Drum-Herum.

Ich würde meinen, wenn man erfahren in Perl ist, hält sich der Aufwand sehr in Grenzen.

Ja, diese Gedanken mache ich mir auch und lese gerade die Doku zu Mojolicious, das weit einfacher, zumindest weniger Boilerplate-Code zu erfordern scheint als HTTP::Server::Simple (ohnehin Version <1). Und wenn der Server nur auf 127.0.0.1 (localhost) lauscht, sollte die Sache doch auch sicherheitstechnisch nicht zu bemängeln sein, oder?

FLoH.tar schrieb:

Ja, diese Gedanken mache ich mir auch und lese gerade die Doku zu Mojolicious, das weit einfacher, zumindest weniger Boilerplate-Code zu erfordern scheint als HTTP::Server::Simple (ohnehin Version <1). Und wenn der Server nur auf 127.0.0.1 (localhost) lauscht, sollte die Sache doch auch sicherheitstechnisch nicht zu bemängeln sein, oder?

Kenne leider weder HTTP::Server::Simple noch Mojolicious, kann das also nicht so qualitativ vergleichen. Aber ob sich so ne umfangreiche Bibliothek wieMojolicious lohnt, hängt von dem Umfang der GUI ab. Spontan würde ich sagen, um ein paar Informationen dazustellen und aufzuhübschen reicht ein simples HTTP-Modul, das CGI-Modul und etwas CSS. Natürlich: Wenn die GUI komplexer wird, lohnt sich eher ein komplettes Web-Framework.

Wenn du das an Localhost bindest ist das natürlich relativ sicher. Hängt davon ab, ob das ein Single-User oder Multi-User-System ist. Ansonsten ist so ein Authentifizierungs-Mechanismus auch sehr schnell realisiert. Wenn du SSL etwa benutzt, kannst du SSL-Authentifizierung benutzen und musst dein Programm gar nicht anpassen.

Die Frage ist halt auch, wie komplex die Interaktion zwischen GUI und Programm ist. Traditionell gibts halt ein paar Buttons die man klickt und hinter denen sich ein Link verbirgt. Dynamische GUIs senden spezifische Ajax-Requests und bauen die Antworten in die aktuelle Seite ein. Wenn du sowas supporten willst, wirst du vermutlich auch eine JSON-Bibliothek für dein Perl-Programm und sowas wie Jquery für die HTML-GUI brauchen (geht auch ohne, wird aber nervig).

Ich probiere es mit Mojolicious, die Doku ist sehr vielversprechend. Danke! ☺

FLoH.tar schrieb:

• Linuxnutzer haben, so vermute ich, meist nur eines der beiden installiert, ...

Wirkliche User interessiert es nicht, welche Libs auf ihrem System installiert sind 😉 Qt und Gtk sind die beiden großen Platzhirsche; ehrlich gesagt denke ich eher, dass es da mehr Systeme gibt, wo beide vorhanden sind - aber meine Einschätzung mag auch falsch sein, sofern die geifernden Lib-Nazis nicht nur eine Forenerscheinung sind, sondern tatsächlich die Mehrheit der User widerspiegeln.

• Qt gäbe es allerdings auch für Windows, Gtk mittlerweile auch, unabhängig davon sehe ich aber große Probleme auf mich zukommen. Okay, dafür lerne ich Qt/Gtk, das ist auch nicht zu unterschätzen,

Ja sicher; der Lernaufwand ist bestimmt recht groß - da kommt es wirklich darauf an, wie motiviert Du da wärst.

aber bis ich dann überhaupt an das eingemachte, an die Programmlogik des Zeitmanagers gehen kann, hab ich mein eigentliches Ziel womöglich aus dem Auge verloren.

Das kapiere ich nicht! Du fängst doch eh mit der Logik an!? Klar kann man sich auch mal einen GUI-Prototypen zusammenbauen - aber für ein Mockup reicht doch auch erst einmal ein vom einem GUI-Designer zusammen geklicktes UI ohne Funktionalität. Da musst Du zu Beginn doch noch gar keine Ahnung von GUI-Programmierung haben... der Aufsatz kann doch am Schluss erfolgen.

• Wenn ich gleich den Netzwerkansatz verfolge, könnte man es theoretisch leichter zu einem Webservice ausbauen. Da Zeitplanung allerdings in puncto Datenschutz sensibel zu behandeln ist, steht dieses Argument auf tönernen Füßen.

Hm... ich denke, es kommt hier klar auf Deinen Anwendungsfall und die unterstützten Workflows an! Man kann auch später leicht einen Webservice aus dem ganzen machen - wichtig ist doch erst einmal die Trennung zwischen Logik und Präsentationsschicht. Wenn Du das sauber umsetzt, dann kannst Du das in eine traditionelle Desktop-UI einbinden oder als Webapp hinter einem HTTP-Layer laufen lassen.

Das ist wie gesagt ein Perlprojekt. Perl ist nun mal meine Leib-und-Magen-Programmiersprache, ich beherrsche sie meiner Ansicht nach gut bis sehr gut.

Ok, ich hatte JS auch nur vorgeschlagen, da Du damit ggf. wirklich ohne Server-Komponente hättest auskommen können - wobei ich lokal auch nicht sicher wäre, wie man die IO-Sperre ausschalten kann. Ich würde da def. auf Perl setzen und damit die Sprache nutzen, die Du kannst - das bringt Dir mehr Vorteile, als dass die "Nachteile" überwiegen.

Kinch schrieb:

Kenne leider weder HTTP::Server::Simple noch Mojolicious, kann das also nicht so qualitativ vergleichen. Aber ob sich so ne umfangreiche Bibliothek wieMojolicious lohnt, hängt von dem Umfang der GUI ab. Spontan würde ich sagen, um ein paar Informationen dazustellen und aufzuhübschen reicht ein simples HTTP-Modul, das CGI-Modul und etwas CSS. Natürlich: Wenn die GUI komplexer wird, lohnt sich eher ein komplettes Web-Framework.

Also da würde ich aber widersprechen! Gerade bei Webapps und dazu ggf. als Anfänger in Sachen Webtechnologien, sollte man tunlichst auf ein Fullstack-Webframework setzen! Das hat in Punkto Sicherheit bereits an alles gedacht und bietet entsprechende Schutzmechanismen; dazu sind die einzelnen Komponenten (Template-Engine, DB-Backend, Authentication, Formular-Validation, usw.) bereits sinnvoll aufeinander abgestimmt. Natürlich kann ich alles per simpler CGI-Kommunitkation und selbst zusammen geklöppelten HTML-Seiten lösen - auf der sicheren Seite bin ich damit nicht! Und da das Programm offenkundig einst veröffentlicht werden soll, so sollte man auch hier auf Qualität beim Code setzen; früher oder später zieht dann nämlich das Argument vom ausschließlichem "localhost"-Einsatz nicht mehr. Zudem sprechen für ein Fullstack-Framework die Dokumentation und die Community!

Ich kenne mich in der Perl-Welt nicht aus, aber Deine Wahl erscheint schon recht gut. Eine populäre Alternative scheint sonst noch Catalyst zu sein.

Ich würde da erst einmal ein wenig recherchieren, wo die Vor- Nachteile von beiden liegen, oder was der aktuelle Trend in der Perl-Community ist.

Zudem verzettele Dich nicht zu "früh" mit dem Webframework - schreibe doch erst einmal so weit wie möglich Deine eigentliche Applikation; Du sagtest ja selber, dass Du es selber als reines CLI umsetzen würdest. Dann mache das doch erst einmal; damit kannst Du die Logik erst einmal durch testen, genauso wie Workflows und Szenarien. Zudem erreichst Du eine saubere Trennung Deiner Logikschicht und der später darauf aufsetzenden Webschicht ☺

Stimmt, eigentlich selbstverständlich diese Vorgehensweise, manchmal sieht man den Wald vor lauter Bäumen nicht – vielen Dank für deinen Beitrag, Lysander. Ich habe da einige Klassenkandidaten ausgemacht, die die innere Logik bewerkstelligen und die daher unabhängig von der Benutzerschnittstelle sind. Ich fange also mit diesen Modulen an, als "Benutzerschnittstelle" reicht wohl erst mal eine stupid-statisch ablaufende Testroutine, die verschiedene Ereignisse durchspielt.

Ich bin allerdings der Meinung, dass man die Benutzerschnittstellenbasis, zumindest mögliche Kandidaten, schon zu Beginn festlegen und in schon in der frühen Entwicklung im Blick behalten (aber sich auch nicht allzu sehr darauf verlassen) sollte. Sonst hat man gegen Ende das Problem, dass Myriaden von Codezeilen nötig sind, um die Präsentations- und Logikschicht zu verheiraten.

Lysander schrieb:

Also da würde ich aber widersprechen! Gerade bei Webapps und dazu ggf. als Anfänger in Sachen Webtechnologien, sollte man tunlichst auf ein Fullstack-Webframework setzen!

Tja, da werden wir uns wohl nicht einig. Wenn man HTML zur einfachen Interaktion und Visualisierung verwendet, finde ich so ein Webframework einfach sinnlos. Datenbank-Anbindung, Formular-Validation, etc pp ist ja alles Zeug, was man in so einem Setting explizit nicht braucht. Dann hat man am Ende so ein riesiges Teil als Abhängigkeit, dass auch noch gewartet und auf den Zielmachinen installiert werden will, um ein bisschen HTML zu rendern.

Kinch schrieb:

Tja, da werden wir uns wohl nicht einig.

In der Tat 😬

Wenn man HTML zur einfachen Interaktion und Visualisierung verwendet, finde ich so ein Webframework einfach sinnlos. Datenbank-Anbindung, Formular-Validation, etc pp ist ja alles Zeug, was man in so einem Setting explizit nicht braucht.

Woher weißt Du das? Und selbst wenn man eine Komponente nicht braucht, kann man dennoch die anderen nutzen. Klar, Qt ist da wesentlich variabler als ein Django; aber solange es ein Major-Projekt ist, wird das 3rd Party-Modul vermutlich länger bestehen als das eigene... 😉

Es gibt ja auch Frameworks, bei denen man gezielt Komponenten aussuchen kann und die nur grundlegende Mechanismen bieten, wie das Routing und ggf. eine simple Templatenegine. Aber die sind für Anfänger eher nicht geeignet, da man sich dafür in den Technologien *sehr gut* auskennen muss, um sinnvolle Architekturentscheidungen treffen zu können.

Zudem vergisst Du den Aspekt des "Wachsens"; man hat es bei einer do-it-yourself Lösung später sicherlich größere Probleme, Dinge hinzuzufügen. (Vielleicht soll es dann irgend wann doch mal ein Formular sein, vielleicht kommt doch noch ein DB-Backend hinzu?)

Und last but not least: Man sammelt ja auch durch Frameworkbenutzung Erfahrung; zum einen für das Framework speziell, wodurch man später immer schneller wird und den Tradeoff zur "schnellen" Lösung ohne Einarbeitung schnell erreicht, zum anderen stärkt es die allgemeine Fähigkeit, mit komplexen Frameworks zu arbeiten.

FLoH.tar schrieb:

Ich bin allerdings der Meinung, dass man die Benutzerschnittstellenbasis, zumindest mögliche Kandidaten, schon zu Beginn festlegen und in schon in der frühen Entwicklung im Blick behalten sollte. Sonst hat man gegen Ende das Problem, dass Myriaden von Codezeilen nötig sind, um die Präsentations- und Logikschicht zu verheiraten.

Ja, verkehrt ist es sicher nicht. Ich wollte Dir ja auch nur vermitteln, dass der Kern komplett unabhängig von einem Framework erarbeitet werden kann. Stellen, an denen Du Logik in Framework spezifischen Code auslagern musst, zeugt dann eher von schlechtem Design Deiner API 😉 Insofern sollte man an solchen Stellen wirklich nachdenken, ob man da nicht einen Fehler gemacht hat... und manche Dinge zählen dann einfach schlicht nicht mehr zur Logik, wenn man da Framework-Funktionen im Code braucht.