Desktop Anwendung im Browser?

[uepselon]

Hallo,

immer öfter lese ich über diverse Anwendungen, die nach "modernstem" Stand der Technik, entwickelt wurden. Vollständig webfähig also und nur in einem Browser lauffähig, aber dennoch den funktionskomfort einer normalen Applikation.

Aha, sehr interessant. Umgesetzt sind solche "wunderschönen" Programme dann mittells HTML, CSS und JavaScript, gestützt von einer Serverseitingen Sprache wie JSP oder ASP und Web Services.

Schon beim ersten Blick sind mir da ein paar Zweifel gekommen, ob solche Anwendunge wirklich so toll sind, wie Sie angepriesen werden?

1. Wie wird erreicht, dass die Seite bei jeder Interaktion nicht neu aufgebaut werden muss? Im Internet Explorer ginge das ja über Web Service Calls (behavior:css->webservice.htc). Aber in Mozilla, Opera und Co?

2. Ohne JavaScript läuft nichts, und die Standard sind von Browser zu Browser ja immernoch unterschiedlich, oder liege ich da inzwischen Falsch? Ich habe zwar schon gut einem Jahr kein Webdesign mehr betrieben, aber früher war da ein heiloses Durcheinander, un JaavScript eher Spielerei statt notwendiges Hilfsmittel.

Also liebe Forumsgemeinde, was haltet Ihr von solchen Anwendungen, bzw. wo seht ihr die Schwächen und Gefahren?

Ich persönlich bevorzuge bei webfähigen Anwendungen eher die Java Applet Variante.

Gruß,

ueps

p.s. was zur Hölle ist der Fehler im Forum: "Error not found: de_E_unid_long" kommt bei mir ständig und ist recht nervig! Muss jedesmal über einen Proxy posten!

[Dieter Raber]

Hallo uepselon,

Ein Beispiel

Ich habe vor einiger Zeit eine webbasierte Anwendung fuer Inmobilienmakler geschrieben. Im Prinzip geht es dabei darum, neue Wohnungen, Haeuser etc. anzulegen, alte zu bearbeiten, Kundenliste zu verwalten und solche Sachen.
Die Applikation ist in PHP geschrieben und genau genommen ein Frontend fuer eine Datenbank. Im Webbrowser sieht man also im Grunde entweder Formulare oder deren Auswertungen. Das Ganze wird vorwiegend in Intranets benutzt, ich weiss also immer recht genau, was meine Kunden als Browser benutzen. Zudem kann ich auch bestimmte Browser voraussetzen. Insofern muss ich mir ueber Javascript wenig Gedanken machen. Zudem sind die modernen Browser, was Javascript anbetrifft, mittlerweile ziemlich aehnlich, dh. dank DOM gehoeren Sachen wie document.all oder document.layers eigentlich der Vergangenheit an.
Du hast natuerlich recht, dass jede Aktion einen Server-Roundtrip bedeutet, aber das geht (meist) genauso flott, wie in einer 'klassichen Software'.
Die Vorteile liegen auf der Hand:

• die Anwendung wird nur einmal installiert, ansonsten braucht jeder Teilnehmer nur seinen Webbrowser
• die Anwender koennen, entsprechende Rechte vorausgesetzt, von ueberall auf die Anwendung zugreifen
• die Daten sind immer aktuell
• die Anwendung ist (relativ) unabhaengig vom verwendeten Betriebssystem, sowohl auf der Serverseite, als auch auf der Clienseite.

Gruß,

Dieter

[Cybaer]

Hi,

1. Wie wird erreicht, dass die Seite bei jeder Interaktion nicht neu aufgebaut werden muss?

DHTML (DOM)

2. Ohne JavaScript läuft nichts,

Kommt drauf an.

und die Standard sind von Browser zu Browser ja immernoch unterschiedlich,

Na und?

oder liege ich da inzwischen Falsch?

Sowieso.

Ich habe zwar schon gut einem Jahr kein Webdesign mehr betrieben, aber früher war da ein heiloses Durcheinander, un JaavScript eher Spielerei statt notwendiges Hilfsmittel.

Ich betreibe seit 10 Jahren Web-Design und habe noch nie eine Extra-Seite für einen speziellen Browser gebraucht. Was das Scriptig eines Browsers kann, kann man i.d.R. auch durch das Scripting abfragen - browserunabhängig.

Also liebe Forumsgemeinde, was haltet Ihr von solchen Anwendungen, bzw. wo seht ihr die Schwächen und Gefahren?

Super. Online-Verbindung notwendig. Keine (Verschlüsselung vorausgesetzt).

Gruß, Cybaer

[Cybaer]

Nachtrag:

1. Wie wird erreicht, dass die Seite bei jeder Interaktion nicht neu aufgebaut werden muss?
   DHTML (DOM)

Und natürlich Frames. In einem unsichtbaren Frame kann eine "PHP-Engine" z.B. "interagieren", bis sie schwarz wird. Ich bekomme im Hauptframe davon nichts mit.

[Andreas Korthaus]

Hi!

1. Wie wird erreicht, dass die Seite bei jeder Interaktion nicht neu aufgebaut werden muss?
   DHTML (DOM)

Und natürlich Frames. In einem unsichtbaren Frame kann eine "PHP-Engine" z.B. "interagieren", bis sie schwarz wird. Ich bekomme im Hauptframe davon nichts mit.

Was verwendest hier für die Interaktion? Lädts Du Javascripte neu die andere Frames steuern?

Grüße
Andreas

[Cybaer]

Hi,

Was verwendest hier für die Interaktion?

Z.B. Client-Server-Interaktion.

Lädts Du Javascripte neu die andere Frames steuern?

Nein, ich hole und sichere Daten, die ich nur mit serverseitiger Technik holen und sichern kann, während clientseitige Technik diese Daten problemlos auswerten, bereitstellen und einbinden/darstellen kann.

Gruß, Cybaer

[Andreas Korthaus]

Hallo!

Was verwendest hier für die Interaktion?

Z.B. Client-Server-Interaktion.

was sonst :)

Lädts Du Javascripte neu die andere Frames steuern?

Nein, ich hole und sichere Daten, die ich nur mit serverseitiger Technik holen und sichern kann, während clientseitige Technik diese Daten problemlos auswerten, bereitstellen und einbinden/darstellen kann.

Ich meine, wie Du das konkret machst.

1. wenn Du jetzt irgendwas in der "GUI" machst, was Du auf dem Server speichern willst, aber ohne einen direkten Request (Formular abschicken), wie   machst Du das genau?

2. Wenn Du einen Wert vom Server holen willst, meietwegen aus der DB, aber ohne das das Hauptfenster neu geladen wird, wie machst Du das?

Viele Grüße
Andreas

[Cybaer]

Hi,

Z.B. Client-Server-Interaktion.
was sonst :)

Z.B. Benutzer-Client ;)

1. wenn Du jetzt irgendwas in der "GUI" machst, was Du auf dem Server speichern willst, aber ohne einen direkten Request (Formular abschicken), wie   machst Du das genau?

Das eine schließt das andere doch nicht aus. Man muß den Request aber nicht "sehen" müssen! ;-)

Man kann als Formularziel auch einen "Engine-Frame" angeben! Man kann aber auch per location.href/reload()/replace() einen Request (im "Engine-Frame") auslösen.

2. Wenn Du einen Wert vom Server holen willst, meietwegen aus der DB, aber ohne das das Hauptfenster neu geladen wird, wie machst Du das?

Ad 1) Daten aus dem GUI-Frame werden dem Engine-Frame übergebe (JS & DOM oder FORM & TARGET); dort startet die serverseitige Aktion.
Ad 2) Nach einer Aktion wertet ein JS die ggf. neuen Daten des Engine-Frames aus und aktualisiert, z.B. mittels DOM, den GUI-Frame.Steht JS nicht (oder nur unzureichend) zur Verfügung, muß halt die gesamte Seite anhand der neuen Daten gerendert werden.

Gruß, Cybaer

[Ludger]

Hi,

Und natürlich Frames. In einem unsichtbaren Frame kann eine "PHP-Engine" z.B. "interagieren", bis sie schwarz wird. Ich bekomme im Hauptframe davon nichts mit.

diese Interaktion, die Du meinst, wofuer macht diese bspw. Sinn? (Es waere doch einfacher immer wieder die gesamte Oberflaeche an den Client zu schicken.)

Gruss,
Ludger

[Cybaer]

Hi,

diese Interaktion, die Du meinst, wofuer macht diese bspw. Sinn? (Es waere doch einfacher immer wieder die gesamte Oberflaeche an den Client zu schicken.)

Einfacher ist mitunter vieles, hübscher schon weniger.

Wenn ich z.B. in einem Online-Editor den Text abspeichern möchte, dann kann dies ein PHP-Script sinnvollerweise "unsichtbar" im Hintergrund tun, während ein JavaScript im Hauptfenster nur die Statusanzeige des Dokuments aktualisiert. Weswegen sollte da gleich die gesamte Oberfläche des Clients neu geladen und gerendert werden (mit all den sich daraus ergebenden Nachteilen und Häßlichkeiten)?

Gruß, Cybaer

[Christoph Zurnieden]

Hi,

2. Ohne JavaScript läuft nichts,

Kommt drauf an.

Wenn es nciht gerdade etwas _sehr_ einfaches ist, kommst DU um Javascript nicht herum. Aber es hält isch in engen Grenzen, normalerweise sind da keine Spezialitäten nötig, das kann auch ein 4er.

und die Standard sind von Browser zu Browser ja immernoch unterschiedlich,

Na und?

Bei _sehr_ komplexen Anwendungen kommst Du ohne Spezialisierung wahrscheinlich nicht mehr weiter.
Das es viele auch ohne guten Grund machen, ist natürlich eine ander Sache; sollte einne aber nicht weiter ablenken ;-)

Also liebe Forumsgemeinde, was haltet Ihr von solchen Anwendungen, bzw. wo seht ihr die Schwächen und Gefahren?

Super.

Sehr praktisch, aber nicht ohne Risiken.

Online-Verbindung notwendig.

Wollen's nicht hoffen ;-)

Keine (Verschlüsselung vorausgesetzt).

Grundlegendes Risiko bei dieser Art der Datenverarbeitung ist der Umstand, das man seine Daten an Dritte abgibt. Im Intranet ist das noch gut zu beaufsichtigen, aber wenn's einmal hinaus geht in die weite Welt ist's damit dann Essig. Die eigentliche Verbindung mag ja noch mit 128 Bit oder mehr abgesichert sein, aber was passiert mit den Daten auf dem fremdem Rechner? Ist der sauber abgesichert? Sind alle Angestellten reich genug und nicht erpressbar?

Ich glaube, das es der Hauptgrund dafür ist, das viele Versuche - eigentlich alle - in dieser Richtung gescheitert sind, sobald sie das Intranet verlassen wollten.

so short

Christoph Zurnieden

[Cybaer]

Hi,

Wenn es nciht gerdade etwas _sehr_ einfaches ist, kommst DU um Javascript nicht herum. Aber es hält isch in engen Grenzen, normalerweise sind da keine Spezialitäten nötig, das kann auch ein 4er.

ACK

Bei _sehr_ komplexen Anwendungen kommst Du ohne Spezialisierung wahrscheinlich nicht mehr weiter.

Auch ACK. Kommt mir auch unter, aber nichts, an dem man wirklich verzeifeln würde. ;-)

Das es viele auch ohne guten Grund machen, ist natürlich eine ander Sache; sollte einne aber nicht weiter ablenken ;-)

:)

Online-Verbindung notwendig.
Wollen's nicht hoffen ;-)

OK, Server-Verbindung notwendig. ;-)

aber was passiert mit den Daten auf dem fremdem Rechner? Ist der sauber abgesichert?

OK, ich bin (scheinbar nicht "natürlich" ;-)) von eigene/Firmenrechnern ausgegangen, auf denen ich eigene/Firmenarbeite erledige.

Sind alle Angestellten reich genug und nicht erpressbar?

:) Na ja, es gibt ja nicht nur sensible Daten. =;-)

Ich glaube, das es der Hauptgrund dafür ist, das viele Versuche - eigentlich alle - in dieser Richtung gescheitert sind, sobald sie das Intranet verlassen wollten.

Ich halte die mangelnde Akzeptanz eher für ein psychologisches Problem, gespeist aus der Neuartigkeit der Arbeitsweise und der "Virtualität" von Software, Daten und Hardware. Aber wenn man sich erstmal dran gewöhnt hat ...

Ich möchte jedenfalls meine "Online-Software" *nie* mehr missen ... :-))

Gruß, Cybaer

[Christoph Zurnieden]

Hi,

Sind alle Angestellten reich genug und nicht erpressbar?

:) Na ja, es gibt ja nicht nur sensible Daten. =;-)

Wer soll das denn sortieren?
Was ist denn in einer Firma nicht sensibel, mal ganz so aus dem Stegreif? Die Werbebroschüre? Gut, die ist nun wirklich nicht sensibel. Aber sonst?

so short

Christoph Zurnieden

[Cybaer]

Hi,

:) Na ja, es gibt ja nicht nur sensible Daten. =;-)
Wer soll das denn sortieren?

Möglichst niemand, weswegen man ja auch auf dem eigenen Server und mit Verschlüsselung arbeiten sollte - wie ich schrieb.

Was ist denn in einer Firma nicht sensibel, mal ganz so aus dem Stegreif? Die Werbebroschüre? Gut, die ist nun wirklich nicht sensibel.

Also ein Zwinkersmiley, ist ein Zwinkersmiley! =;-)

Aber falls Du tatsächlich eine ernsthafte Antwort erwartest: Das kommt drauf an. ;)

Gruß, Cybaer

PS: Auch eine Werbebroschüre ist ggf. sensibel. Wenn ein Mitbewerber diese vorzeitig in die Hände bekommt, kann das wirklich übel sein ... =8-o

[Christoph Zurnieden]

Hi,

Was ist denn in einer Firma nicht sensibel, mal ganz so aus dem Stegreif? Die Werbebroschüre? Gut, die ist nun wirklich nicht sensibel.

Also ein Zwinkersmiley, ist ein Zwinkersmiley! =;-)

Ich schreibe nicht immer dran: "Das ist nicht ernst gemeint", mitunter darf man sich da 'was aussuchen.

PS: Auch eine Werbebroschüre ist ggf. sensibel. Wenn ein Mitbewerber diese vorzeitig in die Hände bekommt, kann das wirklich übel sein ... =8-o

Nur große Firmen können in-house drucken, meist wird das au'er Haus gegeben. Es muß also davon ausgegangen werden, das ab diesem Zeitpunkt der Konkurenz alles bekannt ist.

so short

Christoph Zurnieden

[Cybaer]

Hi,

Ich schreibe nicht immer dran: "Das ist nicht ernst gemeint", mitunter darf man sich da 'was aussuchen.

OK! :-) Allerdings: Wenn wir uns in natura gegenüber ständen, dann müsstest Du mein schelmisches Grinsen auch erst zu deuten wissen! :)

Internet ist halt "wie im richtigen Leben" ... ;-)

Nur große Firmen können in-house drucken, meist wird das au'er Haus gegeben. Es muß also davon ausgegangen werden, das ab diesem Zeitpunkt der Konkurenz alles bekannt ist.

Schon, aber optimalerweise vergeht von Datenanlieferung über Druck bis zur Auslieferung kaum Zeit (so sollte es - aus mehreren Gründen - jedenfalls sein). Aber bis das Ding erstmal fertig, bis alle Texte erstmal geschrieben sind ... 8-)

Gruß, Cybaer

[uepselon]

DHTML (DOM)

2. Ohne JavaScript läuft nichts,

Kommt drauf an.

DOM läuft dann nicht mehr, ergo kann man aus einer Interseit die ansich statisch ist keine dynamsche Anwendung mehr machen, wie man Sie als Desktop Applikation vorfinden würde!

und die Standard sind von Browser zu Browser ja immernoch unterschiedlich,

Na und?

Komplexer Applikationen verlieren damit, Ihre Qualität.

oder liege ich da inzwischen Falsch?

Sowieso.

genau

Ich betreibe seit 10 Jahren Web-Design und habe noch nie eine Extra-Seite für einen speziellen Browser gebraucht. Was das Scriptig eines Browsers kann, kann man i.d.R. auch durch das Scripting abfragen - browserunabhängig.

Wie gesagt bei komplexen Anwendungen musst dann JavaScript Code schreiben bis du schwarz wirst. Und das mit vielen Browserspezifischen unterschieden. Zeit ist halt nun mal Geld!

MfG,

ueps

[Cybaer]

Hi,

Kommt drauf an.
DOM läuft dann nicht mehr, ergo kann man aus einer Interseit die ansich statisch ist keine dynamsche Anwendung mehr machen, wie man Sie als Desktop Applikation vorfinden würde!

Doch, natürlich kann man das. Allerdings dann nur mit dem jeweiligen Neuladen des Dokuments. Eine DOM-unterstützende Variante ist IMHO hübscher und (ggf.) komfortabler, weil sie viele Server-Zugriffe/Reloads überflüssig macht. Aber es obliegt dem Willen/der Fähigkeit/dem zur Verfügung stehenden Zeitaufwand des Programmierers, es sowohl mit, als auch ohne JavaScript zu realisieren.

und die Standard sind von Browser zu Browser ja immernoch unterschiedlich,
Na und?
Komplexer Applikationen verlieren damit, Ihre Qualität.

Also ich finde, daß das Scripting, was alle Browser beherrschen (bzw. mindestens die der 3. Generation - also DOM Level 2), absolut ausreichend ist, wenn man es mit serverseitigem Scripting koppelt. Auf proprietären Unfug kann man i.d.R. verzichten - nur ist die Umsetzung ggf. etwas schwieriger.

Daß es aber unterschiedliche Qualitäten geben kann, ist klar, da es halt unterschiedliche Browser gibt (z.B. den Navigator 3 ;->).

Wie gesagt bei komplexen Anwendungen musst dann JavaScript Code schreiben bis du schwarz wirst.

Nein.

Und überhaupt: Wer redet denn von JavaScript bei komplexen Anwendungen? Ich sehe JS immer als ein (wünschenswertes, aber ggf. fehlendes/unvollständiges) Hilfsmittel an, und habe das auch immer getan. Aber es kann serverseitige Sprachen (PHP, Perl, ...) *wunderbar* unterstützen!

Und das mit vielen Browserspezifischen unterschieden. Zeit ist halt nun mal Geld!

Ja, so sehen die Websites mit ihren Fehlern auch aus ... *SCNR*

... und ich würde deinen Spruch auch abändern wollen in "auch Inkompetenz kann viel Zeit & Geld kosten - zumal sie sich nie so nennt"! >>:-> Ein Tischler-Azubi versucht sich auch nicht am Nachbau einer Stradivari. Im Web hingegen bastelt er sich 'nen Scheiß zusammen (mit 'ner Software, die 'nen Scheiß produziert), hat aber keinen blassen Schimmer, was er da tut, und nennt sich Profi-Webdesigner ...

Gruß, Cybaer

[uepselon]

DOM läuft dann nicht mehr, ergo kann man aus einer Interseit die ansich statisch ist keine dynamsche Anwendung mehr machen, wie man Sie als Desktop Applikation vorfinden würde!

Doch, natürlich kann man das. Allerdings dann nur mit dem jeweiligen Neuladen des Dokuments.

Und dann ist es keine flüssige Applikation mehr! Oder wie willst du PopUp Menüs, spezielle Tastatur-Short-Cuts, zur Laufzeit anpassaber Datentabellen und all den Kram hinbekommen. Und das ohne, das man der Seite beim neuladen zukucken kann?

Wie gesagt bei komplexen Anwendungen musst dann JavaScript Code schreiben bis du schwarz wirst.

Nein.

Und überhaupt: Wer redet denn von JavaScript bei komplexen Anwendungen?

Ich, oder wie willst du oben genannte, Applikations Funktionalität, in eine Webseite integrieren? Ich rede nicht von einer simplen Shop Seite, sondern von einer Anwendung wie z.B. ein ERP System wie SAP!

Ja, so sehen die Websites mit ihren Fehlern auch aus ... *SCNR*

... und ich würde deinen Spruch auch abändern wollen in "auch Inkompetenz kann viel Zeit & Geld kosten - .... Im Web hingegen bastelt er sich 'nen Scheiß zusammen (mit 'ner Software, die 'nen Scheiß produziert), hat aber keinen blassen Schimmer, was er da tut, und nennt sich Profi-Webdesigner ...

Wer solche "Profis" angagiert ist selber Schuld. Wenn man einen Handwerker bestellt, schaut man auch vorher, was er schon gemacht hat und was er kann, und lässt sich ein Angebot geben!

Gruß,

ueps

[Cybaer]

Hi,

Doch, natürlich kann man das. Allerdings dann nur mit dem jeweiligen Neuladen des Dokuments.
Und dann ist es keine flüssige Applikation mehr!

Logisch. :-)

Wer das *will*, der *braucht* JavaScript (oder Java).

Aber *müssen* muß man *nicht*! :)

Und überhaupt: Wer redet denn von JavaScript bei komplexen Anwendungen?
Ich,

Jetzt erstmals. =:-)

Ich zitiere Dich: "Umgesetzt ... mittells ... JavaScript, gestützt von einer Serverseitingen Sprache ..."

Was da JS, was ASP & Co. machen sollen, ist hier nicht definiert - und, mit Verlaub, auch je nach Sinn/Notwendigkeit/Fähigkeit zu handhaben!

oder wie willst du oben genannte, Applikations Funktionalität, in eine Webseite integrieren? Ich rede nicht von einer simplen Shop Seite, sondern von einer Anwendung wie z.B. ein ERP System wie SAP!

Wieso willst Du die Funktionalität denn auf dem Client haben? Es spricht nichts dagegen, sie auf einen schnellen Server mit einer schnellen Anbindung zu verlagern (das brauchst Du für SAP ohnehin - obwohl es sich bei der Client-Software um Standalone-Software handelt 8->). Für das komfortable GUI und eine Server-Entlastung (wo immer es geht) sorgt gerne browserübergreifendes JavaScript. Und auf dem Server kannst Du alles machen, in allen Programmiersprachen.

Soll sich die "komplexe Anwendung" (z.B. aus Gründen der CPU-Performance) unbedingt auf dem Client-Rechner befinden, dann nehme man halt Java & JavaScript.

Das klassische "Net-Client"-Schema geht jedoch von einem möglichst schlanken Terminal mit einem möglichst fetten Server aus - selbst mit Java-Programmen). Wird Java verwendet, dann sollten allerdings, wie jetzt, die Clients über viel Rechenleistung verfügen (oder eine "Java-CPU"). Das hat dann immer noch gewisse Vorteile (z.B. gute Aktualisierung, weil GUI & Applets ja jeweils vom Server geholt werden und dort gepflegt werden können), aber es ist nicht die allein-seligmachende Variante.

Und daß ein beliebiges Java-Applet weniger performant sein soll, als eine beliebige SAP-Software, halte ich für ein Gerücht. Für beide kann ein Client gar nicht genug Rechenleitung haben! >;->

Wer solche "Profis" angagiert ist selber Schuld. Wenn man einen Handwerker bestellt, schaut man auch vorher, was er schon gemacht hat und was er kann, und lässt sich ein Angebot geben!

ACK.

Allerdings: Wer das im Zweifel wirklich beurteilen kann, der braucht keinen Profi, der hat schon einen! ;-)

Gruß, Cybaer

[uepselon]

Hi,

Ich zitiere Dich: "Umgesetzt ... mittells ... JavaScript, gestützt von einer Serverseitingen Sprache ..."

Was da JS, was ASP & Co. machen sollen, ist hier nicht definiert - und, mit Verlaub, auch je nach Sinn/Notwendigkeit/Fähigkeit zu handhaben!

OK, evtl. habe ich mich da etwas unklar ausgedrückt. Die Logik also, alles was mit viel Performance, DB Zugriffen zu tun hat, liegt auf einem Server und dieser stellet Web Services bereit.

Der Client, soll nun anhand dieser Web Services, eine Applikation darstellen. Mit Kontextmenü, Tastatur Short-Cuts, Sortierbaren Tabellen, spaltenweise modifizierbaren Tabellen, etc.

Sprich das Aussehem (Verpacken) der Daten geschieht auf dem Client.

Jetzt war meine grundsätzliche Frage, wie geschickt man sowas macht? Entweder per HTML, bzw. DHTML, oder per Java Applet?

Wobei ich die Schächen von DHTML in diesem Fall größer sehe als die evtl. etwas rechenintensivere Applet Variante.

Einen Web Service aufzurufen geht z.B. in Mozilla und dem IE auf unterschiedlichem Wege. Und da fangen die Browserspezifischen unterschiede schon an, das Kostet doppelte Zeit.

Bei Java, muss nur ein JRE installiert sein und schon gehts in Mozilla und dem IE.

Und daß ein beliebiges Java-Applet weniger performant sein soll, als eine beliebige SAP-Software, halte ich für ein Gerücht. Für beide kann ein Client gar nicht genug Rechenleitung haben! >;->

Da stimme ich dir zu :-)

Allerdings: Wer das im Zweifel wirklich beurteilen kann, der braucht keinen Profi, der hat schon einen! ;-)

Hm, stimmt auch wieder.

Gruß,

ueps

[Cybaer]

Hi,

Sprich das Aussehem (Verpacken) der Daten geschieht auf dem Client.
Jetzt war meine grundsätzliche Frage, wie geschickt man sowas macht? Entweder per HTML, bzw. DHTML, oder per Java Applet?

IMHO kommt es drauf an. Da gibt es IMHO keine generelle "nur so und nicht anders"-Aussage. Wo soll die Web-Applikation laufen, laufen können, laufen müssen? Was soll überhaupt gemacht werden? Welche Datenmenge muß der Client bearbeiten (relativ wenig, z.B. Textdaten, oder relativ viel, z.B. Grafikdaten)?

Wobei ich die Schächen von DHTML in diesem Fall größer sehe als die evtl. etwas rechenintensivere Applet Variante.

Wobei die meisten (beliebigen) Browser JS (und damit DHTML) erlauben, Java aber nicht unbedingt (mangels Notwendigkeit). Ggf. ist, in Firmennetzwerken, JS aber auch prinzipiell aus Sicherheitsgründen verboten, während Java prinzipiell installiert ist (aus Notwendigkeit).

Und ohne JS ist ja immer noch ein (weniger komfortabler) Fallback mittels reinem HTML möglich.

Einen Web Service aufzurufen geht z.B. in Mozilla und dem IE auf unterschiedlichem Wege. Und da fangen die Browserspezifischen unterschiede schon an, das Kostet doppelte Zeit.

Also meine PHPs/Perls laufen problemlos "auf" Mozilla oder IE. ;-) Für eine serverseitige Sprache ist der Browser ohne Belang.

Meine PHPs/Perls funktionieren allerdings auch auf Serverseite system- und serverunabhängig (wenn auch ggf. dann mit einer kleinen, automatischen Fallunterscheidung, wenigstens bei Perl). *Mir* ist es also prinzipiell egal, mit welchem Browser ich online bin, wo ich online bin, und ob die Firma von heute auf morgen meint, den Webserver und/oder das OS des Servers zu wechseln.

Das sind auch Kriterien, die ich, bei jeder Vorstellung eines Leistungskatalogs von mir, nicht vergesse zu erwähnen ;-): Unabhängigkeit/Zukunftsicherheit

Bei Java, muss nur ein JRE installiert sein und schon gehts in Mozilla und dem IE.

Allerdings nicht irgendeine JRE, sondern eine passende. ;-)

Aber dann halt überall und nicht nur dort.

Bei einer serverseitigen Applikation ist es natürlich ggf. etwas einfacher, da nur die dort installierte Version von Relevanz ist.

Gruß, Cybaer

[uepselon]

Hi,

Einen Web Service aufzurufen geht z.B. in Mozilla und dem IE auf unterschiedlichem Wege. Und da fangen die Browserspezifischen unterschiede schon an, das Kostet doppelte Zeit.

Also meine PHPs/Perls laufen problemlos "auf" Mozilla oder IE. ;-) Für eine serverseitige Sprache ist der Browser ohne Belang.

Ich rede hier auch von einem Clientseitigen Aufruf der Web Services. So können im HIntergrund Daten nachgeladen werden, ohne die Oberfläche neu laden zu müssen, dass wird heute von manchen Unternhemen schon so gemacht. Allerdings gibt es bei der JavaScript abhandlung im IE und Mozilla, große Unterschiede. Im IE kann man mittels des behavior styles, ein Web Service Objekt "verfügbar" machen. Im Mozilla gibt es die ProxyFactory für JavaScript.

Meine PHPs/Perls funktionieren allerdings auch auf Serverseite system- und serverunabhängig (wenn auch ggf. dann mit einer kleinen, automatischen Fallunterscheidung, wenigstens bei Perl).

Die Serverseite sollte in diesem Fall auch nciht das Problem sein, sondern die verwendete Client, der die Daten nur visualisieren soll. Und das eben als Anwendung und nicht als HTML Seite. Der User sollte denken, er befindet sich in einer Applikation und genauso schnell und ohne Barrieren Arbeiten können, wie bei einer Standradanwendung. (In meinem speziellen Beispiel). Für Buchungssysteme oder Shops, mag ein HTML Client ausreichend sein.

Bei Java, muss nur ein JRE installiert sein und schon gehts in

Mozilla und dem IE.

Allerdings nicht irgendeine JRE, sondern eine passende. ;-)

Ja, aber da kann man in Java, dass für sich passende raussuchen. Es können auf einem System mehrere Versionen installiert werden und die Java App, sucht sich das Passende raus.

Bei einer serverseitigen Applikation ist es natürlich ggf. etwas einfacher, da nur die dort installierte Version von Relevanz ist.

"Meine" Applikation von der ich rede, ist sowohl Server- als auch Clientseitig. Sprich der Client kommt eigentlich auch vom Server, (Java Web Start, bietet da schöne update möglichkeiten). Die Logok ist serverseitig, die Visualisierung clientseitig.

Gruß,

ueps

[Cybaer]

Hi,

Ich rede hier auch von einem Clientseitigen Aufruf der Web Services.

Schon klar. Aber muß man ja nicht verwenden. :)

behavior styles

Auch nichts anderes, als verkapptes Scripting. Prinzipiell halte ich nichts von MS' proprietären Ausflügen. Daß der Komfort mit Sicherheitslücken (potentiell und tatsächlich) erkauft wurde, ist die eine Sache, daß man mit der Nutzung auf MS festgelegt ist eine andere.

Natürlich ist letzteres in MS' Interesse. In meinem nicht, weswegen ich stets eine universelle Lösung bevorzuge. (OK, auch ich muß gestehen ... ;))

Und was das Verhalten von Firmen angeht: Mir egal! Von mir aus kann jede Firma die auch ihre DHTML-Website auf "IE optimiert" und schicke Flash-Menüs in einen Frame ohne NOFRAMES packt auch sonst mit den Tools arbeiten, die sie verdienen! >:->

Ich werde gefragt, wenn jemand ein Problem hat und dies lösen möchte. Und solange ich das Problem "normal" lösen kann, verzichte ich auf proprietären Scheiß. Dafür gibt es das gute Gefühl, wenn/falls die Kunden mit der Zeit erkennen, wie flexibel und leistungsfähig ist, was sie da eingekauft haben, wo befreundete Firmen mit proprietären Lösungen bereits die Waffen gestreckt haben. Das muß natürlich nicht so sein, aber es passiert halt immer wieder ... 8-)

Die Serverseite sollte in diesem Fall auch nciht das Problem sein, sondern die verwendete Client, der die Daten nur visualisieren soll. Und das eben als Anwendung und nicht als HTML Seite.

In Browsern der 3. Generation kein Problem.

Der User sollte denken, er befindet sich in einer Applikation und genauso schnell und ohne Barrieren Arbeiten können, wie bei einer Standradanwendung. (In meinem speziellen Beispiel).

Sollte "normales" Look & Feel nicht ausreichen, dann bliebe noch CHM-Programmierung (halt speziell für den IE und für andere Browser eine Standard-Alternative). Das ließe sich im wesentlichen auch soweit modularisieren, daß a) sich der Entwicklungsaufwand nicht verdoppelt und b) der Anwender davon nichts merkt.

Für Buchungssysteme oder Shops, mag ein HTML Client ausreichend sein.

Ich sehe die einzige Einschränkung dort, wo wirklich große Datenmengen vom Anwender verarbeitet werden müssen. Der Rest obliegt, IMHO wie immer, der Phantasie und Kreativität des Programmierers.

Ja, aber da kann man in Java, dass für sich passende raussuchen. Es können auf einem System mehrere Versionen installiert werden und die Java App, sucht sich das Passende raus.

Jo.

"Meine" Applikation von der ich rede, ist sowohl Server- als auch Clientseitig. Sprich der Client kommt eigentlich auch vom Server, (Java Web Start, bietet da schöne update möglichkeiten). Die Logok ist serverseitig, die Visualisierung clientseitig.

Ist das eine theoretische Applikation, oder eine konkrete? Und welche, wenn man fragen darf?

Gruß, Cybaer

[uepselon]

Ich sehe die einzige Einschränkung dort, wo wirklich große Datenmengen vom Anwender verarbeitet werden müssen. Der Rest obliegt, IMHO wie immer, der Phantasie und Kreativität des Programmierers.

Und um solche Datenmengen geht es eben.

Ist das eine theoretische Applikation, oder eine konkrete? Und welche, wenn man fragen darf?

Eine konkrete Applikation, die auch schon so umgesetzt ist. Ich sag nur ERP System. Ich bin gerade dabei einen Vergelich zu anderen webbasierten ERP's zu machen, die meisten davon basieren eben auf DHTML Client's.

Gruß,

ueps

[Cybaer]

Hi,

Und um solche Datenmengen geht es eben.

Hmm, ich dachte da an Dinge, die auch was für Signalprozessoren wären (EBV, Video, ...). Aber was für große Datenmengen ...

Ich sag nur ERP System.

... müssen denn beim ERP bearbeitet werden? :-o

Kannst Du mal 'ne MByte-Größe nennen?

Ich bin gerade dabei einen Vergelich zu anderen webbasierten ERP's zu machen, die meisten davon basieren eben auf DHTML Client's.

Ah, deswegen der Schwerpunkt auf den Web Services?! :-)

Gruß, Cybaer

[Ludger]

Hi,

Wie gesagt bei komplexen Anwendungen musst dann JavaScript Code schreiben bis du schwarz wirst. Und das mit vielen Browserspezifischen unterschieden. Zeit ist halt nun mal Geld!

Geschaeftslogik mit ihrer Komplexitaet wird natuerlich serverseitig gehalten und ausgefuehrt. JavaScript ist eben immer als unsicher zu betrachten und optional zu nutzen (von Cheatah gelernt ;-).

Irgendwer hat hier mal etwas vereinfachend geschrieben, dass Webanwendungen im Grossen und Ganzen ueblicherweise ein DB-Frontend darstellen. Zumindest bei dem kommt man sogar ohne JavaScript aus.

Gruss,
Ludger

[Ludger]

Hi,

1. Wie wird erreicht, dass die Seite bei jeder Interaktion nicht neu aufgebaut werden muss? Im Internet Explorer ginge das ja über Web Service Calls (behavior:css->webservice.htc). Aber in Mozilla, Opera und Co?

der Nichtwiederaufbau einer Seite ist an und fuer sich erst einmal kein lohnenswertes Ziel.

2. Ohne JavaScript läuft nichts, und die Standard sind von Browser zu Browser ja immernoch unterschiedlich, oder liege ich da inzwischen Falsch?

Ohne JavaScript kann man sehr viel machen. Wenn man dann noch JavaScript optional nutzt...

Also liebe Forumsgemeinde, was haltet Ihr von solchen Anwendungen, bzw. wo seht ihr die Schwächen und Gefahren?

Man kann halt nicht alles machen. Ein Grafiktool per IE und ActiveX waere schon untauglich m.E.. Aber, wenns keine Spezialsoftware ist, dann ist die Webanwendung Standard. Gefahren sehe ich uebrigens nicht. ("Wer hat Angst vorm Internet?" "Ich nicht!")

Ich persönlich bevorzuge bei webfähigen Anwendungen eher die Java Applet Variante.

Schoen langsam. Aber alles Geschmackssache...

Gruss,
Ludger

[Dieter Raber]

Hallo Ludger,

Man kann halt nicht alles machen. Ein Grafiktool per IE und ActiveX waere schon untauglich m.E.. Aber, wenns keine Spezialsoftware ist, dann ist die Webanwendung Standard.

An diesen Aspekt hatte ich in meinem Posting garnicht gedacht. Aber ich glaube, man kann, ohne sich auf's Glatteis zu begeben, behaupten, dass die ueberwiegende Anzahl von Webappliktionen in irgendeiner Art und Weise dazu dient, ein Frontend fuer Datenbanken bereitzustellen.

Gefahren sehe ich uebrigens nicht.

Die gibt's aber schon. Wenn ich mit meiner vorhergehenden Aussage Recht habe, sind natuerlich, entsprechend schlampige Programmierung vorrausgesetzt[1], Missbrauch der Daten Tuer und Tor geoeffnet.
[1] Wenn man sich hier geposteten Code anschaut, kann's einen manchmal ganz schoen grausen.

Gruß,

Dieter

[Christoph Zurnieden]

Hi,

p.s. was zur Hölle ist der Fehler im Forum: "Error not found: de_E_unid_long" kommt bei mir ständig und ist recht nervig! Muss jedesmal über einen Proxy posten!

Diese Fehlermeldung kommt nicht vom Forumscode.Ich nehme an, das es sich um eine deutsche (de_) Fehlermeldung (E_) eines unidentifizierten (unid_) Integerwertes (long) handelt. Wo der herkommt sagt Dir eine Suche in Deinem Betriebsystem.

so short

Christoph Zurnieden

[uepselon]

Hi,

Diese Fehlermeldung kommt nicht vom Forumscode.Ich nehme an, das es sich um eine deutsche (de_) Fehlermeldung (E_) eines unidentifizierten (unid_) Integerwertes (long) handelt. Wo der herkommt sagt Dir eine Suche in Deinem Betriebsystem.

Doch der Fehler kommt von Forum, jedenfalls steht er da wo z.B. der Fehler steht, wenn kein Name beim neuen Posting angegeben wurde! Und das lässt die Vermutung nahe, dass der Forums-Code wohl den Fehler dahin setzt, oder? ;-)

Geh ich über einen web-proxy auf die Seite, geht es komischerweise. Also mag das Forum meine Adresse, bzw. meinen Clinet wohl nicht.

Gruß,
ueps

[Christoph Zurnieden]

Hi,

Diese Fehlermeldung kommt nicht vom Forumscode.Ich nehme an, das es sich um eine deutsche (de_) Fehlermeldung (E_) eines unidentifizierten (unid_) Integerwertes (long) handelt. Wo der herkommt sagt Dir eine Suche in Deinem Betriebsystem.

Doch der Fehler kommt von Forum, jedenfalls steht er da wo z.B. der Fehler steht, wenn kein Name beim neuen Posting angegeben wurde! Und das lässt die Vermutung nahe, dass der Forums-Code wohl den Fehler dahin setzt, oder? ;-)

Ja, hast Recht, mein Fehler, hatte falsch gesucht (nur nach de_E_unid_long, nicht auch noch nach Teilen). Äußerst peinlich, 'tschuldigung.

Aber immerhin war meine Beschreibung fast korrekt ;-)

Geh ich über einen web-proxy auf die Seite, geht es komischerweise. Also mag das Forum meine Adresse, bzw. meinen Clinet wohl nicht.

Der verlorengegangene Fehlertext sollte wohl "E_unid: Die Daten scheinen manipuliert worden zu sein..." lauten. Was also läuft da schief? Gute Frage. Im Bugtracker war schonmal auf die Schnelle nichts zu finden.

so short

Christoph Zurnieden

[uepselon]

Hi,

seit heute geht es komischerweise wieder! Bis gestern, war es seit ca. 2 Wochen nicht möglich, direkt zu posten. Zumindest für mich nicht :-(

Gruß,

ueps