Ist DocBook wirklich so beschissen?
Felix von Leitner
Seit ungefähr Stunden bin ich hier am Testen, Kompilieren und
Installieren und nicht eine Software kommt mit nutzbringender
Dokumentation, nicht ein HOWTO beschreibt eine funktionierende
Dokumentation und nicht ein Beispieldokument läßt sich mit auch nur
einer der Implementationen "einfach so" (call me naive...) übersetzen.
Kann es sein, daß eine derartig gehypete Technologie, die seit Jahren
standardisiert und (supposedly) dokumentiert ist, in der bekannte
Verlage ihre Manuskripte verfassen, so was von überhaupt nicht
funktioniert?
Ist es möglich, daß die ganze Welt einfach nur völlig besoffen ist in
Bezug auf diese "Technologie"? Oder ist das einfach nur ein grandioser
Witz und jemand sitzt irgendwo in seiner Villa in Bel Air und lacht sich
kaputt?
Was mich am meisten beeindruckt: nicht eine dieser ganzen beschissenen
kaputten "Lösungen" hat eine dem Problem angemessene Größe! Alles
Multi-Megabyte-Pakete von irgendwelchen OOP-Künstlern, Bloat bis zum
Abwinken...
Ich bleib bei TeX, vielen Dank.
Felix
PS: Ich sammle noch prägnante Zitate zu DocBook und XML für meine
Signature-Sammlung.
--
A hypothetical paradox: What would happen in a battle between an
Enterprise security team, who always get killed soon after appearing,
and a squad of Imperial Stormtroopers, who can't hit the broad side of a
planet? --Tom Galloway
Christian Bauer
>Seit ungefähr Stunden bin ich hier am Testen, Kompilieren und
>Installieren und nicht eine Software kommt mit nutzbringender
>Dokumentation, nicht ein HOWTO beschreibt eine funktionierende
>Dokumentation und nicht ein Beispieldokument läßt sich mit auch nur
>einer der Implementationen "einfach so" (call me naive...) übersetzen.
Willkommen im Club. Die einzige halbwegs brauchbare Loesung ist auf die
SGML und die grausamen DSSSL-Geschichten zu verzichten und sein Glueck
mit XML/XSL zu versuchen. Die Kombination der Walsh-DTD, XSL-DocBook
Stylesheets und Saxon/FOP funktioniert leidlich. Bugs bis zum Abwinken,
zum Glueck existieren bekannte Workarounds.
http://www.sagehill.net/xml/docbookxsl/
http://trieloff.net/doctutorial/build/
>Kann es sein, daß eine derartig gehypete Technologie, die seit Jahren
>standardisiert und (supposedly) dokumentiert ist, in der bekannte
>Verlage ihre Manuskripte verfassen, so was von überhaupt nicht
>funktioniert?
Welcher Verlag denn? Ich war bei meinem der Erste, sorgt momentan fuer
grosses Chaos bei den FrameMakern.
>Ist es möglich, daß die ganze Welt einfach nur völlig besoffen ist in
>Bezug auf diese "Technologie"? Oder ist das einfach nur ein grandioser
>Witz und jemand sitzt irgendwo in seiner Villa in Bel Air und lacht sich
>kaputt?
Das ist nicht unwahrscheinlich.
>Was mich am meisten beeindruckt: nicht eine dieser ganzen beschissenen
>kaputten "Lösungen" hat eine dem Problem angemessene Größe! Alles
>Multi-Megabyte-Pakete von irgendwelchen OOP-Künstlern, Bloat bis zum
>Abwinken...
Achja, die Loesungen von oben sind Java-basiert. Sind die einzigen.
>Ich bleib bei TeX, vielen Dank.
Ohja.
>PS: Ich sammle noch prägnante Zitate zu DocBook und XML für meine
>Signature-Sammlung.
Die Anzahl der Flueche und Verwuenschungen duerfte recht ordentlich
steigen. DocBook XML ist wirklich schmerzhaft, aber die Alternativen
sind das auch. Alles sehr unbefriedigend, aber was will man machen...
--
Christian Bauer
tu...@incubus.de
Felix von Leitner
> Ich wollte mich heute mal mit DocBook beschäftigen.
Juchee! Ich habe xsltproc dazu bewegen können, daß er meinen
Hallo-Welt-Article parsen und nach HTML und/oder FO transformiert!
article.xml ist 844 Bytes groß. Ihr könnt euch sicher vorstellen, wie
hochkomplex die Formatierungen dort sind.
Warum xsltproc? Weil ich überall gelesen habe, daß das der mit Abstand
schnellste Transformator sei, der um Größenordnungen über allen
Alternativen liegt und so weiter. Das Teil ist immerhin in
hochoptimiertem C geschrieben, und löst ein doch sehr überschaubares
Problem, zu dem das wohl aussehende Typesetting noch _nicht_ gehört.
Erstaunlich, daß so ein Tool anderthalb Megabyte groß ist!
Noch erstaunlicher, daß dieses unglaublich performante Tool für ein
Hallo-Welt XML-File über zwei Sekunden frißt!
Aber gut, kann passieren, GNOME-Bloatware, kennt man ja.
Jetzt wo ich den harten Teil gemacht habe, sollte das Darstellen ja
richtig schnell gehen, richtig? Man ist ja von PDF und DVI verwöhnt,
aber auch HTML läßt sich auf meinem Athlon XP 2000+ in Echtzeit rendern.
Sollte also kein Thema sein, nicht wahr?
Ich habe mir also eines meiner Pakete genommen, FOP, von der Apache
Suite, und die Jungs sind ja eh bekannt für exzellente Performance und
knallharte Optimierungen bis hart an den Rand der Legalität. Gut, ist
in Java geschrieben, aber Java ist ja heute schneller als C, wir haben
ja schließlich JIT und so, habe ich gelesen. Ich rufe also auf:
$ fop article.fo -awt
Das Fenster geht auch schön schnell auf, dauert nur 1 Sekunde. Es
bleibt grau. Mit zunehmendem Entsetzen sitze ich geschlagene 15
Sekunden vor meinem Desktop, bis ich ein ekliges Rendering sehe, das
noch nicht mal Antialiasing kann, obwohl das ja heute sogar in X
eingebaut ist! FÜNFZEHN SEKUNDEN FÜR HALLO WELT, und dann sieht das
auch noch unakzeptabel scheiße aus?
Gut, kann man jetzt argumentieren, das FO-Format ist offenbar von einem
absoluten vollständigen Vollidioten erfunden worden, und das kann man
halt nicht effizient rendern. Schauen wir uns das doch mal an:
$ ls -l article.fo article.xml
-rw-r--r-- 1 leitner users 40480 Apr 29 01:43 article.fo
-rw-r--r-- 1 leitner users 844 Apr 29 01:33 article.xml
$
WOT? Fast um den Faktor 50 aufgeblasen, und dann immer noch unbrauchbar
für eine performante Darstellung?! WTF?!?!?
Meine Güte, so angewidert war ich schon echt lange nicht mehr von
Software. Was für eine Zumutung! Und die Leute schreiben, daß XML so
effizient sei, und daß SGML so kompliziert sei? Ich will mir gar nicht
vorstellen, wie langsam und unzumutbar das alles mit SGML wäre...
*grusel*
Felix
--
A likely impossibility is always preferable to an unconvincing possibility.
--Aristotle
Felix von Leitner
> Hallo-Welt-Article parsen und nach HTML und/oder FO transformiert!
Oh Mann, da seht ihr mal das Ausmaß meiner Verzweiflung: ich habe sogar
Sun-Software probiert, um aus FO etwas brauchbares zu machen!
Konkret habe ich xmlroff probiert, weil es so klang, als würde es mit
groff gemacht, das performt ja wenigstens. Tatsächlich erzeugt das Teil
auf FO-Dateien PDF-Dateien. Nach dem Java-Desaster hätte es ja nur
besser performen können, sogar Sun kann etwas nicht so verkacken,
richtig?
Tatsächlich kann xmlroff aus dem beiliegenden Beispiel-FO eine PDF-Datei
erstellen, die (es handelt sich um eine halbe Seite, eine konvertierte
Man Page) aus ein paar Kilobyte mit zlib Faktor 9 lediglich gut 200k
groß ist! Diese Qualitätsmaßstäbe überzeugen mich auf Anhieb und ich
werfe das Teil auf mein FO an.
Fehler.
(process:30133): libfo-CRITICAL **: fo-fo-error: FoMarker not allowed as child of FoBlock Object path:
/FoTree[1]/root[1]/page-sequence[1]/flow[1]/FoBlock[1]/FoBlock[1]/FoBlock[1]/FoBlock[1]/FoBlock[1]/FoBlock[1]/FoMarker[1]
[und weiter unten, so richtig großartig überzeugend]
(process:30133): libfo-WARNING **: Unsupported property: Not a GObject: 0x847cf90
[Am Ende dann]
libfo-ERROR **: area_size_request:: parent is NULL
aborting...
zsh: 30133 abort ./xmlroff ~/docs/docbook/article.fo
Na _das_ ist ja mal eine überzeugende Leistung! Immerhin ist das mal
eine echt überzeugende Performance, das Teil braucht nicht mal eine
Sekunde, um sich mit der Assertion zu verabschieden!
Sure it doesn't work but look how fast it is!
Immerhin handelt es sich um eine knackige kompakte hochoptimierte
Minimalimplementation, wie man schon an der Dateigröße sofort sehen
kann:
-rwxr-xr-x 1 leitner users 3979308 Apr 29 02:00 xmlroff
BTW:
libpangopdflib-1.0.so.0 => /usr/local/lib/pangopdf/libpangopdflib-1.0.so.0 (0x40015000)
libz.so.1 => /usr/lib/libz.so.1 (0x4004f000)
libpango-1.0.so.0 => /usr/local/lib/pangopdf/libpango-1.0.so.0 (0x4005b000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40089000)
libdl.so.2 => /lib/libdl.so.2 (0x4008d000)
libm.so.6 => /lib/libm.so.6 (0x40091000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400b3000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40103000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40130000)
libc.so.6 => /lib/libc.so.6 (0x4018d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x402bb000)
libpdf.so.1 => /usr/lib/libpdf.so.1 (0x40301000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Nur falls mir jetzt jemand vorwirft, ich würde maliziös statisch linken.
Und ich dachte, ich bin schlimme Sachen gewöhnt. Ich muß mich ja im
Gegenteil glücklich schätzen, bisher vom gröbsten verschont geblieben zu
sein.
Hach, wie vermisse ich die Tage der Unschuld und naiven Freude!
Felix
--
Don't worry about things that you have no control over, because you
have no control over them. Don't worry about things that you have
control over, because you have control over them.
--Mickey Rivers
Nico Erfurth
> Hach, wie vermisse ich die Tage der Unschuld und naiven Freude!
Da, nimm ein paar getrocknete Froschpillen.
Nico
Felix von Leitner
> Sun-Software probiert, um aus FO etwas brauchbares zu machen!
Siehe da, es gibt einen Weg, aus FO ein brauchbares PDF zu machen, und
dieser Weg terminiert sogar in endlicher Zeit.
Der Weg läuft über... TeX!
Kann mir jemand hier erklären, wieso ich mir diesen XML-Scheiß antun
soll, der
a) eine noch grausigere Syntax als TeX hat
b) alles noch viel langsamer macht als TeX
c) dabei offenbar auch noch weniger mächtig als TeX ist
d) um dann am Ende doch alles durch pdftex zu jagen?
Reicht es nicht, daß einem diese Leute Schmerzen zufügen, muß man sich
auch noch verspotten lassen?!
Das ist ja eine Travestie sondergleichen. SAP und Oracle unter NT sieht
von Minute zu Minute besser aus, je tiefer ich in diesem Sumpf hier
versinke.
Also ich denke mal, ich habe jetzt genug von XML und DocBook gesehen.
Das reicht für ein Leben. Laufen die Loser eigentlich noch frei herum,
die sich diese unerträglichen Müll ausgedacht haben?
Felix
Felix von Leitner
> http://www.sagehill.net/xml/docbookxsl/
Das ist in der Tat die einzige Dokumentation zum Thema, die den Namen
Dokumentation auch verdient. Ohne diesen Text hätte ich das überhaupt
nicht zu Laufen gebracht. Das ganze Geschreibsel der anderen Leute, die
das zu benutzen behaupten, kann man komplett in der Pfeife rauchen.
Aber was erwartet man auch von Experten wie GNOME, Debilian und KDE...
> Welcher Verlag denn?
O'Reilly.
> Die Anzahl der Flueche und Verwuenschungen duerfte recht ordentlich
> steigen. DocBook XML ist wirklich schmerzhaft, aber die Alternativen
> sind das auch. Alles sehr unbefriedigend, aber was will man machen...
Mit TeX bin ich bisher ausgesprochen gut gefahren. Klar ist das auch
sehr fummelig, da z.B. neue Fonts zu installieren. Aber im Vergleich zu
den XML-Verrenkungen gerade ist das geradezu ein Spaziergang im Park.
Felix
Kristian Köhntopp
> Juchee! Ich habe xsltproc dazu bewegen können, daß er meinen
> Hallo-Welt-Article parsen und nach HTML und/oder FO
> transformiert!
xslt, was? Wir kombinieren das Paradigma von awk mit der
sprachlichen Eleganz von Cobol und den programmiertechnischen
Verrenkungen von funktionalen Sprachen unter sorgfältiger
Umgehung aller möglichen Vorteile.
> Ich will mir
> gar nicht vorstellen, wie langsam und unzumutbar das alles mit
> SGML wäre... *grusel*
Richtig, das willst Du nicht. NOT recovery.
Kristian
Holger Marzen
> Also ich denke mal, ich habe jetzt genug von XML und DocBook gesehen.
> Das reicht für ein Leben. Laufen die Loser eigentlich noch frei herum,
> die sich diese unerträglichen Müll ausgedacht haben?
Puh, und ich wollte mir an einem ruhigen Abend DocBook zu Gemüte führen.
Gut dass *du* der Depp warst, der vor mir drauf reingefallen ist, hrhr.
Ich glaube, es wäre wirklich ein klitzekleines Problem gewesen, das
Zeug auf meinem P1/233 mit libc5 zum Laufen zu bringen.
Lars Marowsky-Bree
> Kann mir jemand hier erklären, wieso ich mir diesen XML-Scheiß antun
> soll, der
Weil es standarisiert ist! Und sich ganz geil automatisch parsen und filtern
lässt! Weil man es so klasse ins Web stellen kann!
Aber der wahre Grund...
WEIL DIE GANZE WELT VOLLER IDIOTEN IST, die von ihrer eigenen Unfähigkeit
ablenken müssen.
HTH.
Ja, bei uns setzt sich das auch langsam durch. Ich verstehe es auch nicht. OK,
Tabellen in (La)?TeX sind eklig, aber als ob Docbook besser wäre...
Marc Haber
Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
aus Docbook.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Lars Marowsky-Bree
<mh+use...@zugschl.us> wrote:
>>Ich bleib bei TeX, vielen Dank.
> Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
> aus Docbook.
Das ist aber auch das einzige Problem.
Ich glaube auch, das sich das mit weniger Einsatz lösen liesse als Docbook zu
benutzen, zumindest hochgerechnet über 5-10 Entwickler.
Frank Schmitt
> Felix von Leitner <usenet-...@fefe.de> wrote:
>>Ich bleib bei TeX, vielen Dank.
>
> Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
> aus Docbook.
Aus Docbook HTML machen ist Kindergeburtstag. Will man jedoch texinfo,
dann muss man sich auf echte Schmerzen gefasst machen. (Und auch bei
Nurtext Ausgabe haben wir noch nichts schmerzfreieres als
# XML source file
BASENAME=gnus-faq
SOURCE=$(BASENAME).xml
# docbook XSL stylesheet parameter file - generic and specialized
PARAMS=xsl/docbook-params.xsl
TXTPARAMS=xsl/docbook-txt-params.xsl
gnus-faq.txt: gnus-faq.xml $(PARAMS) $(TXTPARAMS)
$(XMLTO) -m $(TXTPARAMS) -o $(TXTDIR) html-nochunks $(SOURCE)
$(SED) 's$$<a href="\([^#][^"]*\)"[^>]*>\([^<]*\)</a>$$\2 [\1]$$g' < $(TXTDIR)/$(BASENAME).html > $@.tmp
$(W3M) -T text/html -cols 68 -dump $@.tmp > $@ || (s=$$?; rm -f $@; exit $$s)
rm -f $@.tmp $(TXTDIR)/$(BASENAME).html
gefunden).
--
WANTED: A nice signature
REWARD: none
Wolfgang Kaufmann
Hallo,
> * On 29 Apr 2003 00:26:23 GMT, Felix von Leitner wrote:
>> Also ich denke mal, ich habe jetzt genug von XML und DocBook gesehen.
>> Das reicht für ein Leben. Laufen die Loser eigentlich noch frei herum,
>> die sich diese unerträglichen Müll ausgedacht haben?
>
> Puh, und ich wollte mir an einem ruhigen Abend DocBook zu Gemüte führen.
> Gut dass *du* der Depp warst, der vor mir drauf reingefallen ist, hrhr.
Ich war auch mal so naiv und hatte mir DocBook aufschwatzen zu lassen
und wollte mir ein paar Tage vor dem 19C3 das nochmal genauer anschauen.
Nach zwei Tagen hatte ich die Existenz von DocBook zur Gänze verdrängt,
andernfalls wäre suizid wohl der einzige Ausweg aus dem Irrenhaufen
gewesen. Aber es gibt tatsächlich Leute, die das klasse finden. Und auf
doc...@lists.oasis-open.org liest sich alles ja auch ganz harmlos.
Mittlerweile konnte ich immerhin selbst sehen, dass das Ganze
tatsächlich 'funktioniert'.
> Ich glaube, es wäre wirklich ein klitzekleines Problem gewesen, das
> Zeug auf meinem P1/233 mit libc5 zum Laufen zu bringen.
Man kann sich wahrlich angenehmeres vorstellen.
Tschüss,
Wolfgang.
--
"Es gibt Diebe, die nicht bestraft werden und einem doch das Kostbarste
stehlen: die Zeit."
-- Napoleon Bonaparte
Lutz Donnerhacke
> Wie bist du eigentlich auf die wahnsinnige Idee gekommen,
> das von Hand installieren zu wollen?
Jeder normale Mensch installiert von Hand.
Christian Bauer
>Bei Mittlerem läßt sich docbook wirklich total einfach installieren:
># apt-get install docbook docbook-xml
>
>Das zieht im Schnitt 30-50 zusätzliche Pakete an, tut dann aber
>anschließend (zumindest schon zwei Mal[4] bei mir) tatsächlich.
Ist ja auch unglaublich schwierig einen Sack XSL-Stylesheets und die DTD
zu "installieren". Ich glaube Du redest nicht von DocBook XML/XSL,
sondern dem noch wesentlich uebleren DSSSL/SGML-Setup mit dranhaengener
Toolchain. Das will man nicht.
>Habe mal einen kurzen Artikel von einem O'Reilly-Autor
>(weiß nicht mehr welcher) gelesen, in dem er beschrieb
>wie toll das Bücherschreiben mit Docbook doch sei.
>Interessanterweise hat er die Installation komplett ausgelassen.
Weil es ein non-issue ist mit XML/XSL. Vorausgesetzt man ist in der Lage
eine JRE zu verwenden. Fuer HTML saxon.jar, fuer PDF fop/batik.jar.
>Ich fand das XML an sich gar nicht mal soooo schlecht.
Was nu?
--
Christian Bauer
tu...@incubus.de
Felix von Leitner
> Wie bist du eigentlich auf die wahnsinnige Idee gekommen,
> das von Hand installieren zu wollen?
Ich installiere alles von Hand, bevor ich es benutze.
Software, die sich nicht von Hand installieren läßt, oder dabei
signifikant Widerstand leistet, kommt mir nicht auf die Platte.
Das hat mir bisher sehr erfolgreich Schmerzen vom Hals gehalten.
Erst jetzt sehe ich, wie erfolgreich.
> > Mit TeX bin ich bisher ausgesprochen gut gefahren. Klar ist das auch sehr
> > fummelig, da z.B. neue Fonts zu installieren. Aber im Vergleich zu den
> > XML-Verrenkungen gerade ist das geradezu ein Spaziergang im Park.
> Ich fand das XML an sich gar nicht mal soooo schlecht.
Nein, aber was nützt das schon?
Altägyptisch ist sicher auch gar nicht mal sooo schlecht, immerhin hat
damit die damals dominierende Hochzivilisation gearbeitet.
Felix
--
18. Beware of strangers bearing tools such as chain saws, staple guns,
hedge trimmers, electric carving knives, combines, lawn mowers, butane
torches, soldering irons, band saws, or any device made form deceased
companions. --Horror Movie Survival Guide
Felix von Leitner
> >Ich bleib bei TeX, vielen Dank.
> Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
> aus Docbook.
Wieso würde jemand aus TeX HTML erzeugen wollen?
In TeX bilde ich Briefe, Papers und Bücher ab. Die kommen als PDF ins
Web, wenn sie überhaupt ins Web kommen.
In HTML bilde ich Glue und vielleicht mal ne FAQ ab.
Die Schnittmenge ist leer.
Felix
Felix von Leitner
> aus Docbook.
Mir fällt gerade auf, daß das überhaupt kein Problem ist.
Du benutzt pdftex, stellst das Dokument ins Web, und läßt Google drüber
laufen. Danach läßt du dir von Google das PDF als HTML rendern ;)
Und es gibt wohl auch außerhalb von Google PDF-nach-HTML Konverter. Und
weniger taugen als diese XML-Grütze können die wohl kaum.
Felix
Marc Haber
>
>In TeX bilde ich Briefe, Papers und Bücher ab. Die kommen als PDF ins
>Web, wenn sie überhaupt ins Web kommen.
>
>In HTML bilde ich Glue und vielleicht mal ne FAQ ab.
Kundendoku, die dem Kunden bei Übergabe des Systems auf Papier in die
Hand gedrückt wird, und von der regelmäßig aktualisierte Versionen für
das Web erzeugt wird.
PDF finde ich für solche Informationen ätzend, das sollen normale
Webseiten sein.
Deine Google-Idee scheidet aus, weil die hier erzeugten Webseiten nur
für den Kunden sichtbar sein sollen.
Kurt Bernhard Pruenner
> xslt, was? Wir kombinieren das Paradigma von awk mit der
> sprachlichen Eleganz von Cobol und den programmiertechnischen
> Verrenkungen von funktionalen Sprachen unter sorgfältiger
> Umgehung aller möglichen Vorteile.
FdI #363?
--
Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria
.......It might be written "Mindfuck", but it's spelt "L-A-I-N".......
np: Schneider TM - DJ Guy? (Zoomer)
Ingo Oeser
Wenn du das woelltest, warum liest du Zeitung, News, Mailinglisten,
Webseiten?
Wissen ist Macht, aber Macht nimmt einem die Unschuld.
Grusz
Ingo
--
Marketing ist die Kunst, Leuten Sachen zu verkaufen, die sie
nicht brauchen, mit Geld, was sie nicht haben, um Leute zu
beeindrucken, die sie nicht moegen.
Ingo Oeser
> sehr fummelig, da z.B. neue Fonts zu installieren. Aber im Vergleich zu
> den XML-Verrenkungen gerade ist das geradezu ein Spaziergang im Park.
Eben. Waere es zu kompliziert, haette irgendjemand ein Tool geschrieben,
dasz sowas macht.
Wenn LaTeX ein paar nette Stilvorlagen haette, waere das laengst
ein weitverbreiteter Unternehmensstandard zum Austausch von Dokumenten.
Aber die TeXniker basteln halt zu gerne, oft aber nicht gut genug, um es
zu veroeffentlichen (mich eingeschlossen).
Florian Weimer
> Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
> aus Docbook.
Die beste Lösung ist zur Zeit immer noch, eine
Ad-hoc-Auszeichnungssprache zu verwenden, wobei die syntaktische
Ausprägung sicherlich von der Entwicklungsumgebung abhängt.
Eigentlich ist es traurig. Ich beabsichtige aber, mir mit der Zeit ein
Rahmenwerk dafür zu basteln (und nur die Funktionen zu implementieren,
die ich wirklich brauche), so daß das relativ schnell geht.
Andreas Bogk
> Welcher Verlag denn? Ich war bei meinem der Erste, sorgt momentan fuer
> grosses Chaos bei den FrameMakern.
Erm, zeige ihnen FrameMaker+SGML. Sie werden dich lieben.
FrameMaker+SGML ist im übrigen auch die einzig mir bekannte
funktionierende Docbook-Lösung mit allen Schikanen. Und natürlich ist
das SGML im Namen geschichtlich gewachsen, der spricht auch XML.
Gruss Andreas
--
"Share your knowledge. It's a way to achieve immortality."
-- His Holiness the 14th Dalai Lama Tenzin Gyatso
Marc Haber
>Marc Haber <mh+use...@zugschl.us> writes:
>> Es ist aber IMO sehr viel unangenehmer, aus TeX HTML zu erzeugen als
>> aus Docbook.
>
>Die beste Lösung ist zur Zeit immer noch, eine
>Ad-hoc-Auszeichnungssprache zu verwenden, wobei die syntaktische
>Ausprägung sicherlich von der Entwicklungsumgebung abhängt.
We re-invent every wheel?
Lars Marowsky-Bree
<mh+use...@zugschl.us> wrote:
>>Die beste Lösung ist zur Zeit immer noch, eine
>>Ad-hoc-Auszeichnungssprache zu verwenden, wobei die syntaktische
>>Ausprägung sicherlich von der Entwicklungsumgebung abhängt.
> We re-invent every wheel?
Das "new wheel syndrome" ist ärgerlich, wenn dabei echt große Arbeit
repliziert wird.
Das "Wir brauchen eine große abstrakte Lösung um kleine Räder zu vermeiden"
ist nur die Angst-Reaktionen von jenen, die selbst mit kleinen
maßgeschneiderten Lösungen überfordert wären, und dann ihre Unfähigkeit hinter
dem feisten Teil verstecken. Siehe XML, Java...
Erhard Schwenk
> Juchee! Ich habe xsltproc dazu bewegen können, daß er meinen
> Hallo-Welt-Article parsen und nach HTML und/oder FO transformiert!
Naja, so weltbewegend kompliziert ist XSLT auch wieder nicht. Eigentlich
sogar recht simpel.
> article.xml ist 844 Bytes groß. Ihr könnt euch sicher vorstellen, wie
> hochkomplex die Formatierungen dort sind.
>
> Warum xsltproc? Weil ich überall gelesen habe, daß das der mit Abstand
> schnellste Transformator sei, der um Größenordnungen über allen
> Alternativen liegt und so weiter. Das Teil ist immerhin in
> hochoptimiertem C geschrieben, und löst ein doch sehr überschaubares
> Problem, zu dem das wohl aussehende Typesetting noch _nicht_ gehört.
Hmm sabcmd war mit meinen Stylesheets immer einen Hauch schneller. Beide
haben ein paar Macken, mit denen man aber ganz gut leben kann, solang
man nur HTML, WML oder O als Output braucht gehts jedenfalls brauchbar.
> Erstaunlich, daß so ein Tool anderthalb Megabyte groß ist!
> Noch erstaunlicher, daß dieses unglaublich performante Tool für ein
> Hallo-Welt XML-File über zwei Sekunden frißt!
Hmm probier mal, die Network Lookups abzuschalten, das Suchen der DTDs
frißt u.U. etwas Zeit. Und sabcmd war hier wie gesagt auch einen Hauch
schneller. Je nach Konstruktion kann man auch beim Stylesheet viel Zeit
kaputtmachen.
--
Erhard Schwenk
Kulturskandal: Stuttgart will einziges deutsches Bewegungstheater
schließen. Makal-City-Theater vor dem Aus. http://mct.k-itx.net/
Alexander Schreiber
Nein. Ich habe @$ORKPLACE mittlerweile fuer unsere UNIXer-Gruppe LaTeX
als Standard fuer die Doku eingefuehrt. Zusammen mit CVS, damit man
vernuenftig mit ein paar Leuten dran arbeiten kann. Daraus fallen dann
PDFs zum Lesen (oder noetigenfalls tote Baeume damit bedrucken) sowie per
cronjob HTML + PDF als Version auf dem internen Webserver.
Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber
>
>Nein, aber was nützt das schon?
>Altägyptisch ist sicher auch gar nicht mal sooo schlecht, immerhin hat
>damit die damals dominierende Hochzivilisation gearbeitet.
Und wo sind sie jetzt? Alle tot, richtig. Wenigstens steht von dem Zeug,
dass sie gebaut haben, noch einiges. Von unserer Zeit werden wohl nur
die Muellhalden ueberdauern.
Bodo Eggert
> FdI #363?
/unterschreib/
--
Top 100 things you don't want the sysadmin to say:
89. I got a better job at Lockheed...
Stefan Reuther
> Felix von Leitner wrote:
>> Juchee! Ich habe xsltproc dazu bewegen können, daß er meinen
>> Hallo-Welt-Article parsen und nach HTML und/oder FO
>> transformiert!
> xslt, was? Wir kombinieren das Paradigma von awk mit der
> sprachlichen Eleganz von Cobol und den programmiertechnischen
> Verrenkungen von funktionalen Sprachen unter sorgfältiger
> Umgehung aller möglichen Vorteile.
Kommt mir irgendwo her bekannt vor.
Eine "Sprache", in der man
<xsl:call-template name="foo">
<xsl:with-param name="arg">blubber</xsl:with-param>
</xsl:call-template>
schreiben muß, wo jeder andere
foo(blubber)
schreibt, *muß* irgendwie ein Erfolg werden. Jedenfalls für
Festplatten- und Speicherverkäufer.
Auch ich habe den Fehler gemacht, ein größeres Projekt mit
XML/XSLT zu erstellen. Der einzige Grund für diese Wahl: am Ende
sollte HTML rausfallen, und es gab fertige Tools. Für eine
Aufgabenstellung a la "ersetze <file> durch <tt class="file">"
oder "Liste aller <h1> am Anfang der Seite" taucht das sogar,
und liefert hinreichende Performance.
Aufgabenstellung: ein Dokument beschreibt eine Konfigurations-
datei, die Konfiguration besteht aus ca. 300 möglichen Optionen.
Am Ende soll ein automatisch generierter Index der Form
A
Ananas
Apfel
B
Banane
Birne
herausfallen (man beachte die Trenn-Buchstaben).
Nebenbedingung: es gibt ein "Template" "indexl", welches alle
Index-Einträge mit einem bestimmten Anfangsbuchstaben ausgibt.
Lösung 1:
<xsl:for-each select="//config">
<xsl:sort select="@name" />
<xsl:variable name="letter" select="substring(@name, 1, 1)"/>
<xsl:if test="not(preceding::node()[starts-with(@name, $letter)])">
<xsl:call-template name="indexl"><xsl:with-param name="letter" select="$letter"/></xsl:call-template>
</xsl:if>
</xsl:for-each>
Laufzeit von *mindestens* O(n^2*logn) für etwas, das jeder normal
denkende Mensch in O(nlogn) hinbekommt. Braucht dementsprechend
auch knapp 10 Minuten für die Transformation. Ich erinner
nochmal daran, daß das ganze eigentlich für Live-Transformation
auf einem Webserver gedacht war.
Lösung 2:
<xsl:call-template name="indexl"><xsl:with-param name="letter" select="'A'"/></xsl:call-template>
<xsl:call-template name="indexl"><xsl:with-param name="letter" select="'B'"/></xsl:call-template>
<xsl:call-template name="indexl"><xsl:with-param name="letter" select="'C'"/></xsl:call-template>
...
<xsl:call-template name="indexl"><xsl:with-param name="letter" select="'Z'"/></xsl:call-template>
benötigt knapp 2 Minuten. Nicht wirklich tolerabel, aber was
will man machen... Kann leider keine Umlaute. Für etwas, das
Unicode unterstützt, gar keine schlechte Leistung.
>> Ich will mir gar nicht vorstellen, wie langsam und unzumutbar
>> das alles mit SGML wäre... *grusel*
> Richtig, das willst Du nicht. NOT recovery.
Gibt es eine Methode, schicke, *wartbare* HTML-Seiten zu
erstellen, die Recovery ist?¹
Eine "XML"-Transformation für ein anderes Projekt habe ich nun in
Perl geschrieben. 0.5 Sekunden für ca. 100k Dokument. Aufgabe:
gegeben N Zeitlinien ("<event time="2001/12/05">...</event>"),
die in die chronologische Reihenfolge zu bringen und schließlich
zu verketten sind ("nächstes Ereignis für dieses Objekt").
Erschwerende Bedingung: es gibt nicht zu jedem Ereignis einen
time-Eintrag. Eigentlich ist ja nur ein mergesort zu
implementieren. Ob und wie das in XSLT zu lösen gewesen wäre,
darüber mag ich gar nicht nachdenken.
Stefan
--
[1] Nein, "Netscape Navigator Gold" zählt nicht :-)
Kristian Köhntopp
> Gibt es eine Methode, schicke, *wartbare* HTML-Seiten zu
> erstellen, die Recovery ist?¹
Roxen wird ja leider nicht mehr so richtig promoted, also könnte
man auf Caudium ausweichen.
Will man auch eine Community, muß man erst die Krankheit, die
expat ist, fixen und dann mit XML_Transformer aus PEAR arbeiten.
Dann hat man quasi Roxen-Technik als PHP.
Kristian
Dietz Proepper
> On Tue, 29 Apr 2003 22:43:31 +0200, Marc Haber
> <mh+use...@zugschl.us> wrote:
>
>>>Die beste Lösung ist zur Zeit immer noch, eine
>>>Ad-hoc-Auszeichnungssprache zu verwenden, wobei die syntaktische
>>>Ausprägung sicherlich von der Entwicklungsumgebung abhängt.
>> We re-invent every wheel?
Wenn die vorhandenen Räder nicht passen dann ist dies die einzige
Möglichkeit. Wobei "Passen" von vielen, nicht notwendigerweise technischen
Gründen abhängt.
> Das "new wheel syndrome" ist ärgerlich, wenn dabei echt große Arbeit
> repliziert wird.
s/große/brauchbare/
> Das "Wir brauchen eine große abstrakte Lösung um kleine Räder zu
> vermeiden" ist nur die Angst-Reaktionen von jenen,
Du willst Hanlon's razor verstehen. Die Leute haben keine Angst. Sie sind
einfach nur unfähig, kurzsichtig, verbohrt, in 1 a weg usw.. Um Angst zu
empfinden ist ein Minimum an Intelligenz nötig.
> die selbst mit kleinen
> maßgeschneiderten Lösungen überfordert wären,
Für jemanden der bei Suse arbeitet kritisierst Du sonderbare Dinge.
> und dann ihre Unfähigkeit
> hinter dem feisten Teil verstecken. Siehe XML, Java...
Lustig wird es wenn man mit den letztgenannten trotzdem etwas performantes
zaubert. Was wiederum erfordert daß man die specs nicht nur soweit liest
daß man eine Lösung des Problems implementieren kann sondern das Vorhandene
optimal ausnutzt. Man *kann* auch in Java mehr oder minder performantes
scheiben. Man muß nur das Geschwätz der Erleuchteten ignorieren. Kürzlich
erst wieder: Java-Programm, ca 80000 loc, läuft "zu langsam" (vulgo, 4
Anwender saturieren eine E450). Tja, einiges profiling später konnte man
als "Schuldigen" eine Klasse (bzw. einige ihrer Methoden) und deren
Verwendung durch Dritte identifizieren. Einige seds und Flüche später hat
man den Attributen wo es nicht stört den accessor entzogen, einige Methoden
static gemacht, einige Klassen finalisiert und einige äußerst ungeschickte
Stringmanipulationen entfernt. Speedup um Faktor 20 oder so, d.h. die
Maschine beginnt so ab 80 konkurrierenden Zugriffen ernsthaft zu arbeiten.
Eine "optimale" Implementierung wäre vielleicht nochmal um 25%
performanter, ein sinnvolleres Design vielleicht um 100%.
Soweit, so schön. Nun zu dem Teil mit den hirntoten Idioten. Nachdem ich mit
obigem fertig bin und die Änderungen in den Test gegangen sind kommt der
lead architect von $ag und meint, das sei ja alles Scheisse und überhaupt
sei das kein OO und überhaupt mache man das hier nicht so. Glücklicherweise
sah das der Projektleiter etwas differenziert.
Dietz
Lutz Donnerhacke
> Kurt Bernhard Pruenner <9sjs...@sneakemail.com> wrote:
>> FdI #363?
>
> /unterschreib/
Wäre es möglich erst zu schauen, und dann zu posten? Danke.
Thomas Seck
> Will man auch eine Community, muß man erst die Krankheit, die
> expat ist, fixen und dann mit XML_Transformer aus PEAR arbeiten.
> Dann hat man quasi Roxen-Technik als PHP.
Ah! Open-Source Buzzword-Bingo!
--Thomas
Florian Weimer
>>Die beste Lösung ist zur Zeit immer noch, eine
>>Ad-hoc-Auszeichnungssprache zu verwenden, wobei die syntaktische
>>Ausprägung sicherlich von der Entwicklungsumgebung abhängt.
>
> We re-invent every wheel?
Die Kosten für existierende Lösungen sind häufig so hoch, daß sie das
rechtfertigen (auch wenn sie teilweise sehr versteckt sind). Ich würde
das Selbermachen natürlich nicht jedem empfehlen.
christian mock
> Seit ungefähr Stunden bin ich hier am Testen, Kompilieren und
> Installieren und nicht eine Software kommt mit nutzbringender
> Dokumentation, nicht ein HOWTO beschreibt eine funktionierende
> Dokumentation und nicht ein Beispieldokument läßt sich mit auch nur
> einer der Implementationen "einfach so" (call me naive...) übersetzen.
soweit kann ich dir ja noch zustimmen...
> Kann es sein, daß eine derartig gehypete Technologie, die seit Jahren
> standardisiert und (supposedly) dokumentiert ist, in der bekannte
> Verlage ihre Manuskripte verfassen, so was von überhaupt nicht
> funktioniert?
...aber hier frag ich mich dann schon, um wieviel groesser dein hier
ja immer wieder zur schau gestelltes maul ist als die faehigkeiten
dahinter.
ich hab's jedenfalls letzte woche geschafft, innerhalb von ca. 2
stunden mein erstes docbook-xml "book" zu erstellen und mich am
postscript-output zu erfreuen[0].
jedenfalls fuehlt sich docbook besser an als lout[1], mit dem ich
vorher meine dokus gemacht habe, gar nicht zu reden von TeX, das zwar
wunderschoenen output produziert, aber dermassen barock an allen ecken
und enden ist...
cm.
[0] ja, zwischen einem "hello, world" mit titelseite und
inhaltsverzeichnis und einer vollstaendigen 50 seitigen doku
liegen welten, und die beschaeftigung mit den stylesheets, dass
der output so ausschaut, wie ich will, hab ich auch noch
aufgeschoben -- zuerst muss ich den text fertigmachen.
[1] http://snark.ptc.spbu.ru/~uwe/lout/lout.html
--
Hat irgendwer schlechte Schwingungen in seiner globalen
Eierkuchen-Aura bekommen weil man ihm gesagt hat er soll bitte nicht
andauernd mit Vollquotes in 10 Gruppen gleichzeitig crossposten?
Albert Koellner in at.usenet
Kristian Köhntopp
Hier die Hyper-Version:
Will man auch eine Community
(http://marc.theaimsgroup.com/?l=pear-dev), muß man erst die
Krankheit, die expat ist, fixen
(http://lxr.php.net/source/php4/ext/xml/expat/xmlparse.c,
http://marc.theaimsgroup.com/?l=pear-dev&m=104703799905066&w=2)
und dann mit XML_Transformer
(http://pear.php.net/package-info.php?pacid=37) aus PEAR
(http://pear.php.net/manual/en/faq.php) arbeiten. Dann hat man
quasi Roxen-Technik (http://docs.roxen.com/roxen/3.3/index.xml)
als PHP
(http://www.koehntopp.de/kris/artikel/xml-transformer/img3.html)
Kristian
Stefan Reuther
Kristian Köhntopp <kr...@koehntopp.de> wrote:
> Thomas Seck wrote:
>> * Kristian Köhntopp (kr...@koehntopp.de):
>>> Will man auch eine Community, muß man erst die Krankheit, die
>>> expat ist, fixen und dann mit XML_Transformer aus PEAR
>>> arbeiten. Dann hat man quasi Roxen-Technik als PHP.
>>
>> Ah! Open-Source Buzzword-Bingo!
> Hier die Hyper-Version:
Da fe lte aber noch einiges. Ich schreib's einfach mal rein.
# Will man auch (http://www.metoo.com/) eine Community
# (http://marc.theaimsgroup.com/?l=pear-dev), muß man erst
# (http://www.kirchwitz.de/~amk/dni/erst-lesen-dann-schreiben)
# die Krankheit (http://netdoktor.de/), die expat
# (http://www.jclark.com/xml/expat.html) ist, fixen
# (http://lxr.php.net/source/php4/ext/xml/expat/xmlparse.c,
# http://marc.theaimsgroup.com/?l=pear-dev&m=104703799905066&w=2)
# und (http://www.usenetdigest.de/) dann (http://www.dannglenn.com/)
# mit XML_Transformer (http://pear.php.net/package-info.php?pacid=37)
# aus PEAR (http://pear.php.net/manual/en/faq.php) arbeiten. Dann hat
# man (http://www.freebsd.org/docs.html#man) quasi Roxen-Technik
# (http://docs.roxen.com/roxen/3.3/index.xml) als PHP
# (http://www.koehntopp.de/kris/artikel/xml-transformer/img3.html)
#
# Kristian (http://koehntopp.de/)
In der Hoffnung nichts vergessen zu haben,
Stefan
Ralf Döblitz
[...]
> Gibt es eine Methode, schicke, *wartbare* HTML-Seiten zu
> erstellen, die Recovery ist?¹
Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am besten
von allen Varianten, die ich probiert habe.
Ralf
--
Ralf Döblitz * Schapenstr. 6 * 38104 Braunschweig * Germany
Phone: +49-531-2361223 Fax: +49-531-2361224 mailto:doeb...@gmx.de
Homepage: http://www.escape.de/users/selene/
Florian Weimer
> Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
> besten von allen Varianten, die ich probiert habe.
HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
Auszeichnung und Aussehen. Außerdem halte ich es mittlerweile für
sinnvoll, soviel wie möglich statisch zu erzeugen, so daß man simple
Webserver verwenden kann.
Meine sonstigen Erfahrungen mit HTML::Mason sind dagegen eher positiv,
insbesondere für nichtöffentliche Anwendungen.
Lars Marowsky-Bree
<f...@deneb.enyo.de> wrote:
> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
> Auszeichnung und Aussehen. Außerdem halte ich es mittlerweile für
> sinnvoll, soviel wie möglich statisch zu erzeugen, so daß man simple
> Webserver verwenden kann.
Ich benutze den Template Toolkit mit ein paar eigenen Strickereien. (Und
manchmal, wenn mich die make installs ärgern, blamiere ich mich auf der
Mailingliste)
Ich generiere alles statisch, aber zugegeben nur "begrenzt" vom Content
getrennt - statt <A HREF=...> schreibe ich zB [% link(...) %], was automatisch
Cross-Referenzen, evtl Tagging des Links mit Sprachfähnchen etc generiert.
Ich habe mir die ganze Kotze von "fertigen" "Content Management Systemen"
angeguckt, versucht mich einzuarbeiten und angefangen zu kotzen ;-) Da erfinde
ich lieber in ein paar Minuten das Rad, was gerade so für mich passt, als mich
diesen Schmerzen auszusetzen.
Bodo Eggert
> ich hab's jedenfalls letzte woche geschafft, innerhalb von ca. 2
> stunden mein erstes docbook-xml "book" zu erstellen und mich am
> postscript-output zu erfreuen[0].
Du hast also nicht die "tollen" "hilfreichen" "howto"s gefunden und befolgt.
Schätze Dich glücklich, und schau Dir nicht an, wie der Müll aufgebaut ist.
--
O'Reilly's Gesetz für die Küche:
Sauberkeit ist fast unmöglich.
Bodo Eggert
> Das ist in der Tat die einzige Dokumentation zum Thema, die den Namen
> Dokumentation auch verdient. Ohne diesen Text hätte ich das überhaupt
> nicht zu Laufen gebracht. Das ganze Geschreibsel der anderen Leute, die
> das zu benutzen behaupten, kann man komplett in der Pfeife rauchen.
>
> Aber was erwartet man auch von Experten wie GNOME, Debilian und KDE...
Du beleidigsr elegante, durchdachte und zielführend programmierte Software.
Wrqrasnyyf vz Iretyrvpu.
--
Womit verhüten Emanzen - mit dem Gesicht.
-- Oskar Lafontaine
Stefan Reuther
>> Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
>> besten von allen Varianten, die ich probiert habe.
Schaut erstmal schick aus. Insbesondere als Ausrede, kein PHP
lernen zu wollen :-)
> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
> Auszeichnung und Aussehen. Außerdem halte ich es mittlerweile für
> sinnvoll, soviel wie möglich statisch zu erzeugen, so daß man simple
> Webserver verwenden kann.
Ich will auch statische Seiten erzeugen. Sonst würde ich keine
XML-Transformation einsetzen, die zwei Minuten braucht. Die
Seiten, die ich erzeuge, liegen unter <http://phost.de/phost4doc/>.
(Allerdings fällt mir nur ein Leser dieser GABELN ein, der sich
vielleicht noch für dieses Spiel interessiert. Ist aber recovery.)
Nuja, ich bleib dann wohl vorerst bei meinem ad-hoc Perl XML
Transformer. Das, was man an existenten Perl/XML-Dingen findet,
ist alles viel zu bloated. Was will ich mit internem Unicode-
Support, wenn die Ausgabe denselben Zeichensatz benutzt wie die
Eingabe? Warum '<' erst durch '<' ersetzen, um es dann wieder
zurückzuersetzen? Wozu 500 Perl Module und zig .so-Dateien, wenn
ein 50-Zeiler reicht? diet-xml anyone? *duck*
Stefan
Felix von Leitner
> Roxen wird ja leider nicht mehr so richtig promoted, also könnte
> man auf Caudium ausweichen.
Roxen war doch der einzige single task Webserver, der für statische
Seiten noch langsamer als Apache war, richtig?
Mein Mitleid hält sich in Grenzen, wenn das nicht mehr richtig promoted
wird.
> Will man auch eine Community, muß man erst die Krankheit, die
> expat ist, fixen und dann mit XML_Transformer aus PEAR arbeiten.
> Dann hat man quasi Roxen-Technik als PHP.
Mag sein. Nur: Wer würde das haben wollen?
Wenn ich ineffizienten Bloat haben will, kann ich auch gleich Python
oder Java benutzen.
Felix
Felix von Leitner
> Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am besten
> von allen Varianten, die ich probiert habe.
Kann mir mal jemand erzählen, wo der Vorteil von
print HTML::ATag(HTTP::Link(server => "www.fefe.de", port => 80, URI
=> "/fnord/", text => "fnord at fefe.de"))
gegenüber
print "<a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>"
sein soll, fange ich an, mir über HTML::Mason und ähnliche Hirntumore in
anderen Sprachen Gedanken zu machen.
Felix
Felix von Leitner
> > Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
> > besten von allen Varianten, die ich probiert habe.
> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
> Auszeichnung und Aussehen.
Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
Dieser ganze Transformations-Wahnsinn kostet nur Zeit und Geld und
bringt genau gar nichts. Und wenn dann mal jemand von Slashdot vorbei
kommt, bricht gleich die Site unter ihrem Eigengewicht zusammen.
> Außerdem halte ich es mittlerweile für sinnvoll, soviel wie möglich
> statisch zu erzeugen, so daß man simple Webserver verwenden kann.
ACK. $ cvs -d cvs.fefe.de:/cvs co enot
Ist Linux-only und im Moment bloß proof of concept.
Unter Linux mit pipelining und keep-alive habe ich über 16000 Requests
pro Sekunde über loopback gemessen. Benchmark liegt bei. Skaliert
nahezu unabhängig von der Anzahl der idle oder low-traffic Connections
daneben.
Das Problem, statische Seiten effizient auszuliefern, ist inzwischen gut
verstanden und kann aus technischer Sicht als gelöst betrachtet werden.
Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
allermeisten Fälle wie Zeitungen reicht das vollständig aus. Wer
wirklich dynamische Daten ins Web tun will, der kauft sich halt jemanden
ein, der sich damit auskennt, und der wird dann sicher keinen
XML-Bullshit machen, sondern eine funktionierende, zuverlässige und
skalierende Template-Engine.
Felix
Felix von Leitner
> >Juchee! Ich habe xsltproc dazu bewegen können, daß er meinen
> >Hallo-Welt-Article parsen und nach HTML und/oder FO transformiert!
> Naja, so weltbewegend kompliziert ist XSLT auch wieder nicht.
<loriot>Ach!</loriot>
Hey, mein XML und XSLT war von Anfang an korrekt, nur die l33t-XMl-T00lz
waren alle im Arsch.
> >Warum xsltproc? Weil ich überall gelesen habe, daß das der mit Abstand
> >schnellste Transformator sei, der um Größenordnungen über allen
> >Alternativen liegt und so weiter. Das Teil ist immerhin in
> >hochoptimiertem C geschrieben, und löst ein doch sehr überschaubares
> >Problem, zu dem das wohl aussehende Typesetting noch _nicht_ gehört.
> Hmm sabcmd war mit meinen Stylesheets immer einen Hauch schneller.
Ist Sablotron nicht sogar _noch_ größer?
> >Erstaunlich, daß so ein Tool anderthalb Megabyte groß ist!
> >Noch erstaunlicher, daß dieses unglaublich performante Tool für ein
> >Hallo-Welt XML-File über zwei Sekunden frißt!
> Hmm probier mal, die Network Lookups abzuschalten,
Alterlan, willst du mich beleidigen?
Da waren keine Netz-Lookups.
> das Suchen der DTDs frißt u.U. etwas Zeit.
Nein. Ein stat64, ein open, fertig. Es war alles korrekt eingerichtet.
Ich bin zwar stur und eingebildet, aber nicht blöd.
> Und sabcmd war hier wie gesagt auch einen Hauch schneller. Je nach
> Konstruktion kann man auch beim Stylesheet viel Zeit kaputtmachen.
Was du nicht sagst.
Und weil ich mir das schon gedacht habe, habe ich mich auf die Standard
Stylesheets von Docbook beschränkt. Man sollte ja annehmen, daß diese
Leute das können. Immerhin machen sie das schon ein Weilchen.
Felix von Leitner
Marc, wenn die bestehenden Räder alle scheiße sind, dann muß man ein
neues machen. Finde dich damit ab.
Felix von Leitner
> jedenfalls fuehlt sich docbook besser an als lout[1],
Ich finde lout nicht so abstoßend wie die meisten anderen Lösungen.
TeX benutze ich nur aus pragmatischen Gründen. Wenn es für DocBook ein
lout-Backend gäbe, wäre das mit größer Wahrscheinlichkeit die
effizienteste Ausgabemethode.
Sag mal, hast du kürzlich deine Email-Adresse geändert?
Ich erinnere mich vage, dich schon ein paar mal geplonkt zu haben, weil
du zu dämlich bist, Großbuchstaben zu verwenden.
Was solls, ein weiteres Mal schadet nicht. *plonk*
Christian Bauer
>Kann mir mal jemand erzählen, wo der Vorteil von
>
> print HTML::ATag(HTTP::Link(server => "www.fefe.de", port => 80, URI
> => "/fnord/", text => "fnord at fefe.de"))
>
>gegenüber
>
> print "<a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>"
>
>sein soll, fange ich an, mir über HTML::Mason und ähnliche Hirntumore in
>anderen Sprachen Gedanken zu machen.
Session-Tracking. man HTTP, stateless
--
Christian Bauer
tu...@incubus.de
Sebastian Posner
> Wenn ich ineffizienten Bloat haben will, kann ich auch gleich Python
> oder Java benutzen.
Marktlücke:
$SOFTWARE, die vordergründig mit Java *jegliche* CPU- und
Speicherressourcen frißt und hintergründig in Assembler programmiert ist
und genau so schnell $ERGEBNIS produziert wie hoch die monatlichen
Lizenzzahlungen des Kunden sind.
Sebastian, bringt prima Provisionen von $HARDWAREVENDOR und Kunde ist
glücklich weil er $BIGMONEY bezahlen darf, und es stehen immer noch
genug Leistungsreserven zur Verfügung, sollte Kunde die Zahlungen
erhöhen.
--
Hauke findet meine Signtur doof, deswegen hat er mich beim
Büssow verpetzt, und der hat jetzt meine .signature zensiert,
dieser .-%$§$%CARRIER LOST
Dietz Proepper
> Thus spake Florian Weimer (f...@deneb.enyo.de):
>> > Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
>> > besten von allen Varianten, die ich probiert habe.
>> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
>> Auszeichnung und Aussehen.
>
> Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
> CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
Ack. Und der Inhalt kommt woher?
> Dieser ganze Transformations-Wahnsinn kostet nur Zeit und Geld und
> bringt genau gar nichts.
Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken und
soll diese zusammenführen dann ist XSLT ein durchaus brauchbares Mittel.
> Und wenn dann mal jemand von Slashdot vorbei
> kommt, bricht gleich die Site unter ihrem Eigengewicht zusammen.
Wieso versucht Du zu behaupten, die Inhaltgenerierung müsse zum
Zugriffzeitpunkt passieren?
> Das Problem, statische Seiten effizient auszuliefern, ist inzwischen gut
> verstanden und kann aus technischer Sicht als gelöst betrachtet werden.
Eben.
> Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
> demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
Wer statischen (bzw. sich selten ändernden) content anders macht ist so oder
so unfähig. Und sobald man selten genug neugenerieren muß wird die Frage
der Generatorlaufzeit zunehmend uninteressant.
> allermeisten Fälle wie Zeitungen reicht das vollständig aus. Wer
> wirklich dynamische Daten ins Web tun will, der kauft sich halt jemanden
> ein, der sich damit auskennt, und der wird dann sicher keinen
Selbstverständlich.
> XML-Bullshit machen, sondern eine funktionierende, zuverlässige und
> skalierende Template-Engine.
Auch hier wieder - die Aufgabe bestimmt die Mittel. Wenn Du in der Situation
bist daß das Backend XML möchte und ausspuckt dann wirst Du wohl ebenfalls
XML-Bullshit machen. Wenn Du klug bist, allerdings nur an den
Schnittstellen, 1x in jede Richtung. Btw., wenn man Stringgenerierung in
Java und in C (via strcat) vergleicht dann sieht Java garnicht so schlecht
aus.
Dietz
Lars Marowsky-Bree
<dietz...@rotfl.franken.de> wrote:
> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken und
> soll diese zusammenführen dann ist XSLT ein durchaus brauchbares Mittel.
Das kommt auf die Art der Filterung an; ich habe mir das vor einiger Zeit mal
angeschaut und einige "Transformationen" gefunden, die damit nicht machbar
waren; es gab wohl fuer XSLT dann noch eine Weiterentwicklung, die mehr und
mehr Funktionen einer Programmiersprache aufzuweisen schien.
Mehr Details habe ich mir nicht gemerkt, aber ich kam zu dem Ergebnis, das XML
jetzt ja _eventuell_ als Datenformat noch tauglich ist, aber ca. 95% von dem,
was daran gefrickelt wird, postwendend in die Rundablage gehoert.
Schon komplexere syntaktische, ganz zu schweigen von semantischen,
Überprüfungen von XML Dokumenten sind mit DTD etc pp schwer möglich.
>> Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
>> demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
> Wer statischen (bzw. sich selten ändernden) content anders macht ist so oder
> so unfähig. Und sobald man selten genug neugenerieren muß wird die Frage der
> Generatorlaufzeit zunehmend uninteressant.
ACK.
> Auch hier wieder - die Aufgabe bestimmt die Mittel. Wenn Du in der Situation
> bist daß das Backend XML möchte und ausspuckt dann wirst Du wohl ebenfalls
> XML-Bullshit machen. Wenn Du klug bist, allerdings nur an den
> Schnittstellen, 1x in jede Richtung.
Strong ACK.
Sebastian Posner
>> Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
>> demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
> Wer statischen (bzw. sich selten ändernden) content anders macht ist so oder
> so unfähig.
Ack.
Und *richtig* übel wirds, wenn man das Ganze in Java "proggt" und es
aus politischen Gründen unter Slowlartus auf Hardware mit einer Sonne
drauf läuft.
BTST.
Sebastian
Dietz Proepper
> On Fri, 02 May 2003 17:58:59 +0200, Dietz Proepper
> <dietz...@rotfl.franken.de> wrote:
>
>> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken
>> und soll diese zusammenführen dann ist XSLT ein durchaus brauchbares
>> Mittel.
>
> Das kommt auf die Art der Filterung an; ich habe mir das vor einiger Zeit
> mal angeschaut und einige "Transformationen" gefunden, die damit nicht
> machbar waren;
> es gab wohl fuer XSLT dann noch eine Weiterentwicklung, die
> mehr und mehr Funktionen einer Programmiersprache aufzuweisen schien.
XSLT ist turing-vollständig ;). Und ich bin kein besonderer Freund davon.
Der Hauptvorteil, es ist ein "Standard", d.h. man hat u.U. Leute welche
einfache Transformationen schreiben können.
> Mehr Details habe ich mir nicht gemerkt, aber ich kam zu dem Ergebnis, das
> XML jetzt ja _eventuell_ als Datenformat noch tauglich ist,
Naja, es ist (sobald man einige Spezialfälle ausläßt) nicht allzu schwierig
zu parsen, und - es ist da. Andererseits - so schwierig ist es meist auch
nicht, einen Parser für irgendetwas wirklich problemorientiertes zu
schreiben. Spätestens wenn man saxend parst verschwimmt der "Vorteil"
zusehens.
> aber ca. 95%
> von dem, was daran gefrickelt wird, postwendend in die Rundablage gehoert.
Ack.
> Schon komplexere syntaktische, ganz zu schweigen von semantischen,
> Überprüfungen von XML Dokumenten sind mit DTD etc pp schwer möglich.
Naja, XML Schema geht etwas über DTDs hinaus, Du hast aber völlig Recht. Das
führt dann dazu daß der Aufwand zum Schreiben des Parsers sich dem für
beliebige, nicht hirntote Formate nähert. Von Dingen wie !US-ASCII mal
abgesehen ;).
Dietz
Holger Marzen
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> Ralf Döblitz <doeb...@doeblitz.net> writes:
>
>>> Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
>>> besten von allen Varianten, die ich probiert habe.
>
> Schaut erstmal schick aus. Insbesondere als Ausrede, kein PHP
> lernen zu wollen :-)
>
>> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
>> Auszeichnung und Aussehen. Außerdem halte ich es mittlerweile für
>> sinnvoll, soviel wie möglich statisch zu erzeugen, so daß man simple
>> Webserver verwenden kann.
>
> Ich will auch statische Seiten erzeugen. Sonst würde ich keine
> XML-Transformation einsetzen, die zwei Minuten braucht. Die
> Seiten, die ich erzeuge, liegen unter <http://phost.de/phost4doc/>.
|<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
|Transitional//EN"><html><head><title></title></head><body></body></html>
Naja, *das* generiere ich dir in einem Einzeiler.
Holger Marzen
> Felix von Leitner wrote:
>
>> Thus spake Florian Weimer (f...@deneb.enyo.de):
>>> > Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am
>>> > besten von allen Varianten, die ich probiert habe.
>>> HTML::Mason erlaubt von Haus aus keine wirkliche Separierung von
>>> Auszeichnung und Aussehen.
>>
>> Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
>> CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
>
> Ack. Und der Inhalt kommt woher?
>
>> Dieser ganze Transformations-Wahnsinn kostet nur Zeit und Geld und
>> bringt genau gar nichts.
>
> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken und
> soll diese zusammenführen dann ist XSLT ein durchaus brauchbares Mittel.
Wenn die Aufgabe lautet "Wählen Sie eine geeignete
Tabellenkalkulation aus, die Excel heißt und unter Windows läuft", ist
das Ergebnis auch nicht OpenOffice.
Wobei ich ganz stark vermute, dass man mit ein wenig selbstgeschriebenem
Perl das XML, das man im richtigen Leben aus irgendwelchen CMSen kriegt,
mit weniger Schmerzen und viel schneller aufbereiten kann.
Ralf Döblitz
In Mason ist außerhalb von Programmabschnitten erst mal alles nackter
Output. Du schreibst da laos sogar nur das hin, was du wirklich haben
willst:
<a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
Du _kannst_ aber auch Teile des Outputs berechnen, aus einer Datenbank
holen, andere Komponenten aufrufen, die Vererbungshierarchie nutzen
(yep, mit HTML::Mason ist zu einem gewissen Grad objektorientiertes
Design einer Webiste möglich) und ähnliches machen.
Wenn du das alles nicht brauchst, dann laß die Finger von HTML::Mason,
es wäre Overkill. Ansonsten erlaubt es Mason aber, seine Websites aus
kleinen, wiederverwendbaren Bausteinen zusammenzubauen, und das auch
noch in einer Form, die bei uns sogar die Mediengestalter verstehen, so
daß ich mich danach nicht mehr um die Pflege der Site kümmern muß, ein
Beispiel für die korrekte Anwendung reicht aus.
Für mich ist so etwas echt recovery-fördernd.
Markus Dobel
>
> In Mason ist außerhalb von Programmabschnitten erst mal alles nackter
> Output. Du schreibst da laos sogar nur das hin, was du wirklich haben
> willst:
> <a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
Dann kann man doch auch gleich PHP nehmen.
Gruss, Markus
--
Buy more duct tape.
Florian Weimer
>> Felix von Leitner wrote:
>>> Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
>>> CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
Ja, sicherlich. Hast Du das mal eingesetzt? Ist Dir dabei etwas
aufgefallen?
> * On Fri, 02 May 2003 17:58:59 +0200, Dietz Proepper wrote:
>> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken und
>> soll diese zusammenführen dann ist XSLT ein durchaus brauchbares Mittel.
Es mag ausgesuchte Spezialfälle geben, in denen dies funktioniert. Nur
denken offenbar viele, daß "ich habe XML" und "ich brauche eine andere
Art von XML" die Lösung "XSLT" impliziert, das ist aber schlichtweg
falsch.
> Wobei ich ganz stark vermute, dass man mit ein wenig selbstgeschriebenem
> Perl das XML, das man im richtigen Leben aus irgendwelchen CMSen kriegt,
> mit weniger Schmerzen und viel schneller aufbereiten kann.
Es gibt Berichte, daß die Leute heutzutage XML so parsen wie früher
andere Textdateien: Lange draufstarren, Strukturen erkennen und
Semantik erraten, Regular Expressions schreiben und hoffen, daß die
produzierende Seite nichts ändert.
Dietz Proepper
>> * On Fri, 02 May 2003 17:58:59 +0200, Dietz Proepper wrote:
>
>>> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken
>>> und soll diese zusammenführen dann ist XSLT ein durchaus brauchbares
>>> Mittel.
>
> Es mag ausgesuchte Spezialfälle geben, in denen dies funktioniert. Nur
Warum soll es nicht gehen?
> denken offenbar viele, daß "ich habe XML" und "ich brauche eine andere
> Art von XML" die Lösung "XSLT" impliziert, das ist aber schlichtweg
> falsch.
Ja, häufig ist es so oder so sinnvoller, zu parsen und dann von Hand zu
transformieren.
> Es gibt Berichte, daß die Leute heutzutage XML so parsen wie früher
> andere Textdateien: Lange draufstarren, Strukturen erkennen und
> Semantik erraten, Regular Expressions schreiben und hoffen, daß die
> produzierende Seite nichts ändert.
Wie ekelhaft. Wie unbeschreiblich ekelhaft. Warum soll man sowas auch nur in
Erwägung ziehen.
Dietz
Felix von Leitner
> > Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
> > CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
> Ack. Und der Inhalt kommt woher?
Editor, Datenbank, Perl-Script, whatever. Who cares?
> > Dieser ganze Transformations-Wahnsinn kostet nur Zeit und Geld und
> > bringt genau gar nichts.
> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken und
> soll diese zusammenführen dann ist XSLT ein durchaus brauchbares Mittel.
Dietz, wenn du masturbieren möchtest, kauf dir nen Wichsblättchen.
XSLT ist ungefähr so wichtig und brauchbar wie die österreichische
berittene Gebirgsmarine.
> > Und wenn dann mal jemand von Slashdot vorbei
> > kommt, bricht gleich die Site unter ihrem Eigengewicht zusammen.
> Wieso versucht Du zu behaupten, die Inhaltgenerierung müsse zum
> Zugriffzeitpunkt passieren?
Tue ich ja gar nicht.
> > Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
> > demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
> Wer statischen (bzw. sich selten ändernden) content anders macht ist so oder
> so unfähig. Und sobald man selten genug neugenerieren muß wird die Frage
> der Generatorlaufzeit zunehmend uninteressant.
Nein. Während der Entwicklung und Tests wird ständig neu generiert und
wenn das 10 Sekunden vs. 30 Minuten dauert, schlägt sich das deutlich im
Preis und Moral nieder.
Ich habe mal mit einem Typen gesprochen, der Software für die
Aktienmärkte machen wollte. Dessen Anforderungen waren:
Display-Update-Zeit kleiner Refresh-Zeit für ein Bild am Monitor.
Ich sehe keinen Grund, wieso man das nicht auch an allen anderen Stellen
anstreben sollte.
Wenig ist so schlecht für Moral und Produktivität als wenn man auf
Software warten muß.
Felix
Lars Marowsky-Bree
<dietz...@rotfl.franken.de> wrote:
>> es gab wohl fuer XSLT dann noch eine Weiterentwicklung, die
>> mehr und mehr Funktionen einer Programmiersprache aufzuweisen schien.
> XSLT ist turing-vollständig ;). Und ich bin kein besonderer Freund davon.
Eben. Als _Programmiersprache_ vollkommen ungeeignet.
> Der Hauptvorteil, es ist ein "Standard", d.h. man hat u.U. Leute welche
> einfache Transformationen schreiben können.
Ja, klar, wenn die Datenquellen so modifiziert werden können, das keine
komplexeren Operationen zur Darstellung mehr nötig sind, kann man da einfach
was ohne Programmieren machen :-} Und immernoch behaupten, man wäre "XML
kompatibel"...
Kristian Köhntopp
>> nackter Output. Du schreibst da laos sogar nur das hin, was du
>> wirklich haben willst:
>> <a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
>
> Dann kann man doch auch gleich PHP nehmen.
Mein Reden. Ist sowieso Wegwerfcode - beim nächsten Relaunch
fängt das alles wieder auf 0 an.
Kristian
Uwe Ohse
>Falls du perl magst: HTML::Mason gefällt mir bisher immer noch am besten
>von allen Varianten, die ich probiert habe.
$ emerge -up HTML
[ebuild N ] dev-perl/Class-Data-Inheritable-0.02
[ebuild N ] dev-perl/Devel-StackTrace-1.03
[ebuild N ] dev-perl/Exception-Class-1.12
[ebuild N ] dev-perl/Attribute-Handlers-0.78
[ebuild N ] dev-perl/Params-Validate-0.24-r2
[ebuild N ] dev-perl/Digest-SHA1-2.01-r1
[ebuild N ] dev-perl/IPC-ShareLite-0.08
[ebuild N ] dev-perl/Error-0.15-r2
[ebuild N ] dev-perl/Cache-Cache-1.01
[ebuild N ] dev-perl/Scalar-List-Utils-1.08
[ebuild N ] dev-perl/Class-Container-0.08
[ebuild N ] dev-perl/MIME-Base64-2.12-r2
[ebuild N ] dev-perl/URI-1.23
[ebuild N ] dev-perl/Digest-MD5-2.20-r1
[ebuild N ] dev-perl/libnet-1.11-r1
[ebuild N ] dev-perl/HTML-Tagset-3.03-r2
[ebuild N ] dev-perl/HTML-Parser-3.26-r2
[ebuild N ] dev-perl/libwww-perl-5.68
[ebuild N ] dev-libs/mm-1.2.1
[ebuild N ] net-www/apache-1.3.27-r3
[ebuild N ] dev-perl/mod_perl-1.27-r1
[ebuild N ] dev-perl/libapreq-1.0-r2
[ebuild N ] dev-perl/HTML-Mason-1.19
Das ist viel zu viel, selbst wenn man apache und mod_perl wegläßt.
Gruß, Uwe
Uwe Ohse
>Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
>CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
und manchmal funktioniert es auch so wie gewünscht.
Gruß, Uwe
Dietz Proepper
> Thus spake Dietz Proepper (dietz...@rotfl.franken.de):
>> > Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
>> > CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen
>> > es.
>> Ack. Und der Inhalt kommt woher?
>
> Editor, Datenbank, Perl-Script, whatever. Who cares?
Klar. Du schreibst für jeden popeligen producer einen Importer. Testest
diesen, debuggst ihn, schreibst regressionsfähige Tests usw.
Währenddessen sage ich meinem Generator, guggst du, DTD1, DTD2, Abbildung,
fuuump, steht da ein Stylesheet. Wenn sich das Producerformat ändert, neue
DTDen, wenig fummel, fuuump, steht da ein neues Stylesheet.
Regressionstests lassen sich btw. hier auch größtenteils automatisch
generieren.
Es kann so befriedigend sein, anderen bei harter Arbeit zuzugucken.
>> > Dieser ganze Transformations-Wahnsinn kostet nur Zeit und Geld und
>> > bringt genau gar nichts.
>> Nack. Wenn die Aufgabe lautet, man hat 5 Datenquellen die XML ausspucken
>> und soll diese zusammenführen dann ist XSLT ein durchaus brauchbares
>> Mittel.
>
> Dietz, wenn du masturbieren möchtest, kauf dir nen Wichsblättchen.
Ohne Dir in Deiner Voreingenommenheit widersprechen zu wollen, aber auch
hier liegt mir die warme, bewegliche, sprechende Variante mehr. Sheep take
care...
> XSLT ist ungefähr so wichtig und brauchbar wie die österreichische
> berittene Gebirgsmarine.
Das wiederum könnte man über 95% der EDV sagen. Und? Vorallem ändert dies
nichts daran daß sich viele Dinge damit realisieren lassen, es mag
elegantere Methoden geben, das ist aber nicht die Frage. BTW, zu Deinen "2s
um hello-world zu wandeln" würden mich mal die Sourcen interessieren. Die
Chance daß Du da irgendwas falsch gemacht hast sind recht hoch.
>> > Und wenn dann mal jemand von Slashdot vorbei
>> > kommt, bricht gleich die Site unter ihrem Eigengewicht zusammen.
>> Wieso versucht Du zu behaupten, die Inhaltgenerierung müsse zum
>> Zugriffzeitpunkt passieren?
>
> Tue ich ja gar nicht.
Und wie sollen dann Sites zusammen brechen?
>> > Wer unbedingt noch mehr Trennung haben will, kann die Transformation on
>> > demand machen (d.h. Datenbankänderungen triggern ein "make"). Für die
>> Wer statischen (bzw. sich selten ändernden) content anders macht ist so
>> oder so unfähig. Und sobald man selten genug neugenerieren muß wird die
>> Frage der Generatorlaufzeit zunehmend uninteressant.
>
> Nein.
Welcher Teil von "zunehmend" ist Dir unklar?
> Während der Entwicklung und Tests wird ständig neu generiert und
> wenn das 10 Sekunden vs. 30 Minuten dauert, schlägt sich das deutlich im
> Preis und Moral nieder.
Sorry, Felix, das ist derart platt was Du da erzählst... Wenn etwas das 10 s
dauern sollte 30 m dauert wird das Entwickeln erst interessant - als
Conslutant der ganz gerne die geplante Projektstufe n+1 auch mit machen
möchte hat man jetzt leider das Problem, einen speedup um 180 zu
realisieren. Man kann sich natürlich auch rectal dem AG nähern oder einfach
aufgeben.
> Ich habe mal mit einem Typen gesprochen, der Software für die
> Aktienmärkte machen wollte. Dessen Anforderungen waren:
Wollte er oder hat er? NATO-Prinzip, No Action, Talkin' Only?
> Display-Update-Zeit kleiner Refresh-Zeit für ein Bild am Monitor.
Und, hat er Dir auch etwas mehr erzählt? Zumindest soviel daß Du grob
abschätzen kannst, wieviel Aufwand das Darstellen fast displaygerecht
aufbereiteter Datensätze macht? Die insbesondere *eine* Datenquelle
realisieren, nicht etliche?
> Ich sehe keinen Grund, wieso man das nicht auch an allen anderen Stellen
> anstreben sollte.
Dein System ist gerade auf ./ erschienen. Da Deine Echtzeitgenerierung auf
jeden Fall teurer ist als ein statisches System beweist Du gerade die
Sinnlosigkeit von Apfel- mit Birnenvergleichen.
Außerdem, wenn Du eine Horde ausreichend fähiger Programmierer für sowas an
der Hand hast, ich kenne durchaus Leute welche auch zurzeit händeringend
nach solchen suchen. Man bekommt aber wohl entweder Zeloten oder
Prahlhänse.
Dietz
Lars Marowsky-Bree
<u...@ohse.de> wrote:
>>Äh, Kinder, wenn ihr Auszeichnung und Aussehen separieren wollt, NEHMT
>>CSS. Dafür ist das da. Es ist ein Standard. Die Browser verstehen es.
> und manchmal funktioniert es auch so wie gewünscht.
Für den Kleinkram, den ich mache, funktioniert es sogar relativ gut... ;)
Holger Marzen
> Markus Dobel wrote:
>
>>> nackter Output. Du schreibst da laos sogar nur das hin, was du
>>> wirklich haben willst:
>>> <a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
>>
>> Dann kann man doch auch gleich PHP nehmen.
>
> Mein Reden. Ist sowieso Wegwerfcode - beim nächsten Relaunch
^^^^^^^^
Argl!
Ich nehme 2 spitze und einen runden Stein.
Ralf Döblitz
> On Fri, May 02, 2003 at 07:23:07PM +0000, Ralf Döblitz wrote:
>>
>> In Mason ist außerhalb von Programmabschnitten erst mal alles nackter
>> Output. Du schreibst da laos sogar nur das hin, was du wirklich haben
>> willst:
>> <a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
>
> Dann kann man doch auch gleich PHP nehmen.
Wenn man PHP mag, ja. Ich benutze aber für die Programmteile einer
Website gerne die gleichen Bibliotheken und Module, die ich auch für
Standalone-Anwendungen und Batchprocessing verwende. Das erleichtert die
Wartung und reduziert die Kosten.
Ralf Döblitz
> Markus Dobel wrote:
>
>>> nackter Output. Du schreibst da laos sogar nur das hin, was du
>>> wirklich haben willst:
>>> <a href=http://www.fefe.de/fnord/>fnord at fefe.de</a>
>>
>> Dann kann man doch auch gleich PHP nehmen.
>
> Mein Reden. Ist sowieso Wegwerfcode - beim nächsten Relaunch
> fängt das alles wieder auf 0 an.
"Ich brauche um diesen Inhalt ein Tabellenkonstrukt (würg), das mir
einen Kasten mit abgerundeten Ecken macht" ist bei mir eine wiederver-
wendbare Mason-Komponente. "Ich will da eine Flash-Animation für IE und
Netscape" ebenfalls. Das sind Standardfälle, die man nur einmal bauen
will und die man auch nach einem Relaunch oder für die nächste Website
gebrauchen kann (wenn man sie denn sauber gebaut hat).
Ingo Wiarda
>> Es gibt Berichte, daß die Leute heutzutage XML so parsen wie früher
>> andere Textdateien: Lange draufstarren, Strukturen erkennen und
>> Semantik erraten, Regular Expressions schreiben und hoffen, daß die
>> produzierende Seite nichts ändert.
>
> Wie ekelhaft. Wie unbeschreiblich ekelhaft. Warum soll man sowas auch nur
> in Erwägung ziehen.
>
Wenn die produzierende Seite nicht in der Lage ist, korrektes XML zu
exportieren, bleibt einem gar nichts anderes übrig :)
Ingo
--
Ingo Wiarda - http://dewarim.de
GnuPG: http://dewarim.de/de/gpg_key.txt
christian mock
> Sag mal, hast du kürzlich deine Email-Adresse geändert?
kommt auf deine definition von "kuerzlich" an:
$ whois tahina.priv.at|grep changed:|head -1
changed: c...@tahina.priv.at 19970430
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/~cm/
What other OS provides not one but two INTERCAL compilers as part of
the standard distribution?
Mark Brown about Debian
christian mock
> Du hast also nicht die "tollen" "hilfreichen" "howto"s gefunden und befolgt.
haette ich das sollen? "docbook2ps" als name eines executables ist
selbsterklaerend genug, google findet bald zu "docbook: the definitive
guide", und mit etwas lesen der docbook2x scripts wird klar, wo die
ihre stylesheets herhaben, dort kann man dann nach interessanten
woertern greppen.
die doku (~50 seiten) ist mittlerweile jedenfalls fast fertig, inkl
einem customization layer fuer's stylesheet; die meiste zeit ist
dabei, wie ich mir das vorstelle, in den inhalt geflossen und nicht in
fiddling mit dem satzsystem.
meine einschaetzung des schmerzlevels dieser loesung ist immer noch
gleich: wie lout, und deutlich geringer als *TeX.
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/~cm/
** VIBE!AT http://www.vibe.at/ ** wir sind nicht zum spass hier.
Those silly RFCs are all that separate us from the animals!
-- Kevin Rodgers in a.r.e
Dietz Proepper
> Dietz Proepper wrote:
>
>>> Es gibt Berichte, daß die Leute heutzutage XML so parsen wie früher
>>> andere Textdateien: Lange draufstarren, Strukturen erkennen und
>>> Semantik erraten, Regular Expressions schreiben und hoffen, daß die
>>> produzierende Seite nichts ändert.
>>
>> Wie ekelhaft. Wie unbeschreiblich ekelhaft. Warum soll man sowas auch nur
>> in Erwägung ziehen.
>>
>
> Wenn die produzierende Seite nicht in der Lage ist, korrektes XML zu
> exportieren, bleibt einem gar nichts anderes übrig :)
Das ist eine andere Situation.
Christian H. Kuhn
> Felix von Leitner wrote:
>> Dietz, wenn du masturbieren möchtest, kauf dir nen Wichsblättchen.
>
> Ohne Dir in Deiner Voreingenommenheit widersprechen zu wollen, aber auch
> hier liegt mir die warme, bewegliche, sprechende Variante mehr. Sheep take
> care...
Wo gibts die sprechenden Schafe?
Sebastian Posner
> Wo gibts die sprechenden Schafe?
dtju, aber die liszpeln.
Sebastian
Kristian Köhntopp
>> Dann kann man doch auch gleich PHP nehmen.
>
> Wenn man PHP mag, ja. Ich benutze aber für die Programmteile
> einer Website gerne die gleichen Bibliotheken und Module, die
> ich auch für Standalone-Anwendungen und Batchprocessing
> verwende.
Darum gibt es /usr/bin/php bzw. /usr/bin/phpcli.
Kristian
Kristian Köhntopp
> Kristian Köhntopp <kr...@koehntopp.de> wrote:
>> Mein Reden. Ist sowieso Wegwerfcode - beim nächsten Relaunch
>> fängt das alles wieder auf 0 an.
>
> "Ich brauche um diesen Inhalt ein Tabellenkonstrukt (würg), das
> mir einen Kasten mit abgerundeten Ecken macht" ist bei mir eine
> wiederver- wendbare Mason-Komponente. "Ich will da eine
> Flash-Animation für IE und Netscape" ebenfalls. Das sind
> Standardfälle, die man nur einmal bauen will und die man auch
> nach einem Relaunch oder für die nächste Website gebrauchen
> kann (wenn man sie denn sauber gebaut hat).
Und das kriegst Du in PHP nicht hin, weil?
Kristian
PS: Je nach Kunde wirst Du "Kasten mit abgerundeten Ecken" sicher
und "Flash Animation für IE und Netscape" wahrscheinlich
nicht wiederverwenden können. Aber das hat Gründe, die außerhalb
von Mason oder PHP liegen.
Ralf Döblitz
[...]
> Und das kriegst Du in PHP nicht hin, weil?
Weil ich es nicht will. Klar, man könnte wohl auch PHP nehmen, wenn man
denn wollte. Aber das hat bei unserem Szenarion andere Nachteile (bzw.
fehlende Vorteile), die ich in einem anderen Posting schon erwähnte.
Ich behaupte ja auch nicht Perl und HTML::Mason wären das alleinig selig
machende Werkzeug. Es funktioniert für meine Anforderungen hinreichend
gut, was mit PHP AFAICS nicht gegeben wäre. Deshalb habe ich vor einigen
Monaten die letzte PHP-Altlast, für die ich zuständig war entsorgt. Wozu
zwei theoretisch gleichwertige Systeme pflegen, wenn es eines davon auch
tut? Und da ich Perl sowieso verwende ist eben PHP rausgeflogen. YMMVBIDC.
[...]
> PS: Je nach Kunde wirst Du "Kasten mit abgerundeten Ecken" sicher
> und "Flash Animation für IE und Netscape" wahrscheinlich
> nicht wiederverwenden können. Aber das hat Gründe, die außerhalb
> von Mason oder PHP liegen.
Wir haben zwei Klassen von Kunden: die einen zahlen nur für Standradware
und bekommen das aus Baukästen zusammengesetzt, die anderen bezahlen
wirklich für individiuelle Entwicklungen und machen erheblich mehr Spaß.
Leider gehört die Mehrheit zur ersteren Klasse.
Uwe Ohse
>Das ist eine andere Situation.
das ist eine verhältnismäßig häufige Situation.
Die zweite Situation ist die, daß die produzierende Seite drei Monate
oder Jahr nach der Supportanfrage endlich die Doku fixt.
XML ist ein Weg in die Hölle. IMO.
Gruß, Uwe
Bodo Eggert
>> Du hast also nicht die "tollen" "hilfreichen" "howto"s gefunden und befolgt.
>
> haette ich das sollen?
Besser nicht.
> "docbook2ps" als name eines executables ist
> selbsterklaerend genug
[...]
Suche Dir eine Doku mit einem Beispielaufruf, mit dem Tex-Ausgabe erzeugt
werden sollte. Vergleiche ihn mit dem, was docbook2* macht, und Du verstehst.
Alleine die tatsache, daß man ein Wrapper-Script braucht, ist eine Schande
für die Entwickler.
BTW: Man kann die Kataloge auch so installieren, daß $tool sie automatisch
findet. Wenn man jedoch Pech hat, so beißen sich irgendwelche Includes, die
natürlich nicht Doctype-spezifisch geladen werden. Eigentlich könnte man ja
meinen, daß in modernen Programmpaketen _nicht_ _sämtliche_ historischen
Fehler erneut gemacht werden müssen... Grrrrr!
--
Wenn ich mit meiner Relativitätstheorie recht behalte, werden die Deutschen
sagen, ich sei Deutscher, und die Franzosen, ich sei Weltbürger. Erweist sich
meine Theorie als falsch, werden die Franzosen sagen, ich sei Deutscher und
die Deutschen, ich sei Jude. -- Albert Einstein
Alexander Zangerl
[dinge die der fefe nicht so sieht]
> Ich erinnere mich vage, dich schon ein paar mal geplonkt zu haben, weil
> du zu dämlich bist, Großbuchstaben zu verwenden.
>
> Was solls, ein weiteres Mal schadet nicht. *plonk*
usenet purple heart: fefe sagt ich bin dämlich und hat mich geplonkt.
az
--
+ Alexander Zangerl + DSA 42BD645D + (RSA 5B586291)
Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former. -- Albert Einstein
Dietz Proepper
> Hallo Dietz,
>
>>Das ist eine andere Situation.
>
> das ist eine verhältnismäßig häufige Situation.
leider.
> Die zweite Situation ist die, daß die produzierende Seite drei Monate
> oder Jahr nach der Supportanfrage endlich die Doku fixt.
leider.
> XML ist ein Weg in die Hölle. IMO.
NACK.
Dietz
Ralf Döblitz
> begin electrogrammati illius Ralf Döblitz
>
>>"Ich brauche um diesen Inhalt ein Tabellenkonstrukt (würg), das mir
>>einen Kasten mit abgerundeten Ecken macht"
>
Designer kriegen fast alles hin. In beiden möglichen Bedeutungen. Da ist
es schon gut, wenn man die schmerzärmste Variante für zukünftige
Wiederverwendung festhalten kann.
Marc Haber
>> We re-invent every wheel?
>
>Marc, wenn die bestehenden Räder alle scheiße sind, dann muß man ein
>neues machen. Finde dich damit ab.
Wenn Du auf http://www.zugschlus.de/?select=zmna guckst, siehst Du,
dass auch ich bereits versucht habe, dieses konkrete Rad neu zu
erfinden. Leider ist meine Version sicher erheblich schlechter
geworden als die anderer Leute, aber für meinen Bedarf reicht sie und
korrektes HTML erzeugt sie auch.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Lutz Donnerhacke
> Unter Linux mit pipelining und keep-alive habe ich über 16000 Requests
> pro Sekunde über loopback gemessen.
Ca. 22 kHz gegen einen IIS übers Netz. Dann war die Kernellast auf 40%, die
Last des IIS Threads auf 50% und die Netzschnittstelle saturiert.
> Benchmark liegt bei. Skaliert nahezu unabhängig von der Anzahl der idle
> oder low-traffic Connections daneben.
Skaliert = Man konnte noch arbeiten.
> Das Problem, statische Seiten effizient auszuliefern, ist inzwischen gut
> verstanden und kann aus technischer Sicht als gelöst betrachtet werden.
Ack.
> allermeisten Fälle wie Zeitungen reicht das vollständig aus. Wer
> wirklich dynamische Daten ins Web tun will, der kauft sich halt jemanden
> ein, der sich damit auskennt, und der wird dann sicher keinen
> XML-Bullshit machen, sondern eine funktionierende, zuverlässige und
> skalierende Template-Engine.
Es war nur ein Normierungstest für die dynamischen Seiten, die aus
FastObjects (Poet) generiert wurden. Egal welcher Zugriff erfolgt, die
Mindestauslieferungszeit sind 2,5 Sekunden. x "parallele" Zugriffe werden
serialisiert (gequeuet) und brauchen dann linear wachsen bis zu x*2,5 sek.
Ja, das ist eine Scheißanwendung. Ja, das ist eine Anwendung, von jemanden,
der sich damit auskennt. Es ist eben nur blöde, wenn die Anzahl der
gehosteten Objekte von 400 auf 40000 wächst und alle Welt, die die Anwendung
einsetzt nie mehr als 1000 benutzt. Also wenn die Anwendung für nur 200
Objekte entwickelt wurde. Wer trägt die Schuld, wenn nach jahrelangem
Einsatz die Objektmenge plötzlich anwächst, weil das System so gut ist?
Zu CSS oder statische Generierung stimme ich Dir völlig zu.
Lutz Donnerhacke
> XSLT ist turing-vollständig ;).
Das hilft nicht, da es seinen eigenen Output nicht lesen kann. Wenn Du also
Deinen eigenen Output nachbearbeiten willst (Mehrstufige
Verarbeitungsschritte mit unbekannter Anzahl der Schleifenläufe (ändere bis
sich nichts mehr tut)), dann bist Du mit XSLT gezwungen, den gesamten Kram
in eigenene Strukturen nachzubilden (im RAM zu halten) und darauf zu arbeiten.
Das ist aber weder elegant noch schnell, sondern wirklich eine der
Turing-Maschine sehr ähnliche Programmierung.
Wenn Du das machen willst, kannst Du auch gleich den Transformer in
Sendmail-Rules schreiben und die XML Dokumente mailen. Ich bin der Meinung,
daß das schneller und klarer zum Ergebnis führt.
Lutz Donnerhacke
> Es gibt Berichte, daß die Leute heutzutage XML so parsen wie früher
> andere Textdateien: Lange draufstarren, Strukturen erkennen und
> Semantik erraten, Regular Expressions schreiben und hoffen, daß die
> produzierende Seite nichts ändert.
Ack. Genauso. Besonders, weil die angelieferten XML Dokumentation des
Lieferanten in zwei Beispieldateien und einer Zieldatei zu einer der
Beispieldateien besteht. Die andere Beispieldatei enthält Kommentare der Art
"<-- hier kann nur BLA, BLUB oder FASEL stehen -->"
christian mock
> Wenn Du das machen willst, kannst Du auch gleich den Transformer in
> Sendmail-Rules schreiben und die XML Dokumente mailen. Ich bin der Meinung,
> daß das schneller und klarer zum Ergebnis führt.
war das nicht eines der wenigen dinge, die in sendmail.cf nicht gehen:
naemlich mail-bodies bearbeiten?
ciao,
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/~cm/
"Tauschboerse, die. Neudeutsch im Usenetjargon fuer Flamewar (Heftiger
Austausch von Beleidigungen und verbalen Ohrfeigen)."
-- at in aip
Felix von Leitner
> > Aber was erwartet man auch von Experten wie GNOME, Debilian und KDE...
> Du beleidigsr elegante, durchdachte und zielführend programmierte Software.
An welche dachtest du da gerade, wenn ich fragen darf?
Felix
--
02/13/1986. Congress passes the historic Gramm-Rudman Act, which states that in
the event that the federal budget deficit continues to be a problem, Congress
will meet and make a sincere effort to pass some kind of historic act about it.
--Dave Barry
Felix von Leitner
> Erm, zeige ihnen FrameMaker+SGML. Sie werden dich lieben.
Ah, nicht nur obsolete und bloatig, außerdem auch noch beschissen zu
bedienen! Diese Software vereint wirklich alle positiven Aspekte
moderner Softwareentwicklung in sich.
Felix von Leitner
> > Unter Linux mit pipelining und keep-alive habe ich über 16000 Requests
> > pro Sekunde über loopback gemessen.
> Ca. 22 kHz gegen einen IIS übers Netz. Dann war die Kernellast auf 40%, die
> Last des IIS Threads auf 50% und die Netzschnittstelle saturiert.
Cool, was war das für eine Hardware?
> > Benchmark liegt bei. Skaliert nahezu unabhängig von der Anzahl der idle
> > oder low-traffic Connections daneben.
> Skaliert = Man konnte noch arbeiten.
Nein, skaliert == die Latenz stiegt nicht, wenn daneben noch 10000
Idle-Verbindungen rumlagen.
> Es war nur ein Normierungstest für die dynamischen Seiten, die aus
> FastObjects (Poet) generiert wurden. Egal welcher Zugriff erfolgt, die
> Mindestauslieferungszeit sind 2,5 Sekunden. x "parallele" Zugriffe werden
> serialisiert (gequeuet) und brauchen dann linear wachsen bis zu x*2,5 sek.
Äh, und dieses Teil heißt dann allen Ernstes "FastObjects"?!
ROTFL!
> Ja, das ist eine Scheißanwendung. Ja, das ist eine Anwendung, von jemanden,
> der sich damit auskennt. Es ist eben nur blöde, wenn die Anzahl der
> gehosteten Objekte von 400 auf 40000 wächst und alle Welt, die die Anwendung
> einsetzt nie mehr als 1000 benutzt. Also wenn die Anwendung für nur 200
> Objekte entwickelt wurde. Wer trägt die Schuld, wenn nach jahrelangem
> Einsatz die Objektmenge plötzlich anwächst, weil das System so gut ist?
Ein weiser Mann sagte mal: Wenn die Kardinalität um mehr als eine
Größenordnung steigt, ist es ein völlig anderes Problem und muß auch so
behandelt werden.
Felix
Felix von Leitner
> > "Ich brauche um diesen Inhalt ein Tabellenkonstrukt (würg), das
> > mir einen Kasten mit abgerundeten Ecken macht" ist bei mir eine
> > wiederver- wendbare Mason-Komponente. "Ich will da eine
> > Flash-Animation für IE und Netscape" ebenfalls. Das sind
> > Standardfälle, die man nur einmal bauen will und die man auch
> > nach einem Relaunch oder für die nächste Website gebrauchen
> > kann (wenn man sie denn sauber gebaut hat).
> Und das kriegst Du in PHP nicht hin, weil?
Warum in aller Welt würde man für so einen Trivial-Scheiß irgendein T00l
brauchen, sei es nun PHP oder Perl?!
Leute, kommt mal runter hier! HTML ist keine schwierige oder auch nur
ernstzunehmend komplexe Anwendung! Sowas macht man im Editor oder wenn
es denn sein muß mit ein paar Billig-Templates. Das ist überhaupt kein
Ding, und wer anderen Leuten da Kohle für hochtrabende grep-Integration
unter dem Namen "Content Management System" verscheuert, gehört m.E.
direkt auf den Mars geschossen.
Felix von Leitner
Felix von Leitner
Kristian, ich verstehe ja, daß du nicht völlig unvoreingenommen über PHP
diskutieren kannst, aber warum mußt du uns deine Spielzeugsprache
ständig so erbarmungslos reinzudrücken versuchen?
Wenn hier jemand Zeit für solchen Scheiß hätte, würde er sie bereits mit
solchem Scheiß verbringen.
Felix
--
Do not meddle in the affairs of wizards for you are crunchy and taste
good with ketchup.