Vorteile von Nicht-Web-Applikationen?
-
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
-
general bacardi schrieb:
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
Hat Bulli behauptet, das hauptsächlich C++ für Web-Apps eingesetzt wird?
Lediglich die Möglichkeit aufgeführt, das es technisch geht und wenn man wollte, eine Lib nutzen könnte.Es wurde aber auf jeden Fall widerlegt, das C++-User generell was gegen "moderne" Web-Technologien haben. Wobei das modern auch nicht stimmt, wie mir ein Java-Web-Kollege erzählt hat. AJAX gibt es schon ewig und gehört zum alten Eisen, ist halt nur jetzt hipp geworden, weil die Leitungen beim Kunden und Server schneller geworden sind.
-
Artchi schrieb:
general bacardi schrieb:
Bulli schrieb:
Wo man doch sogar mit C++ AJAX-Anwendungen programmieren kann:
Das ist eher die Ausnahme. in der Regel wird C++ im Webbereich nicht verwendet.
Hat Bulli behauptet, das hauptsächlich C++ für Web-Apps eingesetzt wird?
Habe ich behauptet, dass jemand das behauptet hat?
-
Bulli schrieb:
byto schrieb:
Irgendwie verwunderts wenig, dass in einem C++ Forum eher Skepsis ggü. modernen Webtechnologien herrscht.
Unglaublich wie die Leute die Kurve von Hat-Nichts-Mit-C++-zutun zum C++-und-seine-User-sind-eh-Loser bekommen.
Interessante Wertung aus einer sonst recht neutralen Schlussfolgerung meinerseits.
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.
-
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.Laut deiner Schlußfolgerung, dürften PHP-Progger keine Erlebnisse mit C++-Programmen haben.
-
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
-
byto schrieb:
Interessante Wertung aus einer sonst recht neutralen Schlussfolgerung meinerseits.
Bis zu deinem Posting hat keiner C++ ins Spiel gebracht. Wie man das eingeworfene "C++-Programmierer" als neutral einstufen kann, zeigt, das es nur wieder um einen C++-Flamewar geht. Lass es doch einfach und bleib beim Thema Web-Apps!
-
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!
-
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.
