Das deutsche Python-Forum

Hallo zusammen,
nach langem "read-only" ist es soweit, mein erster post.

Da ich gerade am überlegen bin, ob ich ein Programm entwickel, mit dem man einen Verein managen kann tauchen ein paar Fragen auf.
(Das ganze geschieht auf Bestellung, deswegen brauche ich keine Hinweise, dass es schon genügend Mitgliederverwaltungen gibt.)

1. Es stellt sich mir die Frage, wie man so ein Programm am besten/einfachsten/schnellsten realisiert. Da ich von anderer Stelle her gute Erfahrungen mit Python in Verbindung mit Mod_Python, Postgresql und einem Apache Server gemacht habe, war meine erste Überlegung natürlich Python in eben dieser Konfiguration. Vor einem halben Jahr habe ich mich allerdings auch kurz mit Django beschäftigt, aber das Ganze dann irgendwie nicht weiterverfolgt.
Auch nachdem ich mir die verschiedenen Frameworks angeguckt habe, kommt es mir so vor, als ob das ganze fast ausschließlich eine Glaubensfrage ist welches Framework man wählt... (Django, Turbogears, CherryPy, etc.) Da von verschiedenen Arbeitsplätzen gearbeitet wird dachte ich an die Bedinung per Browser. Die Geschwindigkeit spielt übrigens keine große Rolle, da es sich um ein Intranet handelt und keine Verbindung zu Arbeitsplätzen ausserhalb der Büros besteht.
So sonderlich kompliziert ist eine Verwaltungssoftware in ihren elementaren Funktionen ja nicht. Es kommen in diesem Fall nur ein paar Besonderheiten hinzu. Was mich auch gleich zu meinem zweiten Punkt bringt.

2. In wie weit lässt sich Drag&Drop (Sei es nun das Ziehen eines Elements aus Liste a nach Liste b oder das Ziehen eines fotos [jpeg, etc.]) mit Python realisieren? Mit der Verbindung Django / Ajax doch sicherlich machbar, oder? gibt es alternativen?

3. Lassen sich zum Beispiel ein Magnetkartenlesegerät oder sonstige Identifikationsmöglichen irgendwie einbinden? Sei es nun an einem Client der nur per Browser das Programm bedient oder irgendwie an den Server angeschlossen? (Beispiel: Karte wird gelesen; es wird in der Datenbank geprüft ob derjenige reindarf; tür geht auf oder auch nicht; es wird in der Datenbank eingetragen, dass derjenige da ist)

Hoffentlich hab ich mich einigermaßen verständlich ausgedrückt. Falls nicht, ich bin jederzeit für Anregungen offen. Falls das ganze sich nicht mit Python realisieren lassen sollte, ärgerlich. Bis jetzt ist Python meine Traumsprache

Edit (Leonidas): Verschoben.

Hallo bake, willkommen im Forum,

bake hat geschrieben:1. Es stellt sich mir die Frage, wie man so ein Programm am besten/einfachsten/schnellsten realisiert. Da ich von anderer Stelle her gute Erfahrungen mit Python in Verbindung mit Mod_Python, Postgresql und einem Apache Server gemacht habe, war meine erste Überlegung natürlich Python in eben dieser Konfiguration. Vor einem halben Jahr habe ich mich allerdings auch kurz mit Django beschäftigt, aber das Ganze dann irgendwie nicht weiterverfolgt.

Von mod_python würde ich generell abraten, das ist gerne mal buggy und konzeptuell schlichtweg kaputt (Einen Python-Interpreter in jeden Apache-Prozess laden? Broken....). Zum Glück gibt es bessere Alternativen.

bake hat geschrieben:Auch nachdem ich mir die verschiedenen Frameworks angeguckt habe, kommt es mir so vor, als ob das ganze fast ausschließlich eine Glaubensfrage ist welches Framework man wählt... (Django, Turbogears, CherryPy, etc.)

Nein, eigentlich nicht. Jedes ist für etwas anderes besser oder schlechter geeignet (wobei ich so am zweifeln bin, ob TG überhaupt irgendwelche interessanten Vorteile gegenüber direktem Pylons hat).

bake hat geschrieben:2. In wie weit lässt sich Drag&Drop (Sei es nun das Ziehen eines Elements aus Liste a nach Liste b oder das Ziehen eines fotos [jpeg, etc.]) mit Python realisieren? Mit der Verbindung Django / Ajax doch sicherlich machbar, oder? gibt es alternativen?

Mit Python im Browser? Gar nicht, denn Python läuft nicht im Browser. Mit Django? Ebensowenig, denn Django läuft genausowenig im Browser. Mit Ajax? Auch nicht, denn mit HTTP geht ja auch kein Drag and Drop. Was du aber nutzen kannst und worin Drag and Drop im Browser implementiert wird, ist JavaScript. Du kannst dir eine Helfer-Library wie jQuery nehmen und damit so etwas wohl recht schnell zusammenbauen. Anleitungen im Internet gibt es zuhauf, das Problem ist nur die brauchbaren herauszusuchen.

bake hat geschrieben:3. Lassen sich zum Beispiel ein Magnetkartenlesegerät oder sonstige Identifikationsmöglichen irgendwie einbinden? Sei es nun an einem Client der nur per Browser das Programm bedient oder irgendwie an den Server angeschlossen? (Beispiel: Karte wird gelesen; es wird in der Datenbank geprüft ob derjenige reindarf; tür geht auf oder auch nicht; es wird in der Datenbank eingetragen, dass derjenige da ist)

Im Browser? Nein. Merke: ein Browser kann bis auf HTML darstellen so ziemlich überhauptnichts. Wenn du ein Client-Programm schreibst: schon eher. Du kannst natürlich das Lesegerät am Server montieren und den User zwingen es am Server anzustecken und über den Browser zu bedienen, aber das ist recht... lästig.

Von mod_python würde ich generell abraten, das ist gerne mal buggy und konzeptuell schlichtweg kaputt (Einen Python-Interpreter in jeden Apache-Prozess laden? Broken....). Zum Glück gibt es bessere Alternativen.

Gibt es mehrere Alternativen, die sich je nach Einsatzgebiet besser oder schlechter eignen, oder gibt es die Alternative, zu der man greifen sollte?
Könnte man, anhand der Informationen (Mitgliederverwaltung, Checkin/Checkout), schon eine Empfehlung abgeben, welche Alternative Sinnvoll ist?

Nein, eigentlich nicht. Jedes ist für etwas anderes besser oder schlechter geeignet (wobei ich so am zweifeln bin, ob TG überhaupt irgendwelche interessanten Vorteile gegenüber direktem Pylons hat).

Hier das selbe, lässt sich mit den vorhandenen Informationen eine Empfehlung aussprechen? So etwas wie ein Adminbereich wie unter Django oder ein CMS ist, soweit ich das jetzt sagen kann, nicht nötig.

Du kannst dir eine Helfer-Library wie jQuery nehmen und damit so etwas wohl recht schnell zusammenbauen. Anleitungen im Internet gibt es zuhauf, das Problem ist nur die brauchbaren herauszusuchen.

Wunderbar, werde mich mal danach umschauen.

Nein. Merke: ein Browser kann bis auf HTML darstellen so ziemlich überhaupt nichts. Wenn du ein Client-Programm schreibst: schon eher.

Das ein Browser fast nur HTML darstellt war mir klar, hab mich wohl etwas verquer ausgedrückt Wenn ich jetzt von meiner Idee das ganze im Browser umzusetzen Abstand nehme, und das ganze als Client mit GUI umsetze, habe ich dann immer noch die Unabhängigkeit was das Betriebssystem angeht? Dachte halt an ein Bedienung per Browser, weil ich damit schon Erfahrung gesammelt habe und eine andere Bedienung totales Neuland für mich wäre. Wie einfach/kompliziert lässt sich denn sowas im Vergleich zur Steuerung über den Browser realisieren? Wenn ich mich jetzt z.B. für wxPython (welches wie ich das verstanden habe, plattformunabhängig ist - also unter linux, windows und max funktioniert?) entscheiden sollte, ist der Zeitaufwand höher, wie sieht das mit der Stabilität aus?

Vielen Dank schon mal, dass du dir die Mühe gemacht hast auf meine Fragen zu antworten! Wenn man hier die Fragen richtig stellt wird einem ziemlich gut, schnell und kompetent geantwortet.

bake hat geschrieben:Dachte halt an ein Bedienung per Browser, weil ich damit schon Erfahrung gesammelt habe und eine andere Bedienung totales Neuland für mich wäre. Wie einfach/kompliziert lässt sich denn sowas im Vergleich zur Steuerung über den Browser realisieren? Wenn ich mich jetzt z.B. für wxPython (welches wie ich das verstanden habe, plattformunabhängig ist - also unter linux, windows und max funktioniert?) entscheiden sollte, ist der Zeitaufwand höher, wie sieht das mit der Stabilität aus?

Du reduzierst damit deine Abhängigkeiten (Apache, verschiedenste inkompatible Browser, JavaScript, ...), so daß der Zeitaufwand nach meiner Einschätzung auf jeden Fall geringer sein sollte.
Nachteil: Der User muß einen Client installieren (der sich am Besten automagisch aktualisiert).

bake hat geschrieben:

Von mod_python würde ich generell abraten, das ist gerne mal buggy und konzeptuell schlichtweg kaputt (Einen Python-Interpreter in jeden Apache-Prozess laden? Broken....). Zum Glück gibt es bessere Alternativen.

Gibt es mehrere Alternativen, die sich je nach Einsatzgebiet besser oder schlechter eignen, oder gibt es die Alternative, zu der man greifen sollte?
Könnte man, anhand der Informationen (Mitgliederverwaltung, Checkin/Checkout), schon eine Empfehlung abgeben, welche Alternative Sinnvoll ist?

Für die meisten Dinge gibt es sich nicht viel ob man nun FastCGI, SCGI oder mod_wsgi nutzt.

bake hat geschrieben:

Nein, eigentlich nicht. Jedes ist für etwas anderes besser oder schlechter geeignet (wobei ich so am zweifeln bin, ob TG überhaupt irgendwelche interessanten Vorteile gegenüber direktem Pylons hat).

Hier das selbe, lässt sich mit den vorhandenen Informationen eine Empfehlung aussprechen? So etwas wie ein Adminbereich wie unter Django oder ein CMS ist, soweit ich das jetzt sagen kann, nicht nötig.

Für simple CRUD-Sachen ist Django ziemlich ideal, wenn du aber hochwertigere Komponenten brauchst, dann Pylons. Oder wenn du Frameworks generell nicht magst, dann Werkzeug.

bake hat geschrieben:Wenn ich jetzt von meiner Idee das ganze im Browser umzusetzen Abstand nehme, und das ganze als Client mit GUI umsetze, habe ich dann immer noch die Unabhängigkeit was das Betriebssystem angeht? Dachte halt an ein Bedienung per Browser, weil ich damit schon Erfahrung gesammelt habe und eine andere Bedienung totales Neuland für mich wäre. Wie einfach/kompliziert lässt sich denn sowas im Vergleich zur Steuerung über den Browser realisieren? Wenn ich mich jetzt z.B. für wxPython (welches wie ich das verstanden habe, plattformunabhängig ist - also unter linux, windows und max funktioniert?) entscheiden sollte, ist der Zeitaufwand höher, wie sieht das mit der Stabilität aus?

Die meisten GUI-Toolkits für Python sind platformunabhängig und in den meisten Toolkits ist es einfacher GUIs zu machen als mittels HTML schlichtweg weil diese dazu da sind um GUIs anzuzeigen und HTML dazu da ist Dokumente anzuzeigen. Allerdings solltest du dich zum Thema Cardreader umsehen, denn ob diese platformunabhängig funktionieren...
Lediglich die Stabilität von wxPython ist etwas schwach. Von allen großen Toolkits für Python ist es das, was bei manchen Operationen schlicht crasht. Es scheint, dass es in den letzten Jahren aber etwas besser geworden ist.

mkallas hat geschrieben:Nachteil: Der User muß einen Client installieren (der sich am Besten automagisch aktualisiert).

Wenn ich mir das konkret überlege ist das aber noch nichteinmal ein Nachteil. Auf der anderen Seite müsste man ja einen Server mit allen benötigten Dingen (Apache o.a., Mod_Python o.a., ...) aufsetzen.
Wenn der User einen Client installiert bräuchte man ja nur einen Postgres Server, da alles andere ja auf der Clientseite geschieht, oder nicht?

Leonidas hat geschrieben:Für simple CRUD-Sachen ist Django ziemlich ideal, wenn du aber hochwertigere Komponenten brauchst, dann Pylons. Oder wenn du Frameworks generell nicht magst, dann Werkzeug.

Hm, das reine Verwalten der Daten geht natürlich nicht über CRUD hinnaus. Soetwas wie Zugangskontrolle erweitert retrieve ja auch nur um eine darauffolgende Aktion... Man könnte das ganze natürlich auf zwei "Programme" aufteilen. Einmal die Verwaltung per Browser und einmal die Zugangskontrolle per wxPython, oder sehe ich das falsch?

Leonidas hat geschrieben:Lediglich die Stabilität von wxPython ist etwas schwach. Von allen großen Toolkits für Python ist es das, was bei manchen Operationen schlicht crasht. Es scheint, dass es in den letzten Jahren aber etwas besser geworden ist.

Der Punkt Stabilität ist natürlich übel... Welche Ausmaße nimmt das denn an? Ich möchte am Ende natürlich vermeiden, dass das Programm bei jeder zweiten, fünften oder zehnten Aktion über den Jordan geht...[/quote]

bake hat geschrieben:Wenn der User einen Client installiert bräuchte man ja nur einen Postgres Server, da alles andere ja auf der Clientseite geschieht, oder nicht?

Naja, theoretisch. Praktisch fände ich es keine so tolle Idee, den Datenbankserver freizugeben, so dass Clients nach belieben SQL abschicken. Da würde ich eher noch einen RPC-Server oder ähnliches davorschalten, der eine Datenmanipulations-API bietet und sichergeht dass die Clients keinen Unfug anstellen.

bake hat geschrieben:Der Punkt Stabilität ist natürlich übel... Welche Ausmaße nimmt das denn an? Ich möchte am Ende natürlich vermeiden, dass das Programm bei jeder zweiten, fünften oder zehnten Aktion über den Jordan geht...

Ich habe es wie gesagt schon länger nicht mehr genutzt, aber damals hat es sich immer bei den selben Dingen (reproduzierbar) aufgehängt, also solange man diese meidet liefen die Programme recht rund. Und die Bugs wurden meist in den folgenden Releases behoben.

bake hat geschrieben:

mkallas hat geschrieben:Nachteil: Der User muß einen Client installieren (der sich am Besten automagisch aktualisiert).

Wenn ich mir das konkret überlege ist das aber noch nichteinmal ein Nachteil. Auf der anderen Seite müsste man ja einen Server mit allen benötigten Dingen (Apache o.a., Mod_Python o.a., ...) aufsetzen.
Wenn der User einen Client installiert bräuchte man ja nur einen Postgres Server, da alles andere ja auf der Clientseite geschieht, oder nicht?

Leonidas hat geschrieben:Lediglich die Stabilität von wxPython ist etwas schwach. Von allen großen Toolkits für Python ist es das, was bei manchen Operationen schlicht crasht. Es scheint, dass es in den letzten Jahren aber etwas besser geworden ist.

Der Punkt Stabilität ist natürlich übel... Welche Ausmaße nimmt das denn an? Ich möchte am Ende natürlich vermeiden, dass das Programm bei jeder zweiten, fünften oder zehnten Aktion über den Jordan geht...

Mir ist wxPython nie einfach so gecrasht, wenn der Code falsch ist kommt manchmal ein segfault der natuerlich schwerer zu finden ist als eine normale Python exception, aber sonst. Also es ist nicht so wie du das jetzt interpretiert hast.

Leonidas hat geschrieben:Naja, theoretisch. Praktisch fände ich es keine so tolle Idee, den Datenbankserver freizugeben, so dass Clients nach belieben SQL abschicken. Da würde ich eher noch einen RPC-Server oder ähnliches davorschalten, der eine Datenmanipulations-API bietet und sichergeht dass die Clients keinen Unfug anstellen.

RPC-Server kenne ich bisjetzt, leider nur dem Namen nach. Sicherheit ist natürlich wünschenswert. In wieweit bringt mir das denn eine höhere Sicherheit, wenn ich einen RPC-Server davor schalte? Von der Clientseite lassen sich, wenn man es richtig anstellt, doch nur vordefinierte Sql-Befehle verschicken.

Zum Thema RPC-Server: Wenn ich das richtig verstanden habe sind RPC und DB Server ein und derselbe? Und wenn ein RPC vorhanden ist schickt man einen Funktionsaufruf samt Parameter an den RPC der dann Intern eine Abfrage an die DB startet anstatt vom Client eine direkte Abfrage an die DB zu schicken?

name hat geschrieben:Mir ist wxPython nie einfach so gecrasht, wenn der Code falsch ist kommt manchmal ein segfault der natürlich schwerer zu finden ist als eine normale Python exception, aber sonst. Also es ist nicht so wie du das jetzt interpretiert hast.

Das beruhigt mich ein wenig, falscher Code lässt sich ja durch präzises und sorgfältiges Arbeiten minimieren... Ich habe Leonidas Post so interpretiert, als ob wxpython ohne plausiblen Grund (Wie z.B. falscher Code) crashen würde.

bake hat geschrieben:RPC-Server kenne ich bisjetzt, leider nur dem Namen nach. Sicherheit ist natürlich wünschenswert. In wieweit bringt mir das denn eine höhere Sicherheit, wenn ich einen RPC-Server davor schalte? Von der Clientseite lassen sich, wenn man es richtig anstellt, doch nur vordefinierte Sql-Befehle verschicken.

Wer sagt, dass von Clientseite nur vordefinierte Befehle möglich sind? Wenn der User das Passwort kennt kann er sich am Datenbankserver remote einloggen und dort beliebiges absetzen (vorrausgesetzt du hast nicht noch irgendwelche Beschränkungen auf der Datenbankebene eingestellt, aber auch dann kann man zumindest die Integrität der Daten kaputtmachen).

bake hat geschrieben:Zum Thema RPC-Server: Wenn ich das richtig verstanden habe sind RPC und DB Server ein und derselbe? Und wenn ein RPC vorhanden ist schickt man einen Funktionsaufruf samt Parameter an den RPC der dann Intern eine Abfrage an die DB startet anstatt vom Client eine direkte Abfrage an die DB zu schicken?

Richtig.

bake hat geschrieben:

name hat geschrieben:Mir ist wxPython nie einfach so gecrasht, wenn der Code falsch ist kommt manchmal ein segfault der natürlich schwerer zu finden ist als eine normale Python exception, aber sonst. Also es ist nicht so wie du das jetzt interpretiert hast.

Das beruhigt mich ein wenig, falscher Code lässt sich ja durch präzises und sorgfältiges Arbeiten minimieren... Ich habe Leonidas Post so interpretiert, als ob wxpython ohne plausiblen Grund (Wie z.B. falscher Code) crashen würde.

Mir ist es mal gecrasht als ich versucht habe eine Toolbar zu verstecken, was sollte an der Idee "falsch" sein? Er crasht nicht oft, aber es crasht bei richtigem ebenso wie "falschem" Code, je nachdem wo der Bug ist.

@bake: Wie stellt man es richtig an, dass von Clientseite nur "vordefinierte" SQL-Anfragen geschickt werden können? Es geht jetzt nicht nur um Dein Client-Programm, sondern das man ja auch anders an die DB kommt, wenn die im Netz zugänglich ist.

Zu wxPython: Es ist wohl schon so gemeint, das auch richtiger Quelltext crashen kann. D.h. eigentlich gültige Konstruktionen die nicht so funktionieren wie sie sollten. Aber es kracht halt deterministisch.

Wobei wxWidgets/wxPython ein soweit ich weiss ein aktives Projekt ist, da kann man also Bugreports schicken und berechtigte Hoffnung haben, das Fehler in Folgeversionen behoben werden.

BlackJack hat geschrieben:Zu wxPython: Es ist wohl schon so gemeint, das auch richtiger Quelltext crashen kann. D.h. eigentlich gültige Konstruktionen die nicht so funktionieren wie sie sollten. Aber es kracht halt deterministisch.

Ah ok, aber immerhin deterministisch... ich lass mich einfach mal überraschen.

Leonidas hat geschrieben:Wer sagt, dass von Clientseite nur vordefinierte Befehle möglich sind?

Ich habe leider das Fragezeichen vergessen... Klar, wenn man das Passwort kennt kann man sich natürlich einloggen... Daran habe ich garnicht gedacht, bin halt nur von der Bedienung durch einen Client ausgegangen. In punkto Sicherheit sollte man mich also anscheinend zur Zeit nicht konsultieren

Vielen Dank soweit für die Hilfe! Echt gut zu wissen, dass man hier (im Notfall) kompetente Hilfe findet!

Unter der Annahme, dass so ein Verein von nur ein ganz paar Leuten organisiert wird und auch nicht all zu viele Leute auf die Daten lesend zugreifen, rate ich zu einer einfachen webbasierten CRUD-Anwendung.

Für diese ist Django sehr gut geeignet.

Für den Server würde ich eine reine Python-Lösung mit CherryPy empfehlen, damit man sich nicht mit der Installation von Webserver, mod-irgendwas, FCGI, usw. auseinandersetzen muss. Das scheint aber für dich kein Problem zu sein, also benutze deine Wunschkombination einfach.

Die Webanwendung lässt sich (dies ist unabhängig von Python und Django) so interaktiv gestalten, wie man es in JavaScript (Stichwort AJAX) eben schafft. Django unterstützt einen hier (im Gegensatz zu z.B. Rails für Ruby) nicht, stellt sich aber auch nicht in den Weg. Gerade für tabellarische Daten würde ich eine Bibliothek wie YUI oder ExtJS (kommerziell) empfehlen. Ein Freund von mir schwört auf SproutCore (zusammen mit Rails) welches Backend-neutral ist und daher auch mit Django zusammenarbeiten müsste - der MVC-Ansatz ist jedenfalls interessant und kombiniert die Vorteile einer traditionellen Desktop-Anwendung, was die Entwicklung angeht mit denen einer Webanwendung, was die Installation angeht.

Bei dem Magnetkartenleser wirst du jedoch nicht ohne eine zu installierende Anwendung auskommen. Diese kann dann natürlich ebenfalls mit einer Django-Anwendung auf dem Server per HTTP sprechen. Das ist IMHO der bessere Ansatz, als eine Datenbank über das Netz zugänglich zu machen.

Stefan

sma hat geschrieben:Ein Freund von mir schwört auf SproutCore (zusammen mit Rails) welches Backend-neutral ist und daher auch mit Django zusammenarbeiten müsste - der MVC-Ansatz ist jedenfalls interessant und kombiniert die Vorteile einer traditionellen Desktop-Anwendung, was die Entwicklung angeht mit denen einer Webanwendung, was die Installation angeht.

SproutCore scheint mir interessant zu sein, wenn man so etwas wie Desktopanwendungen im Browser machen will. Eine Interessante alternative dazu könnte auch Cappuccino und Objective-J sein (siehe 280slides). Persönlich finde ich so Sachen ziemlich sinnlos, der Geek-Faktor ist da durchaus vorhanden.

Cappuccino gibt es seit gestern und ich lese da gerade ;) Zuvor hatte ich nur in den Sourcecode von 280slides gespickt und gesehen, wie sie JavaScript um ein Klassenmodell a la Objective-C oder eben Smalltalk erweitert hatten. Definitiv ein hoher Geek-Faktor :)

Warum aber hältst du "so Sachen" für sinnlos? Anspruchsvolle UIs in JavaScript zu schreiben, ist doch big-PIA, da finde ich jeden Ansatz, der hier verspricht, Abhilfe zu schaffen, interessant. Insbesondere als Alternative zu GWT, welches mit einer bekannten statischen Programmiersprache zwar den Einsatz ebenso bekannter Werkzeuge erlaubt, aber irgendwie - statisch - ist.

Stefan

sma hat geschrieben:Warum aber hältst du "so Sachen" für sinnlos? Anspruchsvolle UIs in JavaScript zu schreiben, ist doch big-PIA, da finde ich jeden Ansatz, der hier verspricht, Abhilfe zu schaffen, interessant.

Im Vergleich zu "normalen" Toolkits ist das immer noch ätzend, funktionsarm und auch langsam (schnellere JS-VMs helfen da wohl schon etwas, aber man muss auch die HTTP-Requests etc mit einrechnen). Letztendlich ist HTML eben ein Dokumentenformat wie PDF und es zu einem GUI-Toolkit umzubauen engt einen hier und dort ein.

PDF-Dateien können auch Formulare und JavaScript (ja sogar Flash) enthalten, aber das wolltest du jetzt nicht hören, denke ich mal. Ja, HTML + JavaScript wird zu einem UI-Toolkit umgebaut. Aber das ist eben der Lauf der Zeit und wenn es schon passiert, dann bitte so, dass ich als Entwickler damit möglichst wenig Probleme habe. Der Browser wird auf die eine oder andere Weise immer mehr Desktop-Anwendungen ablösen und so selbst zum Desktop - dem Webtop - werden.

Abgesehen davon: Wenn Cappuccino es wirklich schafft, NextStep aka Cocoa in's Web zu übertragen - dann haben wir damit nicht nur ein UI-Toolkit sondern ein Anwendungsrahmenwerk, welches seines gleichen sucht und IMHO einfachen UI-Toolkits wie wx, tk oder auch Swing und SWT überlegen ist. Qt ist da dann eher vergleichbar aufgestellt - aber eben nicht für's Web.

Stefan

sma hat geschrieben:PDF-Dateien können auch Formulare und JavaScript (ja sogar Flash) enthalten, aber das wolltest du jetzt nicht hören, denke ich mal.

Das ist mir bekannt. Aber Formulare gehen so wie die HTML-Formulare noch unter "Dokument" und JS + Flash sieht man so gut wie gar nicht. Ich weiß nicht ob außerdem Reader noch irgend ein anderer Viewer das unterstützt. Ich halte es auch für keine gute Idee.

sma hat geschrieben:Abgesehen davon: Wenn Cappuccino es wirklich schafft, NextStep aka Cocoa in's Web zu übertragen - dann haben wir damit nicht nur ein UI-Toolkit sondern ein Anwendungsrahmenwerk, welches seines gleichen sucht und IMHO einfachen UI-Toolkits wie wx, tk oder auch Swing und SWT überlegen ist. Qt ist da dann eher vergleichbar aufgestellt - aber eben nicht für's Web.

Momantan sind aber nur zwei Teile portiert: Foundation und AppKit. Und vor allem Hardwarezugriff wird es nie haben, was es auf ewig von Browsern abhängig macht. Wenn man dann sieht wie langsam und verbuggt einige sind, dann hat man da gleich keine Lust mehr, wenn dann den meisten die eigene Applikation um die Ohren fliegt.

Ich habe hier einen kleinen Vergleich zwischen Cappuccino und jQuery, da hat jemand das Demo portiert.

• Flickr Photo Demo in Cappuccino
• Flickr Photo Demo in jQuery
• Flickr Photo Demo in SproutCore

Es ist auch nicht alles so unproblematisch, so ist bei mir die Cappuccino-Version wesenlich langsamer, während man bei der jQuery-Version nicht alle Listen entfernen kann und sie etwas weniger als Cappuccino macht (via).

Edit: SproutCore-Version hinzugefügt

Die SproutCore-Demo ist IMHO am Überzeugendsten, weil sie Databinding zeigt. Es geht ja nicht bei den Rahmenwerken darum, den Effekt nachzustellen, sondern wie und mit welchem Aufwand diese "Anwendung" gebaut werden konnte. Das lässt sich an den Demos ohne Quelltext nicht nachvollziehen.

Cappuccino sagt, nutze Objective-J, denn dann hast du zusammen mit unserem Cocoa-kompatiben Rahmenwerk ein mächtiges Werkzeug an der Hand, die Anwendung zu haben - insbesondere wenn du Cocoa schon kennst. Gerüchtehalber soll man sogar den Apple InterfaceBuilder nutzen können, um die Oberflächen zu bauen.

SproutCore sagt, wir benutzen die selben Konzepte wie Cocoa, aber portiert auf JavaScript und mit MVC und Databinding (moderne) Konzepte für die GUI-Entwicklung.

JQuery sagt: Wir sind klein und fein und es kostet nicht viel, die Bibliothek auf Webseiten einzubinden. Bei der Entwicklung von Anwendungen hilft das aber IMHO nicht viel.

Stefan