Vorteile von Nicht-Web-Applikationen?
-
Artchi schrieb:
general bacardi schrieb:
Artchi schrieb:
Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
Das wird ja immer Verrückter. Was bist DU denn für ein seltsamer troll
Danke für die Bestätigung der hirnrissigen Logic von byto.
Ich habe einfach nur die Begriffe ausgetauscht, um mal zu zeigen was wieder abgeht.Geht es in diesem Thread um Web-Apps oder um C++? Eben!
Kommt darauf an ob du die Allgemeinheit fragst, oder fricky
-
Back to topic: Web-Apps vs. Client-Apps. ganz ohne C++ und Flames
Mir sind in letzter Zeit mehrere Applikationen über den Weg gelaufen die den Zwischenweg gehen bzw. beides möglich machen: Ein sauberer geschichteter Aufbau, bei dem mehrere Transportschichten eingebaut sind. Diese können je nach Bedarf ausgetauscht werden. Entweder als lokale "Durchreiche", wo die beiden angrenzenden Schichten direkt zusammengelinkt werden, oder als Webservice, per http als Java-Thin-Client, ganz wie mans braucht. So kann ein und dasselbe Programm als Monolith auf einem einzelnen Rechner laufen oder mit einem Thin Client als Webapp gestartet werden, während die Dialogsteuerung, Fachlogik und ggf. Persistenzschichten auf ein oder mehreren Servern liegen, oder eben als fat client wo Dialogsteuerung und eventuell auch Fachlogik mit auf Clientseite sind.
Ich denke, dass die Möglichkeiten mannigfaltig sind und die Entscheidung, wie flexibel das System sein soll sich ausschließlich am Einsatzgebiet orientieren sollte.
-
pumuckl schrieb:
Mir sind in letzter Zeit mehrere Applikationen über den Weg gelaufen die den Zwischenweg gehen bzw. beides möglich machen: Ein sauberer geschichteter Aufbau, bei dem mehrere Transportschichten eingebaut sind. Diese können je nach Bedarf ausgetauscht werden. Entweder als lokale "Durchreiche", wo die beiden angrenzenden Schichten direkt zusammengelinkt werden, oder als Webservice, per http als Java-Thin-Client, ganz wie mans braucht. So kann ein und dasselbe Programm als Monolith auf einem einzelnen Rechner laufen oder mit einem Thin Client als Webapp gestartet werden, während die Dialogsteuerung, Fachlogik und ggf. Persistenzschichten auf ein oder mehreren Servern liegen, oder eben als fat client wo Dialogsteuerung und eventuell auch Fachlogik mit auf Clientseite sind.
Ich denke, dass die Möglichkeiten mannigfaltig sind und die Entscheidung, wie flexibel das System sein soll sich ausschließlich am Einsatzgebiet orientieren sollte.Das stimmt. Man sollte größere Anwendungen vielleicht immer so schreiben, daß einezelen Komponenten über Schnittstellen kommunizierem, die lokal als auch über Netze möglich sind. Das X-Window System ist ein bekanntes Beispiel für diese Strategie
-
Artchi schrieb:
byto schrieb:
Fakt ist, dass C++ im Webbereich eher eine untergeordnete Rolle spielt. Ergo arbeiten wahrscheinlich die wenigsten C++ Entwickler in Webprojekten. Und dass man eher dem aufgeschlossen ist, was man täglich erlebt, ist ja nicht verwunderlich.
Ehm, wie jetzt? Also C++-Progger benutzen/erleben keine Web-Apps?
Sorry, aber das ist blödsinn! Ich denke schon, das C++-Progger auch täglich Web-Apps nutzen.Interessante Zerhackstückelung meines Beitrags. Dass ich mich auf die Arbeit bezog, hast Du aber schon gemerkt oder? Falls nein, habe ich die entsprechende Textstelle mal für Dich markiert. Evtl. fällt das Verstehen des Gelesenen dann leichter.
-----
Man hat doch heutzutage häufig die Wahl zwischen einem Richclient oder einem Webclient als Frontend (sieht man ja schon am Thema dieses Threads). Wenn ich nun als Programmierer täglich Richclients implementiere, dann werde ich wohl Richclients aufgeschlossener gegenüber stehen als Webclients. Umgekehrt gilt das gleiche.
C++ Anwendungen (falls grafisches Frontend vorhanden) werden idR als Richclient entwickelt. Daher ist das bisherige Fazit dieses Threads nicht verwunderlich.
Und mal unter uns: Webthemen werden in diesem Board unter Spezialitäten -> Webzeugs abgestempelt. Wer erwartet da bitte eine ernsthafte Diskussion zum Thema Webclients?
-
general bacardi schrieb:
Das stimmt. Man sollte größere Anwendungen vielleicht immer so schreiben, daß einezelen Komponenten über Schnittstellen kommunizierem, die lokal als auch über Netze möglich sind. Das X-Window System ist ein bekanntes Beispiel für diese Strategie
In der Java-Welt lässt sich sowas sehr elegant mit dem Spring Framework erreichen. Wir haben beispielsweise verschiedene Dienste implementiert, die Daten aus einer DB bereitstellen oder bestimmte Berechnungen machen. Manche Dienste laufen automatisiert als Jobs zu bestimmten Zeiten ab. Die Dienste sind ganz einfache POJOs.
Mit Hilfe von Spring können wir die Dienste nun beliebig bereitstellen. Wir benutzen einen Webserver, der die Dienste über HTTP bereitstellt. Ohne den Sourcecode zu ändern, könnten wir die Dienste aber auch über ein anderes Verbindungsprotokoll anbieten, z.B. als Webservice über SOAP. Wir könnten die Anwendung aber auch einfach als Standalone Applikation builden. Dann kommen wir ganz ohne Server aus. Das ist alles mit ein bißchen Konfiguration problemlos möglich.
Als Frontend kommt übrigens ein Richclient zum Einsatz. Man könnte das ganze ohne weiteres um ein Webfrontend ergänzen.
-
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Das hat mit Skepsis weniger zu tun als mit Fakten.
-
hustbaer schrieb:
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Das hat mit Skepsis weniger zu tun als mit Fakten.
Es ist Fakt dass C++ Programmierer skeptisch gegenüber Webtechnologien sind? Das kann ich nicht bestätigen
-
general bacardi schrieb:
hustbaer schrieb:
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Das hat mit Skepsis weniger zu tun als mit Fakten.
Es ist Fakt dass C++ Programmierer skeptisch gegenüber Webtechnologien sind? Das kann ich nicht bestätigen
Aber sind den Web-Techniken wirklich so modern? Ich meine hier "modern" im Sinne von "innovativ", "weiterentwickelt" oder "richtungsweisend". Ich meine, der große Vorteil des Webs (im Hinblick auf Software-Entwicklung) ist doch, dass jeder User schon einen Browser zur Verfügung hat. Doch an dem, was dann in diesem Browser geschieht, kann ich eigentlich nicht viel modernes finden. Das Web 2.0 ist in dem Sinne modern, dass man innerhalb des Webs einen neuen Weg gefunden hat. Das Ergebnis aber bleibt deutlich hinter dem zurück, was mit normaler Software seit Jahren Usus ist. Moderne Web-Technik imitiert doch hauptsächlich diese altbekannten Dinge. Oder nicht?
Bitte versteht das nicht polemisch! Ich möchte wirklich gern erfahren, was ihr an Web-Technik modern (in obigem Sinne) findet.
Stefan.
-
DStefan schrieb:
Bitte versteht das nicht polemisch! Ich möchte wirklich gern erfahren, was ihr an Web-Technik modern (in obigem Sinne) findet.
Ich habe mit "modernen Webtechnologien" nicht die Tatsache gemeint, dass Web 2.0 grundsätzlich Frontends revolutioniert. Sicherlich verursacht man häufig, einfach nur das nachzuahmen, was schon seit lange bei Richclients verwendet wird.
Das "modern" bezog sich vielmehr auf den technischen Hintergrund, also auf die Hilfsmittel, die man bei aktuellem Stand zur Verfügung hat, um State of the Art Web 2.0 Anwendungen zu schreiben.
Wenn ich mir Technologien wie YUI oder Google Web Toolkit angucke, dann sind das in meinen Augen (aus technischer Sicht) durchaus Innovationen der letzten Jahre. Und wenn man genau hinschaut, dann bieten viele Web 2.0 UI Bibliotheken längst viel viel mehr UI Komponenten als die meisten Richclient UI Bibliotheken.
Guckt Euch z.B. mal die Komponenten von GXT (einer UI Bibliothek für GWT) an und vergleicht das Angebot an Komponenten mit der Richclient UI Bibliothek eurer Wahl:
-
Hem, kannst du bitte eine Komponente nennen, die es nicht für Richclients gibt? Ich habe jetzt nicht alle Beispiele ausprobiert, aber irgendwie sind das alles bekannte Widgets (Buttons, Trees, Tables usw.) die dann zusammen komponiert wurden, und dann was "neues" ergeben.
Die Komposition kann ich, wenn die mir fehlt, in gtkmm, Qt, Swing usw. selber machen. bei diesem Ext GWT hat halt jemand die Vorarbeit gemacht und alles auf einmal zur Verfügung gestellt. Sehr kompfortabel für den Library-Anwender, keine Frage... aber technisch innovativ? Komposition ist Basis in der OOD.
-
Artchi schrieb:
Hem, kannst du bitte eine Komponente nennen, die es nicht für Richclients gibt? Ich habe jetzt nicht alle Beispiele ausprobiert, aber irgendwie sind das alles bekannte Widgets (Buttons, Trees, Tables usw.) die dann zusammen komponiert wurden, und dann was "neues" ergeben.
Die Komposition kann ich, wenn die mir fehlt, in gtkmm, Qt usw. selber machen. bei diesem Ext GWT hat halt jemand die Vorarbeit gemacht und alles auf einmal zur Verfügung gestellt. Sehr kompfortabel für den Library-Anwender, keine Frage... aber technisch innovativ? Komposition ist Basis in der OOD.
Alleine bei den Grids ist einiges dabei, was ich so bisher selten gesehen habe und was ziemlich aufwendig zu relisieren ist mit den mir bekannten Richclient Libs, so z.B.:
- Paging Grid
- Row Editor Grid
- Grouping Grid
- Live Summary Grouping GridInnovativ ist das Google Web Toolkit durch den Java-To-JavaScript Compiler, auf dem diese UI Lib basiert.
Aber ansonsten hast Du recht. Man kann sich das auch alles selbst zusammenbauen. Nur kannst du dann viele Projekte nicht mehr in adäquater Zeit realisieren.
-
byto schrieb:
Alleine bei den Grids ist einiges dabei, was ich so bisher selten gesehen habe und was ziemlich aufwendig zu relisieren ist mit den mir bekannten Richclient Libs, so z.B.:
- Paging Grid
- Row Editor Grid
- Grouping Grid
- Live Summary Grouping GridOK, habe sie mir jetzt angeschaut. Ist aber nichts, was man nicht auch in Richclients realisieren kann oder gar hat. Das Paging Grid haben wir hier in unserer grafischen Terminal-Emulation (Java-Richclient) auch drin. Wir haben in dieser Terminal-Emulation sogar Intellisense drin. Wenn du z.B. in einem Datumsfeld bist, drückst du STRG+SPACE oder die Maustaste und es erscheint ein Popup-Kalendar um das Datum auszuwählen. Auch haben wir in eingabefeldern die Möglichkeit Popup-Tabellen und -Listen (mit dynamischen Inhalten!) per STRG+SPACE/Maustaste anzuzeigen und dann kann der User was auswählen. Wohlgemerkt alles gegen einen IBM-Mainframe, das Protokoll (per XML) haben wir selber über ein Gateway realisiert. Im Grunde genommen "AJAX" für IBM-Mainframes.
Wir sind sogar soweit, das wir in Terminal-Masken mit unserem Client sogar Charts darstellen können.
Es ist zwar kein Webbrowser, sondern du benutzt halt einen Java-Richclient. Aber das da oben von dir genannte, ist alles gang und gäbe, wo selbst IBMs Vertreter bei einer unserer Präsentation nicht schlecht gestaunt haben.
Aber nochmal zu den gängigen Richclients: dieses Roweditor-Grid ist doch nur eine Renderer-Klasse. Das kann ich in Swing mit der CellEditorRenderer-Klasse lösen. Ich muß da nicht wirklich was programmieren, sondern muß nur sagen welche "Editor-Klasse" er benutzen soll.
In gtkmm ist das auch nicht anders:
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/figures/treeview_editablecells.png
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/figures/treeview_list.pngDie Kostenberechnung in dem Group Summerie löst man mit nem Tablemodel, ist dann halt ein Algorithmus im einen Row-Model drin. Tägliches Geschäft hier bei uns.
Das ist alles OOP mit Strategy-Patterns und Komposition.
Coole Sache das es sowas für WebBrowser gibt! Ich war auch damals erstaunt, als ein Kollege von mir hier eine Ajax-Anwendung für den Kunden entwickelte. Über mein Erstaunen mußte er dann wieder staunen, weil das doch technisch alles alter Kaffe ist. Sein Kommentar so in etwa: "Das geht seit dem es JavaScript und XML gibt.".
byto schrieb:
Innovativ ist das Google Web Toolkit durch den Java-To-JavaScript Compiler, auf dem diese UI Lib basiert.
Im Ernst, das ist ein Implementierungsdetail, das für die Frage dieses Threads nicht wirklich relevant ist. Den WebApps-User interessiert das nicht, und er soll davon ja auch nichts merken.
-
Ich stelle nur eines fest: die WebApps-Technik ist vom Grundgedanke alter Kaffee. Aber man ist jetzt technisch so weit, das man endlich mit Richclients aufgeschlossen hat (überholt kann ich nicht feststellen), was die Widgets-Funktionen angeht. Die Toolkits Ext GWT und Wt sind gute Beispiele dafür.
Für mich pers. bleiben immer noch Nachteile:
1. keine end-to-end-Verschlüsselung
2. keine einheitliche GUI-Konzepte und Workflow
3. ich habe immer noch Wartezeiten in den Aktionen
4. meine Daten müssen bei fremden Anbietern lagern, was mit end-to-end-Verschlüsselung nicht so schlimm wäre
-
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Warum gibts keine Swing Library, die solche Komponenten fertig implementiert, wenn sowas - wie Du schön erkannt hast - Gang und Gäbe ist?Artchi schrieb:
Im Ernst, das ist ein Implementierungsdetail, das für die Frage dieses Threads nicht wirklich relevant ist. Den WebApps-User interessiert das nicht, und er soll davon ja auch nichts merken.
Achso sorry. Hatte angenommen, wir sind hier in nem Programmierforum.
-
byto schrieb:
Innovativ ist das Google Web Toolkit durch den Java-To-JavaScript Compiler, auf dem diese UI Lib basiert.
Das C++-Webtoolkit (dieses "Wt" bzw "Witty") gab's zuerst und macht ja afair das Gleiche :p
Das Konzept davon finde ich aber auch innovativ.
-
Artchi schrieb:
1. keine end-to-end-Verschlüsselung
Ist mit HTTPS gegeben.
Artchi schrieb:
2. keine einheitliche GUI-Konzepte und Workflow
Ist bei Richclients auch nicht der Fall.
Artchi schrieb:
3. ich habe immer noch Wartezeiten in den Aktionen
Hast du bei Richclients auch, ausser Du verarbeitest ausschließlich Offline Daten.
Artchi schrieb:
4. meine Daten müssen bei fremden Anbietern lagern, was mit end-to-end-Verschlüsselung nicht so schlimm wäre
siehe 1.
Gegenfrage, wie realisiert ihr denn den Zugang auf Eure Host DB2? Wie sichert ihr die Zugangsdaten ohne Server?
-
byto schrieb:
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Weil unser Terminal-Client das schon seit fast 10 Jahren kann? Und wie lange gibt es das Ext GWT? Ich glaube, Google als Firma gibts nicht mal so lange.
byto schrieb:
Warum gibts keine Swing Library, die solche Komponenten fertig implementiert, wenn sowas - wie Du schön erkannt hast - Gang und Gäbe ist?
Also erstmal, habe ich von einer Terminal-Emulation gesprochen, die wir mit eigenen grafischen Routinen versehen haben. Weil eine Terminal-Maske was anderes ist, als eine Richclient-Maske. Wir haben das nötige drin gelassen, und mit modernem angereichert. Konkret gesagt, wir benutzen keine Swing-Komponenten, nur die Swing-Graphics-Funktionen zum Zeichnen der Maske... ich bezweifel, das es sowas vor über 10 Jahren gab, so wie wir es speziell benötigten.
Leider kann ich kein Screenshot posten, weil das alles Inhouse-Entwicklung ist.
Was aber die Swing-Komponenten für "normale" Richclient-Anwendungen angeht: ich habe doch gesagt, das die alle in der Java-Runtime vorhanden sind. Genauso wie Gtkmm und Qt solche Komponenten auch hat. Ich weiß jetzt nicht wirklich, was du da jetzt vermisst?
-
byto schrieb:
Artchi schrieb:
1. keine end-to-end-Verschlüsselung
Ist mit HTTPS gegeben.
Nein, die Verschlüsselung geht nur vom Browser bis zum HTTP-Server. Das ist keine end-to-end-verschlüsselung, weil die daten z.B. auf dem Server unverschlüsselt abgelegt/verarbeitet werden.
end-to-end heißt, das sie auf dem CLient verschlüsselt werden, und auf dem Client erst wieder entschlüsselt werden. So das der Dienstleister (oder ein anderer dritter) keine Rohdaten erhält.Wenn ich z.B. im WebMail-Interface eine EMail eintippe und losschicke, kann sie jeder lesen. Die verschlüsselung zwischen Browser und http-Server bringt nichts.
Ich muß also den Mailtext auf meinem PC mit einem Tool verschlüsseln, den kryptyschen Text in das WebMail-Interface einfügen und losschicken. Die Mail geht verschlüsselt zum Empfänger. Und der EMpfänger kann erst auf seinem PC entschlüsseln, in dem er den kryptischen Mailtext aus dem WebMail-Interface kopiert und mit einem Tool entschlüsselt. Also von einem Ende zum anderen Ende.
Aber diese Arbeit macht sich doch keiner, da wird man ja blöd bei.
Sowas macht Thunderbird (mit Enigmail) oder TheBat! im Hintergrund für mich. Rich-Client halt.
-
byto schrieb:
Gegenfrage, wie realisiert ihr denn den Zugang auf Eure Host DB2? Wie sichert ihr die Zugangsdaten ohne Server?
Die Frage habe ich nicht verstanden. Kannst du das genauer formulieren?
-
byto schrieb:
Ihr habt Euch diese Komponenten selbst zusammengebaut. Oben genanntes Framework bietet das Out of the Box. Das ist der Unterschied. Und genau auf den wollte ich hinaus.
Was soll das für einen Unterschied sein? Es gibt überall GUI Bibliotheken, welche spezielle zusammengebaute Komponenten Out of the Box anbieten. Das ist doch keine Innovation oder was neues, sondern da hat sich einfach der Entwickler der Bibliothek ein wenig Zeit genommen, noch ein paar alltägliche zusätzliche Komponenten zusammenzusetzen.
Ich sehe dann eher das Problem, dass die Komponenten zu spezialisiert sind und man ein oder zwei Dinge anders bräuchte und sie dann trotzdem selber erstellen muss. Deshalb sind eben viele Frameworks sehr fundamental gehalten, damit jeder das zusammensetzen kann, was er braucht.
Den einzigen Unterschied, welcher ich sehe, ist vielleicht das WIE des Zusammensetzens. Wobei es allerdings auch bei Richclients bereits solche Ansätze seit längerem gibt. Eine neuere oder bekanntere Vertretung in dem Bereich wäre zum Beispiel WPF für dotNet.
Ich sehe es also auch eher so, dass die Web UIs langsam die Richclient UIs einholen. Wobei dies allerdings hauptsächlich nur das graphische Betrifft. Von der Reaktionszeit solcher Web UIs wollen wir lieber mal nicht reden.
Allerdings finde ich, dass die Diskussion gerade ein wenig in die falsche Richtung geht. Man sollte nicht darüber diskutieren, was für den allgemeinen Fall besser ist, denn das ist wohl ziemlich schwer zu definieren. Es wurde, glaube ich, schon eimal gesagt und ich finde das sehr wichtig für diese Diskussion: Es kommt wahnsinnig stark auf die Anwendung an.
Sollte die Diskussion nicht eher in die Richtung gehen, dass sie definiert, welche Anwendungen man als WebApps realisieren sollte? Ich sehe viele Programme, welche sehr sinnvoll als WebApps sind und viele, welche ich nie als solche haben möchte. Die Kriterien dafür festzusetzen, finde ich aber zum Teil gar nicht so einfach, weil es oft sehr viele Grenzfälle dabei hat.
Ab wann sollte man also eine Anwendung als WebApp implementieren und wann nicht?Grüssli
