# Java 6 und Web 2.0



## miketech (16. Feb 2006)

Hi zusammen,

nun da die erste Beta von Java 6 (Mustang) erschienen ist, liest man ja eine ganze Menge über die neuen Funktionen in Java 6, insbesondere fällt einem immer wieder der Begriff Web 2.0 auf.

In den Artikeln heißt es, dass man nun Java mit allen möglichen Skriptsprachen (PHP, Perl, Ruby usw.) kombinieren kann und das Entwickeln von Webservices vereinfacht wurde. Inwiefern nun noch zusätzlich Ajax integriert wurde, weiß ich nicht. Aber weiß jemand näheres dazu? Gibt es irgendwo Beispiele, wo man sich mal anschauen kann, wie diese Integration von PHP usw. aussehen soll? Heißt es, dass ich meine View in PHP schreiben kann und im Hintergrund ein Java Programm stehen habe? Und inwiefern sind nun Webservices leichter zu entwickeln?

Ich finde hierzu irgendwie keinerlei Tutorials, oder Beschreibungen, was in Java 6 auf diesem Gebiet nun groß anders ist. Da mich Java insbesondere auf der Server Seite immer interessiert würde ich mich freuen, wenn mir jemand dazu mehr sagen könnte, oder vielleicht ein paar informative Artikel hat (Vielleicht mit ein paar Beispielen).

Da es sich ja bereits um eine Beta handelt und Java 6 Q3 2006 erscheinen soll, müsste ein Großteil ja bereits implementiert sein und daher auch ein paar Tutorials oder Beispiele existieren.

Gruß

Mike


----------



## thE_29 (16. Feb 2006)

Warum sollten Tutorials und Bsp existieren wenn die Beta erst gerade erschienen ist??


Also kein Mensch hatte die Sprache (außer ein paar) um irgendwas vorzubereiten und glaubst du ernsthaft das Tutorials oder Bsp innerhalb von 1em Tag entstehen?


----------



## AlArenal (16. Feb 2006)

@miketech:
Warum kommt eigentlich kaum einer auf die Idee beim Hersteller nachzuschauen? Wenn ich ne Betriebsanleitung oder sonstige Infos zu einem Produkt suche, ist das doch wohl das Naheliegendste der Welt, oder?

*Java SE 6: Mustang*
*Object Computing has a useful introductory article on Scripting Support in Mustang [Feb 7, 2006]*
JSR 270: JavaTM SE 6 ("Mustang")
Desktop Java Features in Mustang
Core Java Technology Features in Mustang

Das mit den Skriptsprachen bezieht sich auf eine Schnittstellen-Infrastruktur zur Integration von Skriptsprachen auf Basis der VM. Derzeit gibts ja eine ganze Armada davon, wie z.B. BeanShell, Jython, JRuby und Groovy, wobei letztere es zum JSR geschafft hat und dann wohl mal Einzug in ein zukünftiges Java-Release halten wird.

Wie du jetzt auf AJAX kommst, erschließt sich mir gerade nicht, denn AJAX ist größtenteils eine JavaScript-basierte Client-Technologie (*A*synchronous *J*avascript *a*nd *X*ML).

@thE_29:
Natürlich gibts auch zur Beta bereits eine ganze Menge Artikel und Tutorials. Da Mustang ja ein öffentliches Projekt ist, gabs schon immer ne Menge Tester, Mitentwickler und Interessierte. Außerdem hat Sun natürlich ein Interesse daran, dass die Entwickler auch in der Lage sind die neuen Features zu nutzen und sich nicht alles selbst aus den JavaDocs suchen und rumpfriemeln zu müssen.


----------



## thE_29 (16. Feb 2006)

Aso, das war offen 

Dachte es ist erst jetzt offen rausgekommen ^^


Und das Sun ein paar Tuts bereitstellt ist klar, ich meinte eigentlich andere Tutorials, aber die könnten natürlich auch da sein, da es ja offen ist


----------



## byte (16. Feb 2006)

> Heißt es, dass ich meine View in PHP schreiben kann und im Hintergrund ein Java Programm stehen habe?



Was hätte ich denn davon? Ich sehe den einzigen Vorteil in PHP darin, dass die PHP Hosting Angebote günstiger sind als bei Java Servern. :roll: Wenn ich eh schon nen Java Server habe, wüsste ich nicht, warum ich noch PHP einsetzen möchte, es sei denn ich habe noch ein proprietäres PHP-Skript rumfliegen, das ich nicht portieren möchte.


----------



## miketech (16. Feb 2006)

Hallo,

also auf AJAX komme ich daher, weil mit Java 6 häufig der Begriff Web 2.0 fällt, den ich direkt mit AJAX verbinde. Dass es sich dabei lediglich um JavaScript handelt ist klar, aber derzeit müsste man das alles per Hand programmieren. Ich dachte es gäbe dann irgendwelche neuen Methoden, um so etwas zu automatisieren. 

Vielleicht hat schonmal jemand mit ASP.NET programmiert. Ich persönlich finde ja den Ansatz sehr nett, dass ich eine View habe und dazu ein Codebehind, wobei die Datei denselben Namen hat nur mit ".cs" am Ende. Und dann kann ich einfach mit Methoden wie OnLoad(..), die z.B. beim Laden der Seite aufgerufen wird die Inhalte der Seite festlegen, da ich die Komponenten direkt ansprechen kann. Das scheint bei Java ja mit JSP und JSF auch irgendwie möglich zu sein.

Was mir nun fehlt ist die Integration in Eclipse. Gibts da irgendwie etwas, dass ich dort meine View schreibe und dann automatisch das Codebehind vorbereitet wird und ich nur noch Methoden füllen muss? Ich möchte kein Servlet programmieren, sondern einfach nur Methoden wie OnLoad(..) usw. schreiben müssen.

Ich finde die Webentwicklung mit Java im Vergleich zu einem ASP.NET Projekt mit Visual Studio sehr umständlich, aufgrund fehlender Funktionalität in Eclipse. Aber vielleicht kann mir jemand ja dazu ein paar Tipps geben.

Dann werde ich mir mal die Artikel von Sun anschauen. Muss zugeben, dass ich da tatsächlich nicht direkt dran gedacht habe, weil die Artikel meist sehr umfangreich sind und ich mir dann unter der Beschreibung selten was vorstellen kann  Aber ich schaus mir mal an.

Gruß

Mike


----------



## byte (16. Feb 2006)

Stimmt schon, ASP.NET mit Visual Studio ist schon ne komfortable Sache, aber dafür bezahlst Du dann auch erstmal entsprechendes Geld. Das selbe kannst Du mit Java auch machen, brauchst dann halt die entsprechenden Plugins für Eclipse, wie Lomboz oder WTP, kannst dann komfortabel in Java entwickeln ohne teure Lizenzen bzw. Server Kosten.

Aber das hat jetzt eigentlich wenig mit Java 6 zu tun.


----------



## miketech (16. Feb 2006)

Stimmt schon  Danke aber für die Links, in Kombination mit JSF scheint es stark in die Richtung zu gehen, was ich suche.

Gruß

Mike


----------



## AlArenal (16. Feb 2006)

Hier herrscht wohl allgemeine Begriffsverwirrung. Java hat auch weiterhin nichts mit JavaScript (Basis für AJAX) zu tun und die Möglichkeiten von Eclipse in Standardausführung kontra Visual Studio .NET haben zunächst mal auch nix mit Java 6 zu tun, denn Java 6 ist nicht gleich Eclipse 3.x. Das eine ist ne Sprache mit VM und Lib und das andere ist ne IDE und Plattform.

Hier heißt es "Nachsitzen und büffeln!"


----------



## miketech (16. Feb 2006)

Oh hier ist wohl fälschlicherweise der Eindruck entstanden, dass das missverstanden wurde )

Der Übergang: Java 6 -> In Artikeln häufig Web 2.0 erwähnt -> Ajax (JavaScript) und Webservices -> ASP.NET -> Visual Studio 2005 -> Eclipse.

So könnte man den Übergang schildern, von Gleichheit war jetzt gar nicht die Rede.  Dass Java 6 nichts mit ASP.NET, Eclipse, oder JavaScript zu tun hat ist klar. Aber da in den Artikeln häufig von Web 2.0 die Rede ist, was widerrum in anderen Artikeln häufig mit Ajax verknüpft wird, war die Frage, was Java 6 nun mit Ajax zu tun hat, ob es da irgendwelche neuen Möglichkeiten für Webanwendungen gibt Ajax einfacher einzusetzen.

Gruß

Mike


----------



## byte (16. Feb 2006)

Vielleicht sollte man erstmal klären, was mit Web 2.0 gemeint ist. Der Wiki Eintrag dazu ist etwas... komisch. :roll:


----------



## AlArenal (16. Feb 2006)

AJAX ist clientseitiges JavaScript - Punkt. Was hat Java mit clientseitigem JavaScript zu tun? Genau.. nüscht. Was soll nun also Java 6 speziell mit AJAX zu tun haben? Einzige Verbindung ist, dass man mit JAVA Serveranwendungen stricken kann und auf die kann man dann mit AJAX zugreifen. Toll.. und?

Vielleicht bin ich ja auch blöd...


----------



## miketech (16. Feb 2006)

Hi,

naja ich dachte so in Richtung JSP. Dass es da nun neue Möglichkeiten gibt, dass man den JavaScript Kram für Ajax nicht per Hand schreiben muss.

Gruß

Mike


----------



## Bleiglanz (17. Feb 2006)

AJAX

der gleiche alte Scheiss in neuer Verpackung

vor ein paar Jahren war schon ein leichter Konsens in Richtung

"DHTML und Javascript lieber weglassen"

zu spüren, und an und für sich hat sich daran nichts geändert. Die von allen gewünschte 100%-Cross-Browser-fähige DHTML/Javascript Bibliothek ist nie geschrieben worden, was wohl ein Grund fürs Scheitern von DHTML "im Grossen" war.

Jetzt plötzlich tun alle so, als ob das anders wäre und die 100 neuen Frameworks, die "FAST" alle Browser unterstützen tatsächlich alle Probleme lösen

Das einzig wirklich neue an AJAX (das man aber vor 5 Jahren auch schon hätte machen können, nur hats Google jetzt mal richtig eingesetzt), ist die Verwendung von asynchronen HTTP-Aufrufen aus Javascript heraus und die Darstellung des Resultats über Javascript-DOM-Manipulationen. Irgendwie finde ich das ganze etwas gaga (untestbar, kompliziert, Javascript dabei...) aber höhere Benutzerfreundlichkeit schlägt wohl alles 

Viele der Frameworks versprechen wohl, dass man "kein Javascript von Hand schreiben muss", aber ob das wirklich so stimmt???


----------



## AlArenal (17. Feb 2006)

Sehe das recht ähnlich, ohne mich groß praktisch damit auseinandergesetzt zu haben. Die Erhöhunhg der Anwendungskomplexizität, die stark erschwerte Fehlersuche, die nicht 100%ige Browser-Kompatibilität, die Untestbarkeit und der damit einhergehende erhöhte Entiwcklungs- und Wartungsaufwand wiegen m.E. auch schwerer als der zusätzliche Nutzen auf Anwenderseite.

Alleine wenn ich als Gedankenspiel so ne Anwendung entwickle, bekomme ich das Grausen und das obwohl ich Client-Anwendungen mit Anbindung über XML-RPC entwickle. Der ganze verzogene HTML-/DHTML-/DOM-Kram liegt doch arg schwer im Magen.


----------



## Bleiglanz (17. Feb 2006)

jep, ich wills noch nicht mal ausprobieren...

irgendwie wiederstrebt es mir schon, in einem CSS Stylesheet die blöden IE-Hacks mit einzubauen, auch wenn das nur "Kosmetik" ist - irgendwie hässlich, sowas sollte nicht sein

aber das ganze jetzt auf "Applikationsebene" auch mit einem riesigen Javascript-Gewimmel aufzuziehen, wie konnte das nur zu einem "Hype" werden??


----------



## stev.glasow (17. Feb 2006)

Wieso ist das untestbar?
Die Idee, dass ich die Daten asynchron nachladen kann find ich eigentlich recht geil und Teile in Javascript zu schreiben würde mich auch nicht stören. Problem ist halt nur dass ich immer eine nicht Javascript fähige Version parallel laufen lassen müsste. Zecks google und Leuten die JavaScript aus irgendwelchen Gründen deaktiviert haben.
Mich würde auch mal intessieren wie die Lösungen zwecks Bookmarks und  Browser-Zurückbutton ausehen und zu handhaben sind.
Also ich werde es bei Zeiten zumindest mal ausprobieren.


----------



## Bleiglanz (17. Feb 2006)

stevg hat gesagt.:
			
		

> Wieso ist das untestbar?



Na ja, bisher konnte ich bei einem Servlet z.B. automatisiert nachprüfen, ob bei verschiedenen Eingaben immer z.B. XHTML rauskommt. Das ist natürlich ein gaanz grober Test, aber was willst du machen wenn die Seite jetzt in einem Client Browser wild mit JS/DOM manipuliert wird

Zehn Hausfrauen mit fünf verschiednen Browsern hinzusetzen die wild umherklicken ist KEIN SoftwareTest, und IMHO leider die einzige Möglichkeit um eine AJAX Anwendung zu checken

Dazu kommt, dass das "asynchrone" Nachladen serverseitig auch allerhand Kopfzerbrechen erzeugen dürfte...

Google kann das natürlich alles machen, ist eben auch eine Frage des Geldes...


----------



## AlArenal (17. Feb 2006)

Ist ein Hype für Entscheider. Das Fußvolk, dass den Kram entwickeln muss, ist da völlig außen vor und darf zusehen, wie es klarkommt....

Dummerweise neigen Entschieder dazu Annahmen zu treffen wie "Wenn es einfach zu bedienen ist und nett ausschaut, isses sicher auch einfach zu entwickeln..."


----------



## Bleiglanz (17. Feb 2006)

http://www.aventureforth.com/2005/09/06/top-10-ajax-applications/

in meinem Firefox 1.5.0.1/Linux haben gleich zwei dieser top10 den ganzen Browser eingefroren

und teilweise ist JS doch etwas langsam, so richtig flutschen tun diese Anwendungen auch nicht unbedingt


----------



## AlArenal (17. Feb 2006)

Und was passiert wenn aus Sicherheitsgründen JavaScript deaktiviert ist?


----------



## Bleiglanz (17. Feb 2006)

gute Entwickler werden in dem Fall natürlich eine Javascript-Weiche einbauen und das ganze serverseitig nochmal implementieren

ist ja nix dabei 

Widerspricht ausserdem dem obersten AJAX Gebot "Javascript ist NIE deaktiviert"


----------



## stev.glasow (17. Feb 2006)

Bleiglanz hat gesagt.:
			
		

> stevg hat gesagt.:
> 
> 
> 
> ...


Klar auf die Weise geht das dann nicht, aber meinst du nicht dass da was in Zuknuft für angeboten wird. Schleißlich kann ich ja auch Swing Anwendungen halbwegs testen.

Und ich würde erstmal abwarten und schauen wie sich das ganze entwickelt, als dem Kind zu sage wie dumm es eigentlich ist.


----------



## byte (17. Feb 2006)

Abgesehen davon gibts aber schon sinnvolle Einsatzgebiete von JS, z.B. das Prüfen von Formularen auf korrekte Eingaben. Da ist es imo sinnvoll, wenn das schonmal clientseitig abläuft, damit man damit den Server im Zweifel erst gar nicht belasten muss und somit unnötigen Datenaustausch minimiert. Die Prüfung muss natürlich serverseitig trotzdem nochmal passieren, falls JS (berechtigterweise) (semi-)deaktiviert ist.

Schlimmste JS-Sünde imo: Automatisches Maximieren des Browserfensters... wie ich sowas hasse! :autsch:


----------



## miketech (17. Feb 2006)

Hi,

also ich persönlich finde den Ansatz von Ajax recht gelungen. Natürlich gibt es noch so die ein, oder anderen Probleme. Nicht jeder hat JavaScript aktiviert und noch nicht alle Browser kommen damit klar. Aber durch steigende Verbreitung von Firefox und Co wird es hier vielleicht bald so sein, dass IE und Firefox noch kompatibler werden.

Der Begriff Web 2.0 trifft das ganze eigentlich ganz gut. Aber es dauert eben bis alle nachgezogen sind und es überall so läuft, wie man es sich gerne wünscht. Sicher ist es noch langsam und noch nicht völlig ausgereift. Aber wie war das z.B. mit CSS? Das war doch auch absolutes Chaos, aber mittlerweile haben sich die Browser weitestgehend angenähert, solange man kein allzu exotisches CSS verwendet. 

Zum Entwickeln: Vielleicht kann man wirklich irgendwann davon ausgehen, dass es überall funktioniert und man nicht immer eine Non-JavaScript Version entwickeln muss. Wie war das, als die Leute noch mit Netscape 4, oder Lynx unterwegs waren. Da musste man immer schauen, dass man kein CSS verwendet, oder vielleicht noch nichtmal Frames, oder sonst was. Oder eine Version mit und ohne Frames. Mittlerweile haben sich hier andere Möglichkeiten durchgesetzt.

Gerade große Unternehmen werden Ajax immer weiter pushen und Basics lassen sich mittlerweile sehr bequem verwenden, ohne JavaScript selbst schreiben zu müssen. Wie das in Java funktioniert weiß ich nicht, aber in RubyOnRails z.B. kann man Ajax ohne viel Mühe einsetzen. Man muss ja auch nicht unbedingt Fenster durch die Gegend fliegen lassen, manchmal ist es schon genug, dass man ein paar asynchrone Calls absenden kann und vielleicht irgendwelche Bereiche der Webseite ändern kann, ohne die Seite neu laden zu lassen.

Und zum Testen: Das mit dem Testen gestaltet sich natürlich sehr kompliziert, je nachdem wie aufwendig man Ajax einsetzt. Aber wie gesagt bin ich der Meinung, dass man es einfach nicht übertreiben muss und sich vielleicht auf einige Kleinigkeiten beschränkt. Und vielleicht finden sich irgendwann irgendwelche Testframeworks mit denen man zumindest einige Bestandteile prüfen kann. Aber ich finde eh, dass man den JavaScript Code nicht selbst schreiben sollte, sondern auf Funktionen zurückgreifen sollte, die einem das ganze vereinfachen.

Gruß

Mike


----------



## Bleiglanz (17. Feb 2006)

gerade beim Testen von Formulareingaben ists doch sowieso kacke, weil diese aus Sicherheitsgründen sowieso am Browser nochmal voll durchgecheckt werden müssen

-> eine reine Mehrarbeit nur damit sich der Benutzer einmal das Abschicken ersparen kann

Aber um den Fans mal recht zu geben: sobald die erste 100% Cross-Browser-DHTML/AJAX Bibliothek verfügbar ist mach ich bei dem Hype mit! Ehrlich!!



> Aber wie war das z.B. mit CSS? Das war doch auch absolutes Chaos, aber mittlerweile haben sich die Browser weitestgehend angenähert, solange man kein allzu exotisches CSS verwendet.


Bullshit, der IE wird seinen Box-Fehler bis auf weiteres eingebaut lassen, schon allein damit die "alten" Seiten weiter gut ausschauen


----------



## byte (17. Feb 2006)

Bleiglanz hat gesagt.:
			
		

> -> eine reine Mehrarbeit nur damit sich der Benutzer einmal das Abschicken ersparen kann



Nein, sondern um den Server und den Datenaustausch zu entlasten.


----------



## stev.glasow (17. Feb 2006)

Einiges ist ohne Javascript auch einfach gar möglich, siehe Google Maps oder das Ding von Microsoft.

Naja ich werd das im Auge behalten, mal sehen was sich damit in Zukunft so machen läßt. Unabhänig von dem angesprochenen Hype.


----------



## byte (17. Feb 2006)

Und einiges, was JavaScript erst möglich macht, ist einfach nur endnervig für die Benutzer, z.B. alles was das Erscheinungsbild des Browsers ansich verändert. Warum deaktivieren denn so viele JS im Browser? Sicher nicht, weil das Preloading von Bildern in Internetseiten nervt.


----------



## stev.glasow (17. Feb 2006)

jo, aber ich würde trotzdem nicht die Vielfalt der Möglichkeiten als negatives Argument sehen.


----------



## Bleiglanz (17. Feb 2006)

Wie gesagt, wenn die Toolbox mal so ausgereift ist dass man das machen kann - OK

aber hier mal ein einfacher Fall

Benutzer will sich registrieren

Bisher: am Server schnell schauen, ob die Kombination Benutzername+Passwort schon vorhanden und entsprechende HTML Seite zurück an Client

AJAX: eine reine Mehrarbeit, da obiges ja trotzdem passieren muss: Mit Javascript die Formulareingaben in einem Handler auslesen, einen asynchronen Aufruf machen, serverseitig eine Komponente schreiben die das ganze als XML oder sonstwie zurückschickt, diese antwort wieder in einem Handler abfangen, auslesen und das DOM entsprechend manipulieren

Und was passiert bei wüstem Klicken auf Reload, Forward, Back im Browser??

Ich habe eben irgendwie das Gefühl, dass das Umsetzen von Teilen der sogenannten Businesslogik in Javascript einfach ein Haufen Arbeit ist...


----------



## stev.glasow (17. Feb 2006)

Stimmt schon, aber ajax sehe ich nicht als eine Alternative zu herkömlichen Lösungen sondern als Erweiterung. Ich würde auch nicht anfangen ganze Projekte so zu realisieren. Bei ajax denke ich mehr an Livestatistiken, die immer aktuelle Darstellung von Aktienkursen oder daran dass ich nicht ständig die Seite neuladen muss um zu gucken ob nen neuer Beiträge zu einem bestimmten Thread im Forum gemacht wurde. 
Das sind jetzt Beispiele, die mir auf die schnelle eingefallen sind. Es gibt bestimmt noch bessere (besonders weil meine alle mit dem automatischen Nachladen von Daten zu tun haben, ohne dass der User was tut), aber die Richtung sollte klar sein.
[edit]
Und zu dem Reload, Forward, Back im Browser Problem soll es schon Lösungen geben, aber keine Ahnung wie die Ausehen und wie gut die sind.


----------



## AlArenal (17. Feb 2006)

Vielleicht kann man sich ja demnächst in den Browser einklinken und den Druck auf die Browsernavigation abfangen oder sperren.


----------



## byte (17. Feb 2006)

Oder Hintergrund und Theme des Desktops ändern, damit es dem Corporate Design der Seite entspricht.


----------



## stev.glasow (17. Feb 2006)

Hm?


----------



## AlArenal (17. Feb 2006)

byto hat gesagt.:
			
		

> Oder Hintergrund und Theme des Desktops ändern, damit es dem Corporate Design der Seite entspricht.



*gröhl*


----------



## stev.glasow (17. Feb 2006)

AlArenal hat gesagt.:
			
		

> byto hat gesagt.:
> 
> 
> 
> ...


Find das dämlich. Was hat das damit zu tun? 
Wenn der Button gesperrt und abgefangen wird, muss das natürlich schon vernünftig gemacht werden. Am besten so das der User gar nichts von mit bekommt und den Anschein das er wirklich zurück geht, durch irgendwelche Ajax internen Callbacks oder so.
Vielleicht ist es ja auch gar nicht so gelöst. Schon mal dran gedacht?


----------



## Ontos (19. Feb 2006)

Moin Moin



			
				Bleiglanz hat gesagt.:
			
		

> Bisher: am Server schnell schauen, ob die Kombination Benutzername+Passwort schon vorhanden und entsprechende HTML Seite zurück an Client
> 
> AJAX: eine reine Mehrarbeit, da obiges ja trotzdem passieren muss: Mit Javascript die Formulareingaben in einem Handler auslesen, einen asynchronen Aufruf machen, serverseitig eine Komponente schreiben die das ganze als XML oder sonstwie zurückschickt, diese antwort wieder in einem Handler abfangen, auslesen und das DOM entsprechend manipulieren


Stimmt. Nur ist es imho bei Ajax so das nur eine kleine Message gesendet werden muss an den Client (Login OK oder false) und nicht eine ganze neue Seite wie bei PPH.



			
				Bleiglanz hat gesagt.:
			
		

> Ich habe eben irgendwie das Gefühl, dass das Umsetzen von Teilen der sogenannten Businesslogik in Javascript einfach ein Haufen Arbeit ist...



Ich habe eher Bedenken bezüglich den Sicherheitsüberprüfungen. Alle Daten die von den Clients kommen sind als nicht sicher zu betrachten. Viele Coder werden eine Menge Logik in den Client stecken => Logik muss von PHP nachgebildet werden und alle Berechnungen und Rechnungen überprüft und nachvollzogen werden können. Logik muss an zwei Stellen in zwei Sprachen vorliegen! => Never ever!
Oder liege ich damit komplett daneben?

cu Jens


----------



## SnooP (19. Feb 2006)

Naja - da steckt dann ja wieder die Mehrarbeit weswegen ich das auch wiederum schwachsinnig finde... die Tendenz geht numal in Richtung Thin-Clients. Ne Technologie die wieder Clientseitig ansetzt ist da doch wieder doof. Allerdings gibt es sicherlich Szenarien für Interaktionsmöglichkeiten die Clientseitig besser aufgehoben sind und dort auch sinn machen - aber in dem oben beschriebenen Szenario des Informationsaustauschs zwischen Client/Server macht das imho halt keinen Sinn... es birgt wie du auch schon sagtest die Gefahr der fehlenden Sicherheitsüberprüfungen - nach dem Motto... wer schaltet schon Javascript aus... oder Hacker? Gibts sowas noch?


----------



## byte (19. Feb 2006)

Ich halte mich lieber an die Technologien, die auf den Empfehlungen der W3C basieren. Gerade in Sachen Web sollte man sich an offene und unabhängige Standards halten. Sonst hat man irgendwann ein heiloses Durcheinander. Browser A unterstützt nur X und Y. User B wiederum hat Z deaktiviert. Grausam!


----------



## AlArenal (19. Feb 2006)

byto hat gesagt.:
			
		

> Ich halte mich lieber an die Technologien, die auf den Empfehlungen der W3C basieren. Gerade in Sachen Web sollte man sich an offene und unabhängige Standards halten. Sonst hat man irgendwann ein heiloses Durcheinander. Browser A unterstützt nur X und Y. User B wiederum hat Z deaktiviert. Grausam!



Das bringt dir nur in dem Maße was, wie die Browser diese follrn Empfehlungen auch vollständig, korrekt und einheitlich unterstützen. Genau das ist doch die Crux seit Jahr und Tag...


----------



## byte (19. Feb 2006)

Ja, aber je mehr Leute sich an die Standards halten, umso größer wird der Druck bei den Browser-Herstellern, diese Standards auch zu 100% zu unterstüzen.


----------



## Ontos (19. Feb 2006)

Moin Moin



			
				byto hat gesagt.:
			
		

> Ja, aber je mehr Leute sich an die Standards halten, umso größer wird der Druck bei den Browser-Herstellern, diese Standards auch zu 100% zu unterstüzen.


Das ist ja grade das Problem! Im Bereich Webdesign wird oftmals nicht nach dem Standard codiert sondern nach dem was die Browser anzeigen könne und viele Webseiten sind nur eine Mischung aus Hacks für den IE, für den FF usw. Mehr Fehlerumgehung als alles andere.

cu Jens


----------



## AlArenal (19. Feb 2006)

Genau so siehts aus. Deine Kunden wollen, dass die neue Seite supidoll für das Groß der Surfer wird. Keiner sagt "okay, dann eben keine schicken Features, aber Hauptsache standardkonform".


----------



## byte (19. Feb 2006)

Mir ist das schon klar, dass sich die meisten gerade _nicht_ an die Standards halten. Aber _ich_ versuche halt lieber, die Anforderungen so gering wie möglich zu halten. Ich orientiere mich lieber an den Standards, und wenn diese nicht komplett von allen Browsern unterstützt werden, dann muss ich mir wohl oder übel den kleinsten gemeinsamen Nenner suchen.

Nur weil 80% der Internetseiten scheisse sind, heisst das ja nicht, dass ich auch ne scheiss Seite bauen muss.


----------



## AlArenal (19. Feb 2006)

Ist schon richtig, nur verdienen die wenigsten Leute ihr Geld damit ihre private Website zu basteln und in der Welt von Euro und Dollar hat der Kunde das Sagen.


----------



## byte (19. Feb 2006)

Wohl wahr. Trotzdem kann man doch seine eigene Meinung haben, anstatt seine Seele in neumodischer Söldnermanier meistbietend an den Javascript-Teufel zu verkaufen.  Und nicht jedes Unternehmen lässt seine Internetpräsenz aus Gründen der Coolness mit Javascript und Co. zusammenfrickeln.


----------



## AlArenal (19. Feb 2006)

Richtig, aber auch in dem Fall, dass jemand nichts klickibunti haben will, ist er womöglich nicht bereit für Standard-Konformität die ihm nichts bringt, mehr zu zahlen. Und wenn man einigermaßen gut ist, hat man nicht die Zeit kostenlos dem Kunden mehr zu geben, als er haben wollte.


----------



## AlArenal (22. Feb 2006)

Sun gewährt Einblick in Java EE 5



> Auch Sun setzt verstärkt auf AJAX (Asynchronous Javascript and XML) und unterstützt die Erzeugung entsprechender Web-Clients über JSF sowie Enterprise Javabeans (EJB) 3.0.



Der Link


----------



## Bleiglanz (22. Feb 2006)

Von mir auch noch ein Nachtrag:

Usabiltiy / Accesibility

War das nicht mal angedacht dass da härtere Regeln (zumindest für staatliche Websites) kommen sollten? Wie z.B. Blinde, die sich von PageReadern den ganzen Zeugs Vorlesen lassen mit AJAX klarkommen sollen ist mir ein Rätsel...


----------

