Realisierbarkeit von einem Projekt wie SELFHTML

[Christian]

Hallo,

ich überlege mir ernsthaft, ob ich nicht ein Projekt auf die Beine stellen soll, das sich mit JavaScript beschäftigt, ähnlich dem von JS-Teil von SelfHTML nur ausführicher. Ich dachte du zumindest an eine ausführliche Objektreferenz, die möglichst alle Befehle und Objekte enthält die es so gibt. Die Idee entstand wohl aus meinem Beitrag vom 12.03.03: http://forum.de.selfhtml.org/archiv/2003/3/40659/

Nun frag ich mich wie ich das realisieren könnte! Habt ihr Vorschläge!?

Ich habe Erfahrung mit PHP/MySQL und möchte es auch gerne auf dieser Basis machen. Erste Idee war, dass ich einfach eine Tabelle anlege, die folgende Spalten enthält:

• Name des Objektes/Methode/Eigenschaft/Eventhandler
• Typ (Objekt, Methode, Eigenschaft ODER Event)
• (Rückgabe-)Wert (Objekt, String, Number, void, ...)
• JavaScript Version
• JScript Version
• DOM-Level
• IE-Unterstützung
• Netscape Unterstützung
• Opera Unterstützung
• Syntax/Beispiel Code
• "siehe auch"-Spalte mit Referenz zu ähnlichen Befehlen
• Bemerkung

Dann noch eine Spalte "ID" und "parentID" oder so, um die Felder anzusprechen und die Objekthierarchie rekursiv aufbauen zu können.

Probleme sehe ich nun darin:
Wie kann ich in Texten (z.B. Erläuterung, Bemerkung, ...) Verweise machen oder Schlüsselwörter/Code farbig (SelfHTML benutzt blau) und in anderer Schriftart hervorheben, OHNE (!!!) HTML-Code in der Datenbank zu speichern?? Geht das überhaupt?? Ich bin eigentlich immer bemüht, meine Datenbanken frei von HTML zu haben, und nur reinen Text zu speichern.
Idee war, dass ich jedes Wort durchgehe und schaue ob es ein Befehl (Methode, Eigenschaft, Objekt...) ist, der in der DB steht, und wenn ja das Wort irgendwie hervorhebe/verlinke.
Aber das wäre wohl sehr umständlich und geht sehr auf die Performance!

Weiß jemand wie SelfHTML technisch realisiert ist?? Habt ihr Ideen????

Sicher wäre so ein Projekt sehr viel aufwand, weiß auch nicht ob ich es schaffen werde, oder ob mir in 2 Wochen nicht doch schon die Motivation vergeht, aber probieren will ich es :-) !

Danke und Gruß,
Christian

[Philipp Grashoff]

Hi Christian,

Verweise machen oder Schlüsselwörter/Code farbig (SelfHTML benutzt blau) und in anderer Schriftart hervorheben, OHNE (!!!) HTML-Code in der Datenbank zu speichern?? Geht das überhaupt?? Ich bin eigentlich immer bemüht, meine Datenbanken frei von HTML zu haben, und nur reinen Text zu speichern.

Was ist so schlimm an HTML in der DB?
Eine andere moeglichkeit waere wohl, einen Code aehnlich wie hier im Forum zu entwickeln (<....>...[/link]; [color:...]...[/color]), aber da waere wohl HTML einiges unumstaendlicher.

MFG

Philipp

[Sven Rautenberg]

Moin!

Weiß jemand wie SelfHTML technisch realisiert ist?? Habt ihr Ideen????

SelfHTML ist genau das, was du bei dir im Browser siehst, wenn du http://selfhtml.teamone.de aufrufst: HTML-Seiten.

Da steckt keinerlei Datenbank dahinter, oder sonst irgendeine dynamische Komponente. Alles ist _handgeschriebenes_ HTML, wobei der Großteil des Schreibens natürlich für den Inhalt draufgeht, und nicht unbedingt fürs Markup.

Außerdem mußt du bedenken, dass SelfHTML mittlerweile in Version 8.0 vorliegt - die vorhergehenden 7 Versionen sind teilweise leider verlorengegangen, das, was wiedergefunden wurde, kann in http://aktuell.de.selfhtml.org/archiv/doku/index.htm betrachtet werden. Wenn du dir da mal Version 1.0 oder 2.0 anguckst, weißt du ungefähr, wie deine erste Version aussehen bzw. was sie beinhalten wird.

Wenn du jetzt aber gleich zu Beginn anfängst, die technische Realisation zu bedenken, dann fängst du in meinen Augen definitiv an der falschen Seite an. Es geht dir doch schließlich um Inhalte. Komplexe Inhalte, wie ich mal vermuten würde. Solche komplexen Inhalte lassen sich nur ganz schlecht in eine relationale Datenbank packen. Viel eher passen sie in XML. Wobei du dann erstmal eine DTD definieren mußt - dann kannst du die XML-Dateien aber hinterher beliebig in andere Formate und in anderen Designs ausgeben. Oder du benutzt HTML, da hast du dann die komplette Freiheit in der Inhaltsgestaltung.

- Sven Rautenberg

[Wilhelm Turtschan]

Moin

ich überlege mir ernsthaft, ob ich nicht ein Projekt auf die Beine stellen soll, das sich mit JavaScript beschäftigt, ähnlich dem von JS-Teil von SelfHTML nur ausführicher. Ich dachte du zumindest an eine ausführliche Objektreferenz, die möglichst alle Befehle und Objekte enthält die es so gibt.

Sehr ambitionierte Aufgabe. :)

Ich habe Erfahrung mit PHP/MySQL und möchte es auch gerne auf dieser Basis machen.

Hier liegt IMHO der erste Denkfehler.
Die grosse Verbreitung, die Bekanntheit und Akzeptanz von SELFHTML ergibt sich auch aus den zig-tausend Downloads. Was hilft mir ein Lehrwerk, wenn ich permanent online sein muss.
Wenn Du jedoch alles in eine Datenbank packst und die Inhalte dynamisch aufbereitest, musst Du bei den Clients einen lauffaehigen Webserver incl. Datenbank voraussetzen. Davon kannst Du definitiv nicht ausegehen.

Gruesse
Wilhelm

[Gunnar Bittersmann]

Wenn Du jedoch alles in eine Datenbank packst und die Inhalte dynamisch aufbereitest, musst Du bei den Clients einen lauffaehigen Webserver incl. Datenbank voraussetzen.

Nö, der Server generiert aus der DB HTML und schickt das an den Client. Der Client bekommt gar nicht mit, ob der Code aus einer HTML-Datei stammt oder dynamisch erzeugt wird.

Gruß, Gunnar

[Wilhelm Turtschan]

Moin

Wenn Du jedoch alles in eine Datenbank packst und die Inhalte dynamisch aufbereitest, musst Du bei den Clients einen lauffaehigen Webserver incl. Datenbank voraussetzen.

Nö, der Server generiert aus der DB HTML und schickt das an den Client. Der Client bekommt gar nicht mit, ob der Code aus einer HTML-Datei stammt oder dynamisch erzeugt wird.

Ist ja nett, dass Du mir die Kommunikation Server/Browser erklaerst, die Tatsachen sind mir aber sehr wohl bekannt.

Du haettest aber ein bisschen aufmerksamer lesen sollen:

<cite> "ergibt sich auch aus den zig-tausend Downloads" </cite>

Scheint Dir wohl entgangen zu sein.
Meine ganzen Aussagen bezogen sich auf eine evtl. Download-Version.

Gruesse
Wilhelm

[Gunnar Bittersmann]

Du haettest aber ein bisschen aufmerksamer lesen sollen:

Kann auch bei aufmerksamem Lesen nicht finden, dass Christian daran gedacht hatte, auch eine Version zum Download anzubieten, die dann lokal angeschaut werden kann.

Dass sowas sinnvoll ist, darüber sind wir uns sicher einig. Und dass dann alles ohne Webserver und Datenbank laufen sollte, darüber auch.

Gruß, Gunnar

[Sven Rautenberg]

Moin!

Wenn Du jedoch alles in eine Datenbank packst und die Inhalte dynamisch aufbereitest, musst Du bei den Clients einen lauffaehigen Webserver incl. Datenbank voraussetzen.

Nö, der Server generiert aus der DB HTML und schickt das an den Client. Der Client bekommt gar nicht mit, ob der Code aus einer HTML-Datei stammt oder dynamisch erzeugt wird.

Was ist, wenn man offline ist? Welcher Server sorgt dann für die dynamische Generierung von HTML?

Und sag bitte nicht, man soll dann einfach mal online gehen. Es gibt genügend Gründe, eine wichtige Dokumentation offline auf Festplatte zu haben - der Ausfall der eigenen Leitung ist nur einer davon, der Kostenfaktor u.U. ein weiteter - und wenn der hostende Server ausfällt oder überlastet ist, ist das auch schlecht. Solche Situationen treten leider immer dann auf, wenn man selbst ultradringend was nachgucken muß.

- Sven Rautenberg

[Alexander Foken]

Moin Moin !

Was spricht dagegen, eine Datenbank zu benutzen, um den Inhalt innerhalb der Redaktion schnell und bequem bearbeiten zu können?

Eine Download-Version ist dann nicht mehr und nicht weniger als eine eingefrorene Kopie der dynamisch erzeugten HTML-Seiten. Im "simple-and-stupid"-Ansatz: wget -m -np http://redaktion.local.lan/php/jsdoc/ und anschließend ein Aufruf von ZIP.

Das funktioniert wunderbar, wenn man innerhalb der Doku immer schön brav relative Links benutzt und die Dokumente ausschließlich über "?"-lose URLs aufruft.

Alexander