Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
mit dem Feature von Java 7 Update 51, dass selbstsignierte Applets blockiert werden, stellt sich mir die Frage, wie ich diese Blockade umgehen kann, wenn sich alles in einem lokalen Netzwerk abspielt.
Der Server, von dem ich das Applet lade, befindet sich also auch im LAN, und somit dürfte das Applet auch ohen Zertifikat vertrauenswürdig sein.
Gibt es für den Fall, dass der Server, von dem ich ein selbstsigniertes Applet lade, sich im LAN befindet, Möglichkeiten, die Blockade im Browser zu unterbinden (z.B. beim Deployment, ...)?
Von "Siteliste bearbeiten ..." in der Systemsteuerung bin ich nicht begeistert, da hierbei immer noch bei jedem Start des Applets eine Sicherheitswarnung erscheint.
Außerdem hat nicht jeder Benutzer die benötigten Rechte für diese Einstellung.
Ja, die selbe Frage stellt sich mir auch. Zusätzlich wäre noch meine Frage, wie ich ein Applet ordentlich signieren kann, sodass es auf meiner https Seite keine Sicherheitswarnung mehr hervorruft. Es besteht ein Comodo Zertifikat. Die Benutzer haben die Seite in den vertrauenswürdigen Seiten und im Java Control Panel in der Ausnahmeliste. Dennoch erscheint eine Sicherheitswarnung. Was kann man tun?
Scheidet aus, weil der Benutzer ja nicht bei der Arbeit gestört werden soll. Wenn er gerade in Word einen Brief tippt darf ihm die Erinnerung nicht den Cursor weg reißen. Das wird ihn bald so sehr stören, dass er es nicht mehr nutzt.
Der Benutzer ist froh, wenn er weiß, wie die Kiste an geht. Und das ganze soll ohne großen Support funktionieren. Die window.open Idee fällt ganz raus. Alle Browser bis auf IE haben default eine Popupblocker drin.
Du hast versprochen, dass es schöne Lösungen gibt, dann zeig jetzt bitte auch mal eine.
Scheidet aus, weil der Benutzer ja nicht bei der Arbeit gestört werden soll. Wenn er gerade in Word einen Brief tippt darf ihm die Erinnerung nicht den Cursor weg reißen. Das wird ihn bald so sehr stören, dass er es nicht mehr nutzt.
Der Benutzer ist froh, wenn er weiß, wie die Kiste an geht. Und das ganze soll ohne großen Support funktionieren. Die window.open Idee fällt ganz raus. Alle Browser bis auf IE haben default eine Popupblocker drin.
Du hast versprochen, dass es schöne Lösungen gibt, dann zeig jetzt bitte auch mal eine.
Das hat doch alles seine Gründe. Ich hasse es, wenn mir Fenster beim arbeiten aufpoppen - ob die jetzt den Focus klauen oder nicht.
HTML kann einen Ton abspielen und Notifications anzeigen, was sogar schöner ist als ein fenster, meiner Meinung nach.
In dem Anfangs-Post stand doch etwas von einem Fenster, dass sich öffnet? Dass man mit JavaScript nicht auf die Tray zugreiffen kann ist klar (und auch gut so).
Was spricht denn dagegen, eine eigentsändige Java-Anwendung zu machen welche sich die Anwender herunterladen können? Die kann alles (und noch mehr), was das Applet auch kann. Und obendrein werden die Nutzer weiterhin alarmiert wenn sie den Kalender ausversehen schließen.
Das war anfänglich vielleicht etwas unscharf formuliert. Obwohl es auch gern ein Fenster hätte sein dürfen, es darf nur dem Benutzer nicht den Cursor wegnehmen und ihn bei der Arbeit stören, ansonsten ist mir das Layout relativ egal.
Was spricht denn dagegen, eine eigentsändige Java-Anwendung zu machen welche sich die Anwender herunterladen können? Die kann alles (und noch mehr), was das Applet auch kann. Und obendrein werden die Nutzer weiterhin alarmiert wenn sie den Kalender ausversehen schließen.
Soweit es meine Anforderung betrifft hört sich das super an! Kann man durch das Downloaden den Sicherheitshinweis umgehen? Kann das Teil dann auch vom Browser aus gesteuert werden (das ist zwingend zwecks Kundenbindung an die Website)? Kann ich meinen bisherigen Applet Code verwenden (hab das jetzt schon bezahlt)? Würdest du mir dabei helfen?
Nicht direkt (also etwa so dass man per JS irgendwelche Befehle / Werte schicken könnte).
Aber was geht: Das Programm kann sich die Daten per JSON (oder XML, wies beliebt) vom server holen. Das Programm wird also nicht durch die Webseite sondern den WebServer dahinter gesteuert. Richtig implementiert funktioniert das wunderbar.
Dein Teil fürs anzeigen der Erinnerungen auf jeden Fall, da wird aber bzgl. der Kommunikation mit dem Server noch etwas an Code dazukommen (sowohl für das Programm als auch den Server).
Inwiefern? Du kannst deine Fragen gern hier im Forum stellen (natürlich sepearter Thread etc.) und ich bin sicher, dass dir die Community hilft (was mich mit einschließt)
Aber was geht: Das Programm kann sich die Daten per JSON (oder XML, wies beliebt) vom server holen. Das Programm wird also nicht durch die Webseite sondern den WebServer dahinter gesteuert. Richtig implementiert funktioniert das wunderbar.
Polling scheidet aus Trafficgründen aus. Bei vorgesehenen 400 Benutzern möchte ich nicht, dass 400 Clients dafür noch zusätzlich jede Minute gegen den Server pollen, das Gepolle merze ich an anderen Stellen auch gerade aus. Wie kann der Server mit dem Clientprogramm Kontakt aufnehmen, sobald eine Erinnerung angezeigt werden muss?
Die daten müssen ja nicht jede Minute geladen werden. Einen Termin legt man maximal 30 mintuen vor start fest, es reich also wenn die alle 20-25 Minuten pollen.
Und wenn nicht: du kannst auch einfach eine Verbindung mit dem Server offen halten (musst halt keep-alives senden weil sie sonst geschlossen wird). Dann kann der Server die sachen direkt schicken.
Die daten müssen ja nicht jede Minute geladen werden. Einen Termin legt man maximal 30 mintuen vor start fest, es reich also wenn die alle 20-25 Minuten pollen.
Und wenn nicht: du kannst auch einfach eine Verbindung mit dem Server offen halten (musst halt keep-alives senden weil sie sonst geschlossen wird). Dann kann der Server die sachen direkt schicken.
Das hört sich nicht gut an. Der Server killt lange Sitzungen trotz keepalive, daran kann ich nichts ändern. Wenn es keinen Weg vom Server zum Client gibt scheidet das leider aus.
Man kann sichs auch schwerer machen, als man muss...
Leztes angebot (funktioniert aber nur im LAN):
Jedes Programm registriert sich beim Server mit der IP des Rechners und Benutzername + Passwort. Das Programm macht dann auf einem festgelegten Port ein ServerSocket auf. Wenn der Server dem Programm änderungen / informationen / etc. zukommen lassen will verbindet er sich mit der [dem User zugewiesenen] IP und schickt die Sachen raus.
Dabei musst du aber höllisch aufpassen wegen sicherheit u.s.w. Nicht dass dann die ganze IT-Abteilung der Firma einsicht in die Termine von der Personalleitung hat. Das wäre - gelinde gesagt - unzuträglich für deine Karriere.
Na ja, ich hatte im Vorfeld schon einige Möglichkeiten geprüft, daher bin ich ja beim Applet. Das funktioniert ja auch super. Aber das Sicherheitspopup nervt halt. Obwohl es eine https Seite ist, sie als vertrauenswürdig im Browser steht und auch in der Java Console die Seite auf den Ausnahmen steht. Kann doch nicht sein, oder?