Slideshow Bob - Kommentare

derschreckliche: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (derschreckliche) — Tue, 20 Oct 2009 04:40:41 +0200

Hi Thomas,

hat diesmal etwas länger gedauert, aber ich habe was interessantes dazu gefunden und denke du könntest das auch sehr interessant finden.

Aber erstmal zu deinen Ausführungen:
Du hast vollkommen recht, dass die zugeordneten Ausdrücke natürlich von der Semantik her gleichwertig sein müssen, aber da ich ja versuche eine kontextfreie Sprache zu erzeugen muss ich erstmal sicherstellen, dass der entstehende Ausdruck wohlgeformt ist - also erstmal syntaktisch korrekt aufgebaut ist.
Das Problem ergibt sich, da man nicht eine "einfache" Sprache wie z.B. 3-Adress-Code verwendet, bei der es keine grammatikalischen Einschränkungen gibt, außer, dass es eine Sequenz von den zulässigen Befehlen ist.

Da wir aber in diesem Fall eine von einer kontextfreien Grammatik generierte Sprache als Zielsprache haben, unterliegt deren Syntax ja zwangsläufig der Grammatik und das will auch erst sichergestellt werden.
Zur Vedeutlichung: Angenommen wir habe für jede Regel eine "Entsprechung" in der Zielgrammatik gefunden. Dann ist noch lange nicht sichergestellt, dass die zugeordneten Regeln anwendbar sind. (Rein theoretisch könnte ich bspw. die Startregeln der Zielgrammatik einfach nicht zuordnen, wenn ich semantisch das Gleiche mit anderen Symbolen dartellen kann - somit keine korrekte Ableitung...)

Dass die Abbildung Unidirektional wäre ist an sich kein Problem, schließlich können sich die Sprachen ja in der Ausdrucksmächtigkeit ja unterscheiden, dann ist natürlich eine vollständige Abbildung nur in die mächtigere Sprache möglich.
Ich nehme an genau das hast du mit "...die Ausgangssprache sollte zumindest (von den Features her) eine Untermenge der Zielsprache sein..." gemeint.

Was die Literale/Keywords angeht geb ich dir selbstverständlich auch recht, die sind ja sprachspezifisch => bei der Generierung können ja die jeweils benötigten erzeugt werden.
Um die ging es mir aber gar nicht, bei der Wohlgeformtheit/syntaktischen Korrektheit. Um bei deinem Beispiel zu bleiben - ist glauch auch leichter nachzuvollziehen: Angenommen die Quellsprache(welche auch immer das ist) erlaubt IF_STMNT auch an Stellen, an denen es die Zielsprache( von mir aus Ruby) nicht erlaubt. Ich hätte dann zwar für jede Regel die eine Entsprechung, könnte den Ausdruck also übersetzen, dieser wäre aber nicht konform zur Zielgrammatik.
(Obwohl ich da grade Zweifel bekomme, ob die das IF_STMNT erzeugenden Regeln dann semantisch das gleiche bedeuten... hmmm??? werde es mir überlegen und einen weiteren Komment schreiben, sobalb ich was handfestes habe).

Kommen wir aber nun zu dem Paper, dass ich gefunden habe, das sich mit der Vollständigkeit von ähnlichen Transformationen beschäftigt:
"Completeness of Compositional Translation for Context-Free Grammars"
von Willem-Olaf Huijsen
http://arxiv.org/abs/cmp-lg/9607035

Er nutzt ein anderes (ursprüngl. linguistisches) Modell, wendet es dann aber auf die kontext-freien Grammatiken an und untersucht Bedingungen, unter denen eine vollständige Übersetzung nachweisbar möglich ist.
Hat mir sehr gefallen, deswegen wollte ich es dir nicht vorenthalten.

Einige deiner Ideen sind auch drin, so z.B. nur bestimmte Transformationen erlaubt und die (gemeinsame) Semantik bildet die Grundlage für die Übersetzung.

Einen riesen Dank dir nochmal für diese interessante und spannende Diskussion. Das ist ungemein hilfreich für ein tiefes Verständnis dieser, gerade am Anfang doch recht schwer verdaulichen Materie.

Greeeeeeeeeeeeeeetz

derschreckliche

Ralle: Scribblenauts - die Feder ist so mächtig wie eine Atombombe

nospam@example.com (Ralle) — Tue, 13 Oct 2009 09:49:46 +0200

Geil... bring das beim nächsten Kinobesuch mit.
Aber lass uns da was langweiliges gucken

Thomas Werner: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (Thomas Werner) — Mon, 12 Oct 2009 13:11:06 +0200

Hi Iwan,

jetzt hat's Klick gemacht und ich versteh, worauf Du hinauswillst mit dem formalen Beweis. Klar, im Rahmen von einer Bachelor-Arbeit ist das wichtig, ansonsten wird's ja unwissenschaftlich.

Im Wesentlichen würd's wohl darauf hinauslaufen aufzuzeigen, daß jede Regel aus der Quellgrammatik mindestens einen "Partner" in der Zielgrammatik hat, also die Transformation als surjektive Funktion.

Da man am Ende lauffähigen Code haben möchte, kann man da leider die semantische Seite nicht komplett außen vor lassen, denn an sich würde es ja ausreichen nur diese Partnerbeziehungen in der Transformation aufzuzeigen. Das würde allerdings voraussetzen, daß Quell- und Zielsprache nahezu identisch von ihren Features her sind und sich allenfalls in ein paar kleineren Feinheiten unterscheiden (wie fehlendes Semikolon am Ende einer Anweisung).

Angenommen die Quellsprache ist prozedural und die Zielsprache ausschließlich objektorientiert oder vielleicht sogar funktional oder logisch (oha!). Du müßtest also noch eine Menge an Zeug für die Zielsprache drumherumbasteln und beispielsweise für das Klassenkonstrukt der Zielsprache hättest Du keine Entsprechung in der Ausgangsgrammatik. Das bedeutet, daß die Transformation unidirektional wäre - was allerdings okay ist, denn das ist nun mal das, was man meistens auch bei Modelltransformationssprachen hinkriegt, auch wenn man sich gerne wünscht, bidirektionale Verfahren herzustellen.

Abhängig vom Paradigma einer Sprache passieren in der Laufzeitumgebung einige Sachen, die man nicht explizit programmiert - Objektinstanziierung, Vererbung, das Finden einer passenden Regel/Funktion sowie Backtracking bei logischen und funktionalen Programmiersprachen usw.
Das Transformationsverfahren müßte also ganz klar eingegrenzt werden: Ausgangs- und Zielsprache sollten also schon ein gemeinsames Paradigma teilen und über das gleiche Feature-Set verfügen, oder die Ausgangssprache sollte zumindest (von den Features her) eine Untermenge der Zielsprache sein - ansonsten beweist Du Dir wahrscheinlich noch nen Wolf.

Ich streu mal ein blödes Beispiel hier ein. Angenommen es gibt die Ausgangssprache A mit folgender Art von IF-Statement:

CODE:

if(a == true) print("blabla");

Die Entsprechung in der Zielsprache B würde so aussehen:

CODE:

print("blabla") IF a == true

Ich glaube die Sprache Ruby bietet optional eine solche Syntax.

Quell-Grammatik für das if-Statement:

CODE:

IF_STMNT -> 'if' '(' EXPR ')' STMNT

Ziel-Grammatik für das if-Statement:

CODE:

IF_STMNT -> STMNT 'IF' EXPR

Du hast die Grammatik der Ausgangssprache, die Grammatik der Zielsprache. Du weißt, was die jeweiligen Konstrukte machen, im obigen Fall sind sie für dieselbe Funktionsweise verantwortlich (das klarzustellen wäre wahrscheinlich sehr wichtig für den Beweis).

Meiner Meinung nach sind die Literale/Keywords hierbei unerheblich, es geht also nicht darum zu zeigen, daß das "if" aus A zum "IF" aus B wird, sondern lediglich darum, daß die beiden Regeln der Grammatik A sowie Grammatik B semantisch dasselbe sind und die bedeutsamen Teile, welche für die korrekte Funktionsweise des IF-Befehls vonnöten sind, ihren korrekten Platz in der Zielgrammatik finden.

Der Beweis würde sich also ausschließlich darum drehen, daß die semantisch bedeutsamen Teile (in dem obigen Beispiel die Nichtterminalsymbole EXPR und STMNT) in der Zielgrammatik durch die Transformation abgedeckt werden. Diese Elemente werden in der Ausgangsgrammatik gesucht, zwischengespeichert und im Rahmen der Transformation an ihre entsprechenden Plätze der Zielgrammatik eingebaut.

Aufgrund der möglichen Unterschiede in der Gestalt kann man wahrscheinlich einen formalen Beweis nicht weiter abstrahieren und auf eine kleine Menge an Sätzen reduzieren. Der Beweis müßte vermutlich für jede Regel der Ausgangsgrammatik erbracht werden.

Vielleicht fällt Dir ein Verfahren ein, bei der Du in einer Datenstruktur die semantischen Komponenten der Grammatik A auf die Komponenten der Grammatik B mappst und somit irgendwie automatisiert einen Transformationsalgorithmus die richtigen Entscheidungen treffen läßt. Das wäre elegant, aber nochmal ein ganz eigenes Thema auf Korrektheit zu beweisen.

derschreckliche: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (derschreckliche) — Mon, 12 Oct 2009 03:50:26 +0200

Hi Thomas,

danke für den Tipp mit "ecore", bin bei der Recherche da irgendwie nicht drübergestolpert.

Was das Validieren mit Hilfe von Tests angeht:
Klar, das würde natürlch gehen, ist aber dann keine formale Korrektheit.
(Ich schreibe gerade an meiner Bachelorarbeit und mein Prof. mag es gerne formal )

Zu deiner Aussage:
"Da Du in Deinem Algorithmus die Umwandlung selbst in der Hand hast, weißt Du ja im Vorfeld, daß das Resultat der gewünschten Zielsprache entspricht oder entsprechen sollte."
Genau zwischen dem "entspricht" und "entsprechen sollte" liegt ja der Unterschied .

Und zu:
"...weil Du ja die Zielgrammatik schon davor im Zwischenschritt bei der Generierung des Zielquelltexts angewendet hast..."
Genau da bin ich ja am grübeln. Habe ich das?
Wo genau mach ich das? Und wie?

Hier mal ein Paar meiner Überlegungen hierzu:

Die Transformationsfunktion würde jeder Regel der Ausgangsgrammatik eine "in sich konsistente"(was das bedeuten soll erkläre ich gleich) Folge von Konstruktionsregeln der Zielgrammatik zuweisen würde.
"in sich konsistent" soll hier heißen, dass der dabei konstruierte Teilbaum des Ziel-AST mit Hilfe der Regeln der Zielgrammatik gebildet wird.

Ein Beispiel für zwei solcher Regeln
( T sei die Transformationsfunktion,
A->bCd und C->efg seien Regeln der Quellgrammatik und
Regeln der rechten Seite, in den eckigen Klammern gehören zur Zielgrammatik.
In geschweiften Klammer die semantischen Aktionen hierzu.
Über .val wird auf die Werte zugegriffen
Verarbeitung Buttom-Up):

T(C->efgh) = [
Q->q { createNode(q, h.val); //Ergebnis wird oben auf den Stack gelegt.
createNode(Q, null); //Ergebnis wird oben auf den Stack gelegt.
stackTop.appendChild();//Darunterliegendes Element als Kind anhängen - 'q'
} ,
P->rs { createNode(r, concat(e.val, f.val)); //Ergebnis wird oben auf den Stack gelegt.
createNode(s, g.val); //Ergebnis wird oben auf den Stack gelegt.
createNode(P, null); //Erge...
stackTop.appendChild(); //Darunterliegendes Element als Kind anhängen - 's'
stackTop.appendChild(); //Darunterliegendes Element als Kind anhängen - 'r'
},
O->PQ { createNode(O, null); //Erge...
stackTop.appendChild(); //Darunte... 'P'
stackTop.appendChild(); //Darunte... 'Q'
} ,
]

T(A->bCd) = [
N->n{ createNode(n, b.val);
createNode(N, null);
stackTop.appendChild(); //Darunte... 'n'
} ,
M->O {
//--------------------------------------
//-- Ergebnis des vorherigen Transformationsschrittes (Reduktion zu 'C') liegt unterhalb von 'N' auf dem Stack. Wir hängen dieses an, indem wir stackTop.appendChild(2) aufrufen, also das zwiete Element unterhalb des stackTop an diesen anhängen.
createNode(M, null); //Erg....
stackTop.appendChild(2); //Erg. des vorh. Tra.fo.Schrittes anhängen - 'O'
//-------------------------------------
} ,
L->l { createNode(l, d.val);
createNode(L, null);
stackTop.appendChild(); //Darunte... 'l'
} ,
K->LMN { createNode(K, null);
stackTop.appendChild(); //Darunte... 'L'
stackTop.appendChild(); //Darunte... 'M'
stackTop.appendChild(); //Darunte... 'N'
}
]

Soviel zur "in sich konsistent" bzw. lokalen Korrektheit.
Jedoch kann ich ja nicht davon ausgehen, dass bei jeder Regel, in der nach 'C' reduziert wird auch ein 'O' erzeugt wird. Ich könnte ja auch eine Regel haben, bei der zu 'C' reduziert wird und dabei ein 'Z' und kein 'O' erzeugt wird... ?!?

Obwohl ich gerade eine Idee bekomme:
Ich könnte eine Art "look ahead" einbauen[= oberstes Element auf dem Stack], d.h.

T(QRegel) = switch("look ahead") { hier der Rest }

oder auch nur bei Regeln, die auf NichtTerminale zugreifen?
T(QRegel) = [...., //auf NT auf rechter Seite von QRegel zugreifende ZRegel
ZRegel{ switch ("lookahead") { hier der Rest } },
...
]

Somit könnte ich entscheiden, ob bei der letzten Reduktion ein 'O' oder ein(oder auch mehrere) 'Z' herausgekommen ist.
Solange ich das eindeutig Anhand des obersten Stackelementes, also einen "look ahead" von 1, bestimmen kann welche Elemente im Ziel-AST zu erstellen sind, dürfte das korrekt sein, solange ich fü jeden Fall eine Entsprechung in der Zielgrammatik finde, oder?

Was meinst du dazu?

Ich weiss, es ist etwas viel, sorry!
Ich dachte nur etwas Gedankenaustausch dazu kann sicherlich nicht schaden.

Greeeeeeeeeeeetz und danke nochmals für all die Ideen, Anregungen, etc.

derschreckliche

Thomas Werner: Scribblenauts - die Feder ist so mächtig wie eine Atombombe

nospam@example.com (Thomas Werner) — Sun, 11 Oct 2009 13:21:02 +0200

Uff... da ist mir grad ein makabrer Level aufgefallen. Da läuft ein Männlein nen Hang runter, wird vom Blitz erschlagen, fällt tot um und läuft sofort blau an. Dann kommt die Aufgabenstellung: "Berge die Leiche und begrabe sie". Wow. Man muß den Blaumann aufheben, in nen Sarg stecken und unter die Erde bringen. Wirklich krass. Keine Ahnung, was ein Sechsjähriger dazu sagen würde.

Thomas Werner: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (Thomas Werner) — Sun, 11 Oct 2009 13:02:57 +0200

Zunächst zur Frage mit dem (Meta-)Modell: das ist einfach nur implementierungsspezifisch. Ob die Modelle als XML-Dateien, Binärdateien, spezieller Quellcode oder in einer SQL-Datenbank vorkommen, hängt vom jeweiligen Werkzeug ab.

Soweit ich noch in Erinnerung hab gibt es für die meisten Modelltransformationssprachen eine einheitliche Sprache, die zur Beschreibung von Modellen und Metamodellen dient. Ich glaub, die nennt sich "ecore" und es handelt sich um XML zur Definition von Klassen / Typen / Attributen und Relationen untereinander.

Zur zweiten Fragen wegen der Validierung: das ist bei Programmiersprachen aufgrund ihrer Grammatik an sich machbar, Du erstellst Dir Testfälle, welche gültigen Quellcode sowie ungültigen Quellcode darstellen und jagst die einzelnen Quelltexte durch den Parser, um zu gucken, ob an den richtigen Stellen gemeckert wird.

Das Thema der automatisierten Validierung der Korrektheit eines Algorithmus geht allerdings schon in den Bereich der Theoretischen Informatik - sprich: man träumt derzeit noch davon, Verfahren zu entwickeln, die es ermöglichen herauszufinden, ob ein Algorithmus wirklich das macht, was man von ihm erwartet.

Mit Fehlern muß man leider rechnen und man kann sie allenfalls durch fleißiges Unit Testing eindämmen, aber komplett ausschließen ist leider nicht möglich.

Da Du in Deinem Algorithmus die Umwandlung selbst in der Hand hast, weißt Du ja im Vorfeld, daß das Resultat der gewünschten Zielsprache entspricht oder entsprechen sollte. Du hast es ja nicht mit einer beliebigen Eingabe eines Benutzers zu tun, sondern mit einem Resultat Deines Programms. Dieses Resultat zu validieren, wäre ja dann einfach eine Frage der Anwendung der Zielgrammatik darauf. Es ist halt die Frage, ob das wirklich notwendig ist, weil Du ja die Zielgrammatik schon davor im Zwischenschritt bei der Generierung des Zielquelltexts angewendet hast, daher würde ich diese Prüfung mit der Zielgrammatik nicht als festen Bestandteil des Umwandlungsprogramms sehen, sondern als einen extern angelegten Unit Test zur Prüfung der Qualität des Programms.

derschreckliche: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (derschreckliche) — Sun, 11 Oct 2009 06:51:40 +0200

Vielen Dank für die Anregungen, hat mir auch viele Anhaltspunkte für weitere Recherchen geliefert.

Wo ich aber leider kaum etwas dazu gefunden habe ist wie so ein Modell bzw. Metamodell beschrieben wird. Mit MOF? Grafisch?

Zu dem vorgeschlagenen Vorgehen für die Transformaiton:
So in etwa habe ich mir das auch vorgestellt. Und ob man den AST der Zielsprache zuerst aufbaut, ob in place oder nicht, oder gleich Code generiert ist ja (fast) egal .
Allerdings bleibt das Problem der Validierung in beiden Fällen bestehen. [Obwohl man bei Generierung eines Zielsprachen-AST diesen natürlich mit einem Visitor unter Zurhilfenahme der Zielgrammatik durchlaufen und prüfen könnte... ]
Interessant wäre es aber vor allem den Regelsatz(ich nenne ihn mal Transformationsfunktion) vorab mit Hilfe der Ziel-Grammatik auf Korrektheit prüfen zu können, denn wenn ich bei der Transformationsfunktion alles mögliche angeben kann, kann ich ja nicht sicher gehen, dass jede _korrekte_ Eingabe auch eine korrekte Ausgabe liefert - ich also eine Vollständige Abbildung habe.

So, das waren ein Paar Gedanken meinerseits dazu, bin gespannt ob du auch etwas kennst, was in diese Richtung geht, habe bisher kaum etwas dazu finden können.

Freue mich wie schon oben erwähnt sehr auf den kommenden Artikel.

Greeeeeeeeeeeeetz,

derschreckliche

Thomas Werner: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (Thomas Werner) — Thu, 08 Oct 2009 13:53:13 +0200

Während meines Studiums beschäftigte ich mich zwei Semester lang mit dem Thema Modelltransformation (siehe http://de.wikipedia.org/wiki/Modelltransformation) - das ist im Prinzip ein relativ frisches Forschungsfeld, welches sich unter Anderem mit genau dem Thema beschäftigt, eine Programmiersprache in eine andere Programmiersprache umzuwandeln.

Grundidee ist, daß ein Quellcode als ein Modell betrachtet wird. Diesem Modell liegt ein Metamodell zugrunde, welches die Möglichkeiten der Modellgestaltung ausdrückt (im Grunde wie eine Grammatik). Im Rahmen der Modelltransformation bastelt man sich Regeln, wie man die Informationen aus dem Metamodell A auf die Informationen aus einem anderen Metamodell B abbildet.

Hier kann man so Späße machen wie: verwandle mir ein UML-Klassendiagramm in eine SQL-Datenbank und umgekehrt.

Für die Modelltransformation gibt es einige Modelltransformationssprachen und dazugehörige Werkzeuge, unter anderem QVT (textuell) oder MOLA (grafisch - hier wird die Transformation über Diagramme ausgedrückt).

Leider sind ein paar der vorhandenen Werkzeuge derzeit etwas instabil, weil es sich eben auch um Neuland handelt. Andere Werkzeuge sind dagegen stabil und dafür teuer.

Wenn man die Transformation von einer Sprache in eine andere sauber machen möchte, würde ich das folgendermaßen angehen:

1. Den AST für die Ausgangssprache erstellen

2. Mit Hilfe eines Regelsatzes den Ausgangs-AST in den AST der Zielsprache umwandeln (wobei mir gerade einfällt, daß man sich diesen Schritt sparen könnte und den Ausgangs-AST direkt in JavaScript-Code wandeln könnte)

3. Den Ziel-AST zurückwandeln in Quellcode - also im Grunde die Schritte umkehren, die der Parser angestellt hat.

Da ich das Thema ziemlich spannend finde, werde ich mir - sobald ich Zeit habe - selbst Gedanken dazu machen und einen Artikel darüber schreiben.

derschreckliche: [Compilerbau II] Der Abstrakte Syntaxbaum

nospam@example.com (derschreckliche) — Thu, 08 Oct 2009 04:40:45 +0200

Hi Thomas,

auch diesen Artikel fand ich äußerst hilfreich, auch wenn er nicht auf alle Details eingeht, aber das ist im Rahmen eines Artikels von 3 Seiten länge ja auch nicht möglich.

Eine Frage hätte ich noch:
Ich habe im Quellcode der Live-Version des Interpreters gesehen, dass du die Befehle beim durchlaufen des AST direkt ausführst. Das funktioniert ja auch super, da du für viele Funktionen ja direkte Entsprechungen in JavaScript hast.
Angenommen du wolltest JavaScript-Code generieren, anstatt die Anweisungen direkt auszuführen, wüsstest du da eine Möglichkeit sicherzustellen, dass der generierte Code _valides_ JavaScript ist?

Mir würde auch schon ein Link oder eine Buchempfehlung zu diesem Thema schon sehr weiterhelfen.

Die Möglichkeiten, die mir einfallen würden wären zum einen:
- Parsen des Outputs mit Hilfe eines JS-Parsers,
zum anderen:
- Übersetzungsschemata angeben und deren Korrektheit beweisen.
Ersteres hat den Nachteil, erst nach Anwendung der Transformation feststellen zu können, ob diese korrekt ist oder nicht.
Letzteres ist erstens nicht ganz trivial, und zweitens stellt zwar sicher, dass die einzelnen Transformationsregeln "lokal" korrekt sind, jedoch nicht ob diese "untereinander/zueinander" korrekt sind....
*grübel*grübel*

Freue mich schon auf den kommenden Artikel zu diesem Thema.

Greeeeeeeeeeetz

derschreckliche

derschreckliche: [Compilerbau] Parser Marke Eigenbau

nospam@example.com (derschreckliche) — Thu, 08 Oct 2009 03:11:18 +0200

Super Artikel, vielen Dank hierfür!

Ich beschäftige mich auch gerade mit diesem Thema und ich muss sagen, du hast es geschafft viele Zusammenhänge sehr gut und verständlich zu erklären, ohne dabei zu sehr in die Tiefe zu gehen.
Das Problem hatte ich teilweise beim aktuellen "Drachenbuch", da fand ich "Grundlagen und Techniken des Compilerbaus" von Niklaus Wirth, auf welches du ja auch verweist, schon viel besser.

Welches Buch ich aber noch für "außergewöhnliche" Anwendungsbereiche empfehlen kann ist "Übersetzerbau - Techniken, Werkzeuge, Anwendungen" von Güting und Erwig. Dort vor allem das Kapitel 5, welches die Übersetzung einer Dokumentenbeschreibungssprache beschreibt. (PD-Text[ähnelt mancher Wiki-Syntax] nach LaTeX).
Leider steht da nicht viel zur Validierung der Transformation, also zu Möglichkeiten, sicherzustellen, dass die Ausgabe in der Zielsprache liegt...

Naja, ich werde mal deinen zweiten Artikel lesen, vllt. finde ich ja da etwas in der Richtung.

Nochmals vielen Dank für den schönen Artikel.

Greeeeeeeeeetz

derschreckliche

Thomas Werner: Ein Thema voller Mißverständnisse: o.o.p.

nospam@example.com (Thomas Werner) — Mon, 07 Sep 2009 17:49:48 +0200

Okay, zu meiner Verteidigung... nein, hierfür gibt es keine plausible Entschuldigung. Seit Anfang des Jahres hatte ich diesen Artikel als Entwurf und wollten ihn noch mit speziell angefertigten Illustrationen verfeinern, die so aussehen wie aus dem Tampon-Beipackzettel.

Ich hab keine Ahnung, was mich damals trieb, das zu schreiben, aber ich denke, es mußte endlich mal raus...

Mein zukünftiger Arbeitgeber möge mir diesen Artikel verzeihen.

Thomas Werner: Annahme ausgelöst und nicht aufgefangen - oder JavaScript im Internet Explorer

nospam@example.com (Thomas Werner) — Mon, 29 Jun 2009 14:35:53 +0200

Ich hab den Code schon gesehen, es wird nur so kaputt dargestellt, wie man das jetzt bei Deinem Kommentar sieht. Aber naja...

Zum Problem: ich fürchte, ich kann da nicht weiterhelfen. Ich würde versuchen da anders ranzugehen und rumzuexperimentieren. Statt span mal nen DIV probieren. Vielleicht hilft es auch, wenn Du Dich in eine etablierte JavaScript-Bibliothek wie JQuery, prototype oder Dojo einarbeitest. Darin finden sich auch meist Problemlösungen für diverse Browser-Wehwechen.

Abschließend würde ich noch vorschlagen, daß Du zuerst einmal versuchst, das Aussehen Deines Menüs fest in HTML zu programmieren. Versuch's so zu machen, daß es im IE anständig aussieht. Vielleicht sind da die Probleme auch bereits gegeben.

Da Du in Dein Menü noch speziellen HTML-Code einbaust, der nur für den Internet Explorer sichtbar ist (Kommentar-Code), verändert sich für den IE natürlich auch die Anzahl der Kindknoten des Eltern-Knotens. Der Code:

Menue.insertBefore(span, Menue.childNodes[3]);

Verweist dadurch wahrscheinlich im IE an die falsche Stelle im DOM-Baum. Mach's doch folgendermaßen: Die beiden unsortierten Listen (ul) sind ja fest im HTML-Code. Gib doch der zweiten "ul" eine id und mach folgendes:

document.getElementById('zweiteUlID').insertBefore(span);

Das muß an sich funktionieren. Wenn nicht, dann hakts sicherlich an einer anderen Stelle in Deinem Code.

Wegen dem Breitenwert "0" gibts folgende JavaScript-Lösung, die ich aus meiner eigenen JavaScript-Bibliothek herauskopiert hab:

// Teste, ob IE am Laufen ist:
if(isIE) {
window.getComputedStyle = function(node) {
var toReturn = new Object();
toReturn.getPropertyValue = function(prop) {
prop = prop.hyphenToCamelCase();
switch(''+prop) {
case 'width':
if(node.currentStyle[prop] == 'auto') {
return node.offsetWidth;
}
case 'height':
if(node.currentStyle[prop] == 'auto') {
return node.offsetHeight;
}
}
return node.currentStyle[prop];
};
return toReturn;
};
}
String.prototype.hyphenToCamelCase = function() {
var str = this;
// Achtung: > ist ein Größer-Als-Zeichen!
if(str.indexOf('-') > -1) {
var parts = str.split('-');
str = parts[0];
// < ist ein Kleiner-Als-Zeichen
for(var i = 1; i < parts.length; i++)
str += parts[i].substr(0, 1).toUpperCase() + parts[i].substr(1);
}
return str;
};

Die Methode window.getComputedStyle(node) ist an sich ne Standard-Funktion, die nur der IE nicht kennt.

Anwendung:

var result = window.getComputedStyle(node);
var breite = result.getPropertyValue('width');

Daniel: Annahme ausgelöst und nicht aufgefangen - oder JavaScript im Internet Explorer

nospam@example.com (Daniel) — Mon, 29 Jun 2009 13:36:23 +0200

Hallo Thomas,

ich sehe jetzt gerade, das mein HTML-Code hier nicht erschienen ist.
Daher konntest du mein Fall nicht ganz verstehen.
Füge sie jetzt noch mal hier ein und hoffe, dass du mich dann besser verstehst.

CODE:

1.0 1.1 1.1.1 1.1.2 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.3 1.4 1.5 2.0 2.1 2.2 2.3 3.0 4.0 5.0 6.0 6.1 6.2 6.1 6.2

Das mit "display:inline-block" habe ich versucht aber Hilft auch nichts.
Du hast recht mit dem Breitenwert.
Bekomme tatsächlich die 0 raus.
Aber habe auch Manuell ein Breitenwert (also ein statischen Wert) eingegeben und es tut sich einfach nichts.

Bin echt am zweifeln !!!

Viele Grüße,
Daniel

Thomas Werner: Annahme ausgelöst und nicht aufgefangen - oder JavaScript im Internet Explorer

nospam@example.com (Thomas Werner) — Mon, 29 Jun 2009 10:15:34 +0200

Ich muß da nochmal nachhaken, weil ich immer noch nicht genau weiß, was bei Dir nicht funktioniert. Wird das eingefügte Span überhaupt nicht dargestellt oder wird die gewünschte Breite nicht gesetzt? Das mit der Breite könnte an einer Darstellungseigenschaft des Spans liegen, und du könntest zusätzlich die CSS-Eigenschaft "display:inline-block" versuchen. Dadurch bekommt das Span noch Block-Eigenschaften und dadurch ist dann auch das Setzen einer festen Breite vorgesehen.

Welchen Breitenwert liest Dein JavaScript-Code eigentlich im Internet Explorer aus? Ist es vielleicht 0?

Als weiterer Hinweis: Dein JavaScript-Code verwendet die Liste childNodes, welche in den verschiedenen Browsern, abhängig vom HTML-Code, unterschiedlich beschaffen sein kann. Firefox macht zum Beispiel selbst aus unbedeutendem Whitespace eigenständige Textknoten - IE verhält sich da etwas anders und scheint sich mehr "auf's Wesentliche" zu konzentrieren.

Ansonsten würde ich das Span bereits vorher einbauen und unsichtbar machen.

Daniel: Annahme ausgelöst und nicht aufgefangen - oder JavaScript im Internet Explorer

nospam@example.com (Daniel) — Mon, 29 Jun 2009 02:03:54 +0200

Hallo Thomas,

hm, habe das mit "insertBefore" über den Style geschrieben - sprich erst wird der Span-Tag eingefügt und dann der Style aber leider funktioniert das auch nicht.

Mein HTML Code sieht folgendermaßen aus:

TW: Tut mir leid, ich krieg den HTML-Code nicht dargestellt. Irgendwie spinnt das Geshi-Plugin herum.

Der Span-Tag soll via JS genau zwischen den beiden UL-Tags eingefügt werden.
Also da wo ul#nav und ul#nav2 steht.

Anschließend soll der Width Dynamisch für Span-Tag geändert werden.
Und zwar mit der Abhängigkeit, dass im ul#nav wo der "selectMenue" existiert davon der Position vom linken Rand aus soll für den Span-Tag Width eingefügt werden.

Ich hoffe ich konnte mein Ziel gut beschreiben.
Falls du fragen haben solltest, dann einfach noch mal Fragen !!!

Würde dir echt sehr Dankbar sein, wenn du mir Helfen könntest.
Bin echt am zweifeln momentan.

Viele Grüße,
Daniel