Frage zu Same Origin Policy
- Ersteller bis
- Erstellt am
ein schlauer
Lounge-Member
Ich versteh das Problem nicht. Wenn du deinen localhost aufrufst:
http: //localhost
Bekommst du HTML (und meinetwegen JS), dann kannst du dort, ohne irgendeine Einschränkung, JS Code einbinden
<script src="http: //serverB/src.js" type="text/javascript"></script>
Das machen viele, die z.b. jquery direkt von einem zentralen google Server in ihre Hompage einbinden.
Oder hab' ich etwas missverstanden?
http: //localhost
Bekommst du HTML (und meinetwegen JS), dann kannst du dort, ohne irgendeine Einschränkung, JS Code einbinden
<script src="http: //serverB/src.js" type="text/javascript"></script>
Das machen viele, die z.b. jquery direkt von einem zentralen google Server in ihre Hompage einbinden.
Oder hab' ich etwas missverstanden?
dass will er aber nicht(warum auch immer, ist eigentlich schon wegen der performance günstiger). er will den statischen teil für alle user ins netz auslagern und den dynamischen teil über requests an den lokalen server regeln.
Ich glaube schon, denn es soll ja exakt andersrum sein:
1) Start von localhost in App mit Link auf Url auf Public Web-Server
2) Alles Html, Flash, JS nur vom Public Web-Server
3) Daten (Settings, States, Anwender-Daten) via Ajax von localhost in App
4) User Aktionen im Browser via JS an beide:
- für Content vom Public Web-Server
- für App-Aktionen via Localhost an Applikation
Wird naheliegend und logisch, wenn man sich den Browser völlig eingebunden in ein Fenster der Desktop-App vorstellt und genau das ist geplant, wobei der Browser seinen Content vom Public Web-Server holt.
Hab grad erst angefangen zulesen, aber es sieht so aus als sei CORS die Lösung.
Sweit mein Dank an alle, bes. an @hesst
Nachtrag:
Für mein "tolles" Smalltalk
gibt es eine Test-Software, völlig eingebunden, die ich auch nutze, mit der man quasi "von außen" durch Code oder auch durch Daten die App steuern kann.
Beispiel:
- User macht in der Hilfe im Browser eine Auswahl (z.B. in einer Hilfe oder Tutorial).
- Browser schickt Daten an App via Localhost
- diese (Aktions-) Daten hat sich der Browser evtl. zuvor von einem Web-APPLICATION-Server geholt (muß aber nicht)
- Test-Teil in der App öffnet bestimmte Menüs, gibt Daten ein und startet einen Job
- alles ausgelöst durch einen Klick des Benutzers in einer Hilfe oder Tutorial
- Versions-Daten und Einstellungen des Benutzers in seiner App werden berücksichtigt.
Das ist exakt wie in der Test-Software, nur das UI verlagert in einen Browser. Sollte eine Super-Hilfe und Tutorials ergeben.
Für mein "tolles" Smalltalk
gibt es eine Test-Software, völlig eingebunden, die ich auch nutze, mit der man quasi "von außen" durch Code oder auch durch Daten die App steuern kann.Beispiel:
- User macht in der Hilfe im Browser eine Auswahl (z.B. in einer Hilfe oder Tutorial).
- Browser schickt Daten an App via Localhost
- diese (Aktions-) Daten hat sich der Browser evtl. zuvor von einem Web-APPLICATION-Server geholt (muß aber nicht)
- Test-Teil in der App öffnet bestimmte Menüs, gibt Daten ein und startet einen Job
- alles ausgelöst durch einen Klick des Benutzers in einer Hilfe oder Tutorial
- Versions-Daten und Einstellungen des Benutzers in seiner App werden berücksichtigt.
Das ist exakt wie in der Test-Software, nur das UI verlagert in einen Browser. Sollte eine Super-Hilfe und Tutorials ergeben.
ich verstehe sowieso nicht ganz, wozu du überhaupt den lokalen web-server benötigst. wenn du den browser in deiner app einbettest, kannst du diesen doch direkt steuern
![Junkee[]](/data/avatars/m/26/26576.jpg?1671603977){kind=avatar}
Junkee[]
Lounge-Member
Auch auf localhost muss ein Server laufen (ist meistens auch Apache).
soweit ich das verstanden habe, hat er den selber geschrieben oder anders gesagt,
seine app kommuniziert mit der gui über http.
das geht natürlich viel schneller über eine api
Unsinn!
Ich schrieb oben ausdrücklich, daß die Software der App einen eigenen Web-Server völlig integriert hat (in Smalltalk). Der kann zwar auch hinter IIS oder Apache laufen, kann aber auch völlig autark agieren. Für kleine Datenmengen und z.B. einen Benutze an Localhost ist das völlig ok, hier aber eher nicht (Flash Filme etc)r
Das ist eine (wahrscheinlich eher seltene) Besonderheit von Smalltalk und eröffnen eine Menge neuer Möglichkeiten. Ist aber leider im Vergleich zu Apache langsam bei großen Datenmengen.
Nein, nicht selbst geschrieben. In Smalltalk gibt es eine ungeheuer große Menge an Objekt-Bibliotheken. Das Stichwort zum gurgeln hier ist "Swazoo". So heißt dieser Web-Server. Damit arbeitet z.B. das Web-Server Framework in Smalltalk namens Seaside. Man stelle sich vor: Eine PHP-Umgebung völlig in einer mächtigen, rein o-o Hochsprache.
Und damit eben mit der App-Logik eine Einheit.
Auch nicht (noch nicht), obwohl das hier ein Ziel ist, d.h. der Browser soll für bestmmte Teile der Anwendung das GUI übernehmen, hier aber mit Zugriff auf den Public Web-Server. Als Konsequenz ist alles, was ich mit Ext JS für Netz/Intranet/Browser an GUI entwickle, ebenfalls sofort Teil der Desktop-Applikation, wobei es durch das Einbinden des Browsers in App-Fenster für den Benutzer total so wirkt und er den Browser als solchen gar nicht mehr sieht.
Die Desktop-App kann, dank integriertem Web-File-Server (Swazoo) und dank des integrieten Web-App-Servers (wie aber nicht Seaside) den Browser als GUI der App treiben, obwohl es technisch "nur" ein normaler Browser ist. Oder z.B. im LAN sogar hybrid via Localhost und auch andere Web-Clients.
Klaro?
Zuletzt bearbeitet:
Der Localhost (inside der App) sitzt logisch zwischen der App-Logik und dem Browser. Irgendwie muß der Browser ja sein DOM bekommen. Das "kann" die App nicht selbst. Die kann auch nicht per se mit dem Browser kommunizieren.
Dafür braucht es Swazoo als Web-Server und teilweise so etwas wie Seaside als Web-App-Server (beides inside Smalltalk, aber logisch als Aufsatz der App).
Wir haben die Controller (die das UI steuern) so aufgebaut, daß sie mi geringen Änderungen sowohl das interne UI als auch ein DOM unterstützen. das ist höchste Re-use von Objekt-Klassen. Die Modelle sind sowieso zu 100% identisch. Nur halt die Views anders. MVC wie es in Smalltalk vor >30 Jahren erfunden wurde als noch niemand an JS oder Java dachte. Ein wenig Werbung muß sein.
Gruß
egal, dann halt als externe lib eingebunden
das ist doch aber der browser als HTML-View auch. also kannst du mit diesem direkt reden
dagegen habe ich auch nichts gesagt, wenn mir auch die gründe nicht ganz klar sind.
bei einer hilfe würde mir noch die aktualität/update möglichkeit einleuchten. das war es aber auch schon.
ist halt arschlangsam, für ne hilfe aber ok
also ein normaler html-view nur mit kommunikation über http und datenhaltung/oberflächenlayout auf einen webserver
Ich wüßte nicht, wie ich aus der App das DOM des Browsers ansprechen sollte. Über COM-Interface geht das nur bei IE (mache ich eh in dieser App aber andersrum zum Auslesen des DOM) und das ist langsam.
Ist aber auch egal. So sollte es laufen, wenn das mit dem CORS so implementiert werden kann. "Es kann" sicher, ob ich es kann muß ich rausfinden.
Hilfe (mit States und Rückkoppelung in die App - siehe oben) ist nur der erste Teil. Da gibt es 1001 mehr Möglichkeiten.
Pardon, aber ich stehe ungeheuer unter Zeitdruck, wenn ich der allgemeinen Diskussion nicht mehr so folgen kann.
@hesst
Danke noch mal!
keine ahnung, wie das in st funktioniert. wenn das nicht geht, gut, ist aber ein nicht zu vernachlässigender performanceverlust
Über COM treibt meine App komplett einen IE. Geht leider nur mit IE und der hat große Memory-Probleme. Damit liest die App ganze Domains aus und in ihre DB ein. Ist aber langsam. Aber ein DOM so komplett aufzubauen, das wäre extrem aufwendig, theoretisch möglich aber m.E. großer Unsinn. Das kann EXT JS viel besser und schneller.
Und damit mutiert die App zu einer Einheit aus App, WebFileServer und WebAppServer.
Und damit mutiert die App zu einer Einheit aus App, WebFileServer und WebAppServer.
Es gibt einige sehr gute Gründe, warum ich das nicht machen werde. Nur einer: Die Hilfe wird eine eigene App werden (in der selben Technologie), sie wird aber auf/als Web-Server laufen. Es gibt nur Nachteile, das in jede Applikation zu integrieren und diese selbst "native" den Browser füllen zu lassen.
Technisch möglich, gerade mit Stmalltalk, aber nicht alles, was möglich ist, ist auch sinnvoll.
Pardon, wirklich keine Zeit mehr...
warum soll das langsammer sein, als die domain im browser selbst zu öffnen. das hat ja nichts mit COM zu tun, damit stosst du den ladevorgang ja nur an.
das was da zeit frisst, dürfte die http-kommunikation und das abfüllen der db sein.
hähh? du musst dem document doch nur eine html seite vorwerfen.
die html seite muss ja nicht statisch sein, sondern kann EXT JS zum aufbau nutzen
auch wenn das gut klingt, muss es nicht gut sein