Java 6 und Web 2.0

[miketech]

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]

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]

@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 (Asynchronous Javascript and XML).

@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]

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]

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]

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]

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]

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]

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]

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]

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

 

[AlArenal]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

 

[Bleiglanz]

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]

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.

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]

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]

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]

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]

-> 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]

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]

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]

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

 

[Bleiglanz]

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]

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]

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

 

[byte]

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

 

[stev.glasow]

Hm?

 

[AlArenal]

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

*gröhl*

 

[stev.glasow]

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

*gröhl*

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]

Moin Moin

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.

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]

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]

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]

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]

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]

Moin Moin

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]

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]

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]

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]

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]

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]

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]

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...