HTML-DOM manipulieren?

[Don P]

Hallo,

Bin absoluter Java-Anfänger, bzw. eignetlich erst Möchtegern-Anfänger, d.h. noch nicht mal blutig, weil ich erst ein bischen darüber gelesen habe, aber noch nichts wirklich selber programmiert.

Mein Anfänger-Frage:
Kann man mit einem Java-Applet problemlos den HTML-DOM-Baum manipulieren, also z.B. neue DOM-Elemente einfügen, löschen, Attribute setzen und dergleichen?

In JavaScript klappt das ja, aber bei Java bin ich mir nicht sicher. Immer wieder stoße ich auf sowas wie besondere Restriktionen für Applets, die so manches nicht tun dürfen.

Wo kann ich näheres über HTML-DOM-Manipulationen erfahren, wenn sie denn möglich sind? Beim Googeln bekomme ich nur spärliche Auskunft über XML-DOM, mich interessiert aber speziell das HTML-DOM im Zusammenhang mit Applets im Browser.

Danke und Gruß,
Don P

[Harlequin]

Yerf!

Mein Anfänger-Frage:
Kann man mit einem Java-Applet problemlos den HTML-DOM-Baum manipulieren, also z.B. neue DOM-Elemente einfügen, löschen, Attribute setzen und dergleichen?

Meine Erfahrungen mit Applets sind schon etwas her und eher begrenzt. Allerdings sind Applets recht abgeschlossene "Dinge" die nur über wenige Schnittstellen mit der restlichen Seite kommunizieren können. Ob dazu auch ein Zugriff auf das HTML-DOM gehört kann ich nicht sagen, aber es müsste zumindest ein "Brücke" zu JavaScript existieren, evtl. hilft die Weiter (z.B. die JS-DOM-Methoden benutzen).

Gruß,

Harlequin

[Alexander (HH)]

Moin Moin!

Meine Erfahrungen mit Applets sind schon etwas her und eher begrenzt. Allerdings sind Applets recht abgeschlossene "Dinge" die nur über wenige Schnittstellen mit der restlichen Seite kommunizieren können. Ob dazu auch ein Zugriff auf das HTML-DOM gehört kann ich nicht sagen, aber es müsste zumindest ein "Brücke" zu JavaScript existieren, evtl. hilft die Weiter (z.B. die JS-DOM-Methoden benutzen).

Das wäre auch mein Vorschlag. Java-Applets haben in verschiedenen Browsern (IE vs. FF vs. Opera) und mit verschiedenen JREs (MS vs. Sun) durchaus unterschiedliche Zugriffsmöglichkeiten. Mal kann man nur von JS aus auf Methoden des Applets zugreifen, mal kann man nur JS-Funktionen aufrufen (teilweise über Krämpfe wie openURL("javascript:foo('bar','baz')")), mal geht gar nichts. Dazu kommt, dass die MS-JRE richtig antik ist, und man sehr eingeschränkt wird. Und schließlich schalten viele Leute Java aus oder haben es gar nicht erst eingeschaltet.

Ich würde Java-Applets außerhalb einer kontrollierbaren Umgebung nicht einsetzen. Insbesondere zum Basteln mit dem DOM ist JS wesentlich besser geeignet.

Alexander

[Don P]

Hallo,

Ich würde Java-Applets außerhalb einer kontrollierbaren Umgebung nicht einsetzen. Insbesondere zum Basteln mit dem DOM ist JS wesentlich besser geeignet.

Es geht eher um eine kontrollierte Umgebung. Wer mein Programm nutzen möchte, muss dann halt einen kompatiblen Browser benutzen. Es ist ohnehin nur für eine überschaubere Zielgruppe interessant, für die das kein Problem sein sollte.

Eigentlich geht es um folgendes:

Eine umfangreiche, rechen- und datenintensive Javascript-Anwendung, deren Sourcecode ich nicht unbedingt herausgeben möchte, soll aber dennoch im Browser laufen. Ein Server wäre schnell überlastet, wenn mehrere Benutzer damit arbeiten wollten, denn es müssen jeweils u.a. mehrere zig tausend Arrays angelegt und ständig Daten berechnet und umhergeschoben werden. Allein das macht einen IE z.B. völlig ungeeignet – Der packt es einfach nicht...

Nun bin ich auf die Idee gekommen, zumindest einige Schlüsselobjekte und Methoden in ein Java-Applet zu kompilieren und von Javascript aus aufzurufen. Um auch den Zugang zum restlichen JavaScript-Code möglichst zu erschweren, dachte ich mir, dass man den vielleicht sozusagen durch die Hintertür erst über das Applet nachladen könnte. Dazu müsste das Applet aber z.B. ein <script>-Tag im HTML-DOM einfügen können. Alle anderen DOM-Operationen können mit JavaScript erfolgen.

Angenommen, das funktioniert – mit oder ohne Nachladen von JavaScript – würde durch die ständige Interaktion mit einem Applet die Perfomance des Programms leiden? JavaScript ist als Scriptsprache ohnehin nicht gerade pfeilschnell, daher wäre es nicht wünschenwert, wenn es durch Java noch weiter ausgebremst würde. Oder kann ich hoffen, dass die Anwendung dann sogar schneller läuft als in reinem JavaScript?

Danke und Gruß, Don P

[Alexander (HH)]

Moin Moin!

»» Ich würde Java-Applets außerhalb einer kontrollierbaren Umgebung nicht einsetzen. Insbesondere zum Basteln mit dem DOM ist JS wesentlich besser geeignet.

Es geht eher um eine kontrollierte Umgebung.

Nö, wohl nicht. Kontrollierte Umgebung in diesem Zusammenhang ist eine Monokultur aus Maschinen mit geringer Hardware-Auswahl, einheitlichem Betriebssystem, einheitlichem Browser, einheitlichen Einstellungen, Software-Verteilung, und vor allem unprivilegierten Benutzern, die nicht ständig an den Maschinen herumkonfigurieren können. Also das, was man typischerweise in einer Firma mit einer durchsetzungskräftigen IT-Abteilung findet.

Wer mein Programm nutzen möchte, muss dann halt einen kompatiblen Browser benutzen.

Oder aber er sch***t drauf und sucht sich einen anderen Anbieter, dessen Angebot mit dem Browser des Besuchers funktioniert.

Es ist ohnehin nur für eine überschaubere Zielgruppe interessant, für die das kein Problem sein sollte.

Hoffst Du.

Eigentlich geht es um folgendes:

Eine umfangreiche, rechen- und datenintensive Javascript-Anwendung, deren Sourcecode ich nicht unbedingt herausgeben möchte, soll aber dennoch im Browser laufen. Ein Server wäre schnell überlastet, wenn mehrere Benutzer damit arbeiten wollten, denn es müssen jeweils u.a. mehrere zig tausend Arrays angelegt und ständig Daten berechnet und umhergeschoben werden. Allein das macht einen IE z.B. völlig ungeeignet – Der packt es einfach nicht...

Wenn Du -- nach eigener Aussage -- eine kontrollierte Umgebung hast, warum mußt Du dann unbedingt im Browser Datenmengen verarbeiten, mit denen der Browser nicht klarkommt? 10.000 Arrays für einen User klingt für mich nach einem völlig aus dem Ruder gelaufenen Projekt.

Warum willst Du in einer kontrollierten Umgebung den Quelltext nicht ausliefern? Warum kannst Du nicht einfach mit Hilfe der kontrollierten Umgebung eine dedizierte Client-Software verteilen? Ist Deine Umgebung vielleicht doch nicht so kontrolliert?

Nun bin ich auf die Idee gekommen, zumindest einige Schlüsselobjekte und Methoden in ein Java-Applet zu kompilieren und von Javascript aus aufzurufen.

Was versprichst Du Dir davon? Hoffst Du, dass die Java-VM um Zehnerpotenzen schneller ist?

Ein besserer Algorithmus oder optimierte Datenstrukturen kann Dir Zehnerpotenzen bringen, für den Wechsel von JS auf Java glaube ich das nicht.

Ich habe gerade für einen guten Kunden ein kleines, eigentlich triviales Perl-Script um den Faktor 20 beschleunigt. Unter anderem dadurch, dass ich die internen Datenstrukturen umgebaut habe, unnnötige Sortierungen rausgeworfen habe, und möglichst viel von den optimierten, schnellen Core-Funktionen erledigen lasse statt das Rad neu zu erfinden. Angesichts des kruden Algorithmus im Script gehe ich eigentlich davon aus, dass da noch reichlich Luft für weitere Optimierungen drin wäre, so dass das Script am Ende vielleicht 25x oder 30x schneller als das Original wäre. Aber für Faktor 20 werden Sie mir schon die Füße küssen. ;-)

Um auch den Zugang zum restlichen JavaScript-Code möglichst zu erschweren, dachte ich mir, dass man den vielleicht sozusagen durch die Hintertür erst über das Applet nachladen könnte. Dazu müsste das Applet aber z.B. ein <script>-Tag im HTML-DOM einfügen können. Alle anderen DOM-Operationen können mit JavaScript erfolgen.

Security by Obscurity funktioniert nicht. Wenn Du Code nachlädst, sehe ich das z.B. am Log eines zwischengeschalteten Proxy-Servers oder ganz einfach im Firebug, mit vollständiger URL, und, wenn ich will, mit Session Keys und Passworten. Egal ob Du XMLHttpRequest benutzt oder ein Script-Tag einbaust, egal ob aus Javascript, Java-Applet oder Flash.

Davon abgesehen gibt es für Java-Applets durchaus brauchbare Decompiler. Ich habe einen externen Mitarbeiter mal über die Schulter geschaut, als er ein fremdes Applet "mal eben" decompiliert, an unsere Bedürfnisse angepaßt und wieder compiliert hat -- alles an einem ganz entspannten Nachmittag. Der decompilierte Quelltext sah durchaus brauchbar und nachvollziehbar aus.

Deine Software ist jetzt schon offensichtlich an der Leistungsgrenze, die Komplexität scheint recht hoch zu sein, und sie scheint einige Anforderungen zu stellen. Darauf noch mehr Komplexität zu werfen und noch mehr Anforderungen zu stellen klingt für mich nicht sonderlich sinnvoll.

Angenommen, das funktioniert – mit oder ohne Nachladen von JavaScript – würde durch die ständige Interaktion mit einem Applet die Perfomance des Programms leiden? JavaScript ist als Scriptsprache ohnehin nicht gerade pfeilschnell, daher wäre es nicht wünschenwert, wenn es durch Java noch weiter ausgebremst würde. Oder kann ich hoffen, dass die Anwendung dann sogar schneller läuft als in reinem JavaScript?

Fange an zu messen, ganz klassisch mit der Stoppuhr. Ich denke, die meiste Zeit wird der PC darauf warten, dass der Benutzer etwas tut, egal ob du JS oder Java einsetzt.

Wahrscheinlich wäre es wesentlich besser, Du würdest Deine Software mal gründlich überdenken. Du sagst, sie sei sehr rechenintensiv. Kannst Du Dinge vorberechnen und bei Bedarf statt einer aufwendigen Rechnung einfach einen vorberechneten Wert vom Server laden? Kannst Du mit schneller berechenbaren Näherungen arbeiten? Mußt Du jedes mal mit 10.000 Arrays herumjonglieren oder könntest Du den Großteil der Daten erst "on demand" laden? Kannst Du einen schnelleren Algorithmus benutzen? Für mich klingen 10.000 Arrays irgendwie nach einer auf alle Clients ausgekippten Datenbank, in der die Clients von sich aus herumwühlen müssen. Das geht definitiv schneller auf einem optimierten RDBMS-Server.

Oder anders ausgedrückt: Erkläre uns Dein wahres Problem, statt an Symptomen herum zu quacksalbern.

Alexander

[Don P]

Hallo,

»» Es geht eher um eine kontrollierte Umgebung.

Nö, wohl nicht. Kontrollierte Umgebung in diesem Zusammenhang ist eine Monokultur aus Maschinen mit geringer Hardware-Auswahl [...]

Wow, dann ist es wohl alles andere als eine konrollierte Umgebung. Das hab' ich wohl ganz falsch verstanden.

»» Wer mein Programm nutzen möchte, muss dann halt einen kompatiblen Browser benutzen.

Oder aber er sch***t drauf und sucht sich einen anderen Anbieter, dessen Angebot mit dem Browser des Besuchers funktioniert.

Sicher nicht, denn es gibt keine anderen Anbieter. Was ich da habe, gibt es nicht mal annähernd mit dieser Funktionalität, kein Witz.

Natürlich könnte es jemand nachbauen, nachdem er es kennengelernt und verstanden hat. Aber ich will mich ja nur ein bisschen vor wildem Raubkopieren schützen. Wenn sich jemand die Mühe macht, das ganze zu hacken, zu decompilieren usw., nun denn... dann soll er wenigstens annähernd soviel Arbeit damit haben, wie ich aufwenden musste, um das Ding zu erstellen. Davor schrecken wohl die meisten zurück. Dann könnten sie's ja gleich selber machen oder halt die geringe Nutzungsgebühr bezahlen.

»» Es ist ohnehin nur für eine überschaubere Zielgruppe interessant, für die das kein Problem sein sollte.

Hoffst Du.

Da bin ich mir sehr sicher. Es sind Privatpersonen, die selber Herr über ihre Computer sind (hoffentlich), d.h. sie können sich jederzeit dafür entscheiden, einen Firefox, Opera oder Safari für diese Anwendung zu benutzen. Falls nötig, erkläre ich ihnen die Installation solcher Freeware.

warum mußt Du dann unbedingt im Browser Datenmengen verarbeiten, mit denen der Browser nicht klarkommt? 10.000 Arrays für einen User klingt für mich nach einem völlig aus dem Ruder gelaufenen Projekt.

Es sind sogar mehrere zig tausend, leider. Warum? Wegen der Optimierung: Alles, was zur Laufzeit schon irgendwie vorausberechnet sein kann und zur Verfügung stehen muss, liegt auch bereits fertig da, und wegen des unkomplizierten Zugriffs über Array-Indizes sind es eben Arrays. Diese werden in recht kurzer Zeit (<1 Sekunde) gleich nach dem Laden auch von einem Client selbständig erstellt (außer vom IE, der stirbt fast daran), das ist also nicht das Problem, aber das ständige Abarbeiten der Arrays zur Laufzeit kostet eben...

Warum willst Du [...] den Quelltext nicht ausliefern?

Weil ich eine Gebühr für die Benutzung verlangen will.

Warum kannst Du nicht einfach [...] eine dedizierte Client-Software verteilen? Ist Deine Umgebung vielleicht doch nicht so kontrolliert?

Sie ist eben nicht so kontrolliert. Zuerst war das Ganze nur für mich selbst gedacht. Dehalb auch einfach nur JavaScript, so zur Übung. Nun ist es aber auch für andere interessant geworden, und ich will's halt weder verschenken, noch neu programmieren in C oder sowas (auch weil ich das gar nicht könnte).

Was versprichst Du Dir davon? Hoffst Du, dass die Java-VM um Zehnerpotenzen schneller ist?

Nein, es reicht völlig, wenn's zur Laufzeit nicht spürbar langsamer wird. Längere Ladezeiten sind zu verkraften, aber halt keine deutlichen Verzögerungen bei der Anwendung.

Ein besserer Algorithmus oder optimierte Datenstrukturen kann Dir Zehnerpotenzen bringen, für den Wechsel von JS auf Java glaube ich das nicht.

Zur Zeit ist so ziemlich das optimalste umgesetzt, was in JavaScript möglich ist, mit allen Tricks. Besser geht's kaum...

Ich habe gerade für einen guten Kunden [...] so dass das Script am Ende vielleicht 25x oder 30x schneller als das Original wäre. Aber für Faktor 20 werden Sie mir schon die Füße küssen. ;-)

Gratuliere! So muss es sein.

Security by Obscurity funktioniert nicht. Wenn Du Code nachlädst, sehe ich das z.B. am Log eines zwischengeschalteten Proxy-Servers oder ganz einfach im Firebug, mit vollständiger URL, und, wenn ich will, mit Session Keys und Passworten.

Mit Passworten? Donnerwetter. Hast *du* etwa den Bundestrojaner programmiert? ;-)
Ich dachte da z.B. an vom Server vergebene einmalige Dateinamen, die z.B. per AJAX ausgehandelt werden und dach dem Download sofort wieder ungültig sind.

Deine Software ist jetzt schon offensichtlich an der Leistungsgrenze, die Komplexität scheint recht hoch zu sein, und sie scheint einige Anforderungen zu stellen. Darauf noch mehr Komplexität zu werfen und noch mehr Anforderungen zu stellen klingt für mich nicht sonderlich sinnvoll.

Für mich auch nicht wirklich. Aber probieren will ich es trotzdem mal... Wenn's nichts wird, bin ich wenigstens reicher an Erfahrung :-)

Ich denke, die meiste Zeit wird der PC darauf warten, dass der Benutzer etwas tut, egal ob du JS oder Java einsetzt.

So ist es. Aber nicht immer. Die Anwendung kann auch sebständig mit größeren Datenmengen arbeiten, die der Benutzer auf einmal füttert. Ohne Zweifel werden aber manche Portionen à 10 Millionen Datensätze reinstopfen wollen, und das kann dann schon dauern, bis die vom Programm verarbeitet sind :-(.

Wahrscheinlich wäre es wesentlich besser, Du würdest Deine Software mal gründlich überdenken. Du sagst, sie sei sehr rechenintensiv. Kannst Du Dinge vorberechnen und bei Bedarf statt einer aufwendigen Rechnung einfach einen vorberechneten Wert vom Server laden?

Wie gesagt, das ist so ziemlich alles schon gemacht. So 10'000 Datensätze in 3 Minuten, schneller geht's zur Zeit nicht. Ein Server kann nicht helfen, weil alle Berechnungen zur Laufzeit erfolgen müssen. Es ist zwar keine Spieleanwendung, aber so ähnlich kann man es sich vorstellen: Laufend müssen neue Daten verarbeitet werden, die sich immer wieder neu erst zur Laufzeit ergeben.

Mußt Du jedes mal mit 10.000 Arrays herumjonglieren oder könntest Du den Großteil der Daten erst "on demand" laden?

Die müssen immer zur Verfügung stehen. Jeders neu reinkommende Datum muss mit allen abgeglichen werden. Mit Client-Server Verkehr jedesmal wird das nichts.

Kannst Du einen schnelleren Algorithmus benutzen?

Ja vielleicht... Einer schwebt mir noch vor, der die Sache evtl. wesentlich beschleunigen könnte. Das ist intellektuell aber nicht einfach zu hinzubekommen. Ich müsste ein geeignetes Näherungsverfahren für bestimmte Zugriffe finden, um schneller an manche Daten zu kommen, die zur Zeit noch schrittweise durchgekämmt werden. Eine relationale Datenbank könnte da vielleicht helfen, aber das kann ich ja vom Client nicht verlangen, und wenn dazu immer Anfragen beim Server nötig werden, ist der Perfomance-Gewinn im Eimer...

Oder anders ausgedrückt: Erkläre uns Dein wahres Problem, statt an Symptomen herum zu quacksalbern.

Das wahre Problem: Ich müsste alles in einer andern Programmiersprache umsetzen, in C oder C++ oder am besten in Assembler ;-). Da ich aber schon über 1 Jahr daran arbeite und nur Scriptsprachen beherrsche, wäre mir das einfach zu aufwändig. Manchmal muss man halt Kompromisse eingehen.

Danke jedenfalls für deine Anregungen!

Ich denke mal, meine Chancen stehen gar nicht so schlecht, dass ich das mit ein bisschen Java zum Laufen bekomme, mal sehen...

Gruß, Don P

[Thomas J.S.]

Hallo,

Mein Anfänger-Frage:
Kann man mit einem Java-Applet problemlos den HTML-DOM-Baum manipulieren, also z.B. neue DOM-Elemente einfügen, löschen, Attribute setzen und dergleichen?

Man kann, es kommt darauf was du machen willst.

Hier die Beschränkungen für Applets:
http://java.sun.com/docs/books/tutorial/deployment/applet/security_practical.html

In JavaScript klappt das ja, aber bei Java bin ich mir nicht sicher. Immer wieder stoße ich auf sowas wie besondere Restriktionen für Applets, die so manches nicht tun dürfen.

Wo kann ich näheres über HTML-DOM-Manipulationen erfahren, wenn sie denn möglich sind?

die Java "Package org.w3c.dom" macht das möglich:
http://java.sun.com/javase/6/docs/api/org/w3c/dom/package-summary.html

Aber eher LiveConnect ist eigentlich was du suchst, http://javascript-workshop.de/buch/12.html
https://developer.mozilla.org/en/LiveConnect

https://jdk6.dev.java.net/plugin2/liveconnect/

Aber unter Umständen ist JavaFX was für dich:
http://www.javafx.com/

Grüße
Thomas

[Don P]

Hallo Thomas,

Wow, da hab' ich ja eine Menge Lesestoff, vielen Dank!

Freut mich zu hören, dass DOM-Manipulationen möglich sind. Mal sehen, was sich alles machen lässt...

Gruß, Don P