Ich hab für die Dokumentation von Bottle ein kleines Script geschrieben, das ein GitHub Wiki herunter laden und als HTML-Seiten speichern kann.
http://gist.github.com/149524
Benötigt Bottle (für das Template) kann aber leicht angepasst werden, so das es auch ohne Bottle läuft.
In der Kommandozeile ausgeführt wird der erste Parameter als Benutzername und der zweite als Projektname interpretiert und für jede Wiki-Seite eine separate HTML Datei im aktuellen Verzeichnis angelegt. Wiki-Links werden dabei in relative Links umgewandelt.
Beispiel: "python githubwikifetcher.py defnull bottle"
GitHub Wiki Downloader
-
Defnull
- User
- Beiträge: 778
- Registriert: Donnerstag 18. Juni 2009, 22:09
- Wohnort: Göttingen
- Kontaktdaten:
Bottle: Micro Web Framework + Development Blog
Tja, intern nutzt der Wiki möglicherweise git - wer weiß - doch nach außen ist das ein ganz eigenes Biest.Leonidas hat geschrieben:Und ich dachte das Wiki könnte man einfach klonen, so wie bei BitBucket auch.
Man findet übrigens auch alle Wiki-Seiten, in dem man auf "Home" nach ".sidebar li" (in JQuery-Sprech) sucht und dort allen Links folgt. Die "Nutzlast" der Seite findet man in ".main", wo man dann noch das ".actions"-Kind entfernen kann. Eigentlich sollten das IMHO alles IDs und kleine Klassen sein. Den Quelltext könnte man von den .../edit-Seiten ernten, doch auch dort ist die HTML-Struktur etwas merkwürdig. Wieso ist das textarea-Element ein Kind des label-Elements? Will man Github selbst eine Seite rendern lassen, könnte man dazu die preview-Funktion als Webservice missbrauchen.
Stefan
-
Defnull
- User
- Beiträge: 778
- Registriert: Donnerstag 18. Juni 2009, 22:09
- Wohnort: Göttingen
- Kontaktdaten:
@sma
RegExp war in dem Fall schneller und einfacher als domtree gewurstel, prinzipiell tu ichs aber genau so, wie du sagst.
@Leonidas
GitHub plant irgendetwas umständliches, wobei ein spezieller Branch eines Projektes die Wiki Seiten enthalten soll. Das ist aber ziemlicher Mist. Ich persönlich fände es ätzend, wenn ich in meinem Repro einen Branch hätte, der komplett andere Dateien enthält als mein eigentliches Projekt.
Ich hätte einfach für jedes Projekt automatisch ein separates Repository angelegt (z.B. projektname_githubwiki) und gut. Mit Hooks könnte man verhindern, das Seiten hoch geladen werden, die sich nicht parsen lassen. Mit Dateiendungen könnte man den Syntax festlegen. Das man für die Wikiseiten kein MarkDown verwenden kann, ist eh ätzend. Ich muss die Doku praktisch zwei mal schreiben, einmal in rt und einmal in md.
Den WiKi-Downloader hab ich für mein Release-Script geschrieben, damit in der Source-Distribution eine aktuelle Dokumentation enthalten ist. Klappt eigentlich ganz gut. Die Idee mit der Edit-Seite für die Quelltexte ist aber auch nicht schlecht. Viele lesen ja lieber Textdateien als HTML Seiten.
RegExp war in dem Fall schneller und einfacher als domtree gewurstel, prinzipiell tu ichs aber genau so, wie du sagst.
@Leonidas
GitHub plant irgendetwas umständliches, wobei ein spezieller Branch eines Projektes die Wiki Seiten enthalten soll. Das ist aber ziemlicher Mist. Ich persönlich fände es ätzend, wenn ich in meinem Repro einen Branch hätte, der komplett andere Dateien enthält als mein eigentliches Projekt.
Ich hätte einfach für jedes Projekt automatisch ein separates Repository angelegt (z.B. projektname_githubwiki) und gut. Mit Hooks könnte man verhindern, das Seiten hoch geladen werden, die sich nicht parsen lassen. Mit Dateiendungen könnte man den Syntax festlegen. Das man für die Wikiseiten kein MarkDown verwenden kann, ist eh ätzend. Ich muss die Doku praktisch zwei mal schreiben, einmal in rt und einmal in md.
Den WiKi-Downloader hab ich für mein Release-Script geschrieben, damit in der Source-Distribution eine aktuelle Dokumentation enthalten ist. Klappt eigentlich ganz gut. Die Idee mit der Edit-Seite für die Quelltexte ist aber auch nicht schlecht. Viele lesen ja lieber Textdateien als HTML Seiten.
Bottle: Micro Web Framework + Development Blog