GoogleWebToolkit auf IIS?
-
Ich würde eine Anwendung mit dem GoogleWebToolkit realisieren wollen, hab dazu aber noch eine Frage: Ist der Output vom GWT überhaupt irgendwie auf einem IIS lauffähig? Es wird ja auch das Backend in gewisserweise erzeugt, in welcher Sprache ist das dann? Java?
MfG SideWinder
-
Der GWT Compiler übersetzt Java Code in JavaScript. Das kannst Du mit jedem Webserver deployen.
Remote Procedure Calls kommunizieren aber standardmäßig über Servlets mit einem Java Servlet Container (z.B. Apache Tomcat oder Jetty). Das wird auf nem IIS also nicht laufen. Es gibt aber noch weitere Möglichkeiten, z.B. über JSON. Insofern reicht auch ein JSON-fähiges Backend.
-
Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Webzeugs verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
byto schrieb:
Der GWT Compiler übersetzt Java Code in JavaScript. Das kannst Du mit jedem Webserver deployen.
Remote Procedure Calls kommunizieren aber standardmäßig über Servlets mit einem Java Servlet Container (z.B. Apache Tomcat oder Jetty). Das wird auf nem IIS also nicht laufen. Es gibt aber noch weitere Möglichkeiten, z.B. über JSON. Insofern reicht auch ein JSON-fähiges Backend.Das ganze irgendwie auf C# als Backend umzubiegen gibt es aber nicht soweit ich sehen kann, oder? Bzw. gibt's da Alternativen in diese Richtung?
Ich möchte eine Web-Applikation daraus machen und das ohne mich um XSS, SQL-Injection, Browser-Weichen, Session-Management, etc. etc. kümmern muss. Gibt's da nichts für ASP.NET? Das abstrahiert ja eh schon sehr gut, aber ich möchte das ganze noch etwas näher an der Desktop-Entwicklung haben.
MfG SideWinder
-
Jo, auch dafür hat Microsoft ne billige Kopie in petto, hab aber vergessen wie das heisst.
-
GWT mit anderem (d.h. nicht-Java Backend) ist kein Problem. Man muss nur schauen, dass man in seiner Backendsprache einen Connector für die RPC Aufrufe baut. Alternativ kann man im GWT selber einfache JSON/XML Webservices aufrufen, aber dann hat man nicht mehr die Aufrufstruktur von Google.
-
ASP.NET MVC ist doch ein Webframework mit klassischer Request-Response Architektur. Das hat imo wenig mit GWT gemeinsam.
Ein komplett in GWT geschriebener Client läuft ausschließlich als JS im Webbrowser und holt lediglich Daten asynchron im AJAX-Stil vom Server.
Headhunter schrieb:
GWT mit anderem (d.h. nicht-Java Backend) ist kein Problem. Man muss nur schauen, dass man in seiner Backendsprache einen Connector für die RPC Aufrufe baut. Alternativ kann man im GWT selber einfache JSON/XML Webservices aufrufen, aber dann hat man nicht mehr die Aufrufstruktur von Google.
Zumindest für ne Neuentwicklung halte ich es aber für wenig sinnvoll, den Client in Java (GWT) zu schreiben und den Server in einer ganz anderen Sprache. Anders siehts natürlich aus, wenn man bestehende Services weiternutzen will.
-
Volta heißt der direkte GWT Konkurrent - ist aber seit fast einem Jahr "temporarily not availible". Die ASP .NET MVC (was für eine Name) Bibliothek hat auch AJAX Libraries. Und zumindest unter ASP .NET gibt es auch AjaxPanels. Jede Komponente die dort platziert wird, kommuniziert fortan asynchron über die gewohnte Postbackstruktur. Ist zwar nicht das selbe wie GWT, kommt dem aber schon recht nahe vom Effekt her- einfache AJAX Entwicklung.
-
Naja, wenns danach geht ist jedes aktuelle Webframework "wie GWT". Für die herkömmlichen Java Webframeworks wie JSF, Spring MVC, Struts, Wicket, Seam usw. gibts auch AJAX Taglibs. Das ändert aber trotzdem nix daran, dass das MVC Konzept dieser Frameworks weiterhin auf konventionellem Request/Response basiert. Und genau das ist eben bei GWT grundlegend anders.