Klassenbeschreibungen

[Philipp Hasenfratz]

Halihallo Forumer

Ich würde mal gerne eine allgemeine Vorlage für Klassenbeschreibungen erstellen, womit
ich die Klassen schön beschreiben kann. Ich hab da mal was Kleines erstellt, um mir aus
einer XML Datei eine HTML Datei zu transformieren. Jetzt würde ich gerne wissen, was
da noch so alles wichtig für eine Klassenbeschreibung wäre.
Was würdet Ihr euch noch wünschen, wenn Ihr ein solches Dokument vorliegen hättet?
Welche Informationen wären für Euch als Anwender der Komponente noch wichtig?

http://www.emedias.ch/tmp/DatabaseComponent.html mal was für's Auge, dass ihr
etwa wisst, wie ich mir das vorstelle.

Einige Features, die ich noch implementieren möchte, sind:
 [x] Beschreibung
 [x] Funktionsweise
 [x] Anwendungsbeispiele (evtl. für jede Methode?)
 [x] Autoren und Kontaktinformation
 [x] Beschreibung nicht nur der Methoden, sondern auch der Attribute (Variablen).
 [x] Bessere Verlinkung der Klassen (mit Ankern und Links) zu Verdeutlichung der
     Funktionsweise.

Was sonst noch? - Ist das vollständig und ausreichend?

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo nochmals

Mich würden auch andere Vorschläge zu Design und Inhalt interessieren. Die
Dokumentationsstyle zu Perl-Modulen kenne ich schon (*g*) aber vielleicht hat
jemand noch andere Dokumentationen. Oder wie macht ihr das? - Verwendet ihr
Vorlagen?
Gerne auch Links zu Klassenbeschreibungen etc.

Viele Grüsse

Philipp

[Simon Reinhardt]

Hi!

Mal eine Frage: Du beziehst Dich objektorientierte Sprachen im Allgemeinen, oder?
Also, hier gibt es ja die UML, mit der sich dann unter anderem auch Dokumentationen von objektorientierten Projekten durchführen lassen.
Ansonsten benutze ich, wenn ich in Java schreibe, immer das mitgelieferte JavaDoc (http://java.sun.com/j2se/1.4.1/docs/tooldocs/javadoc/index.html), welches sich auch so erweitern lässt, dass man eigene Layouts produzieren kann. Da ist eigentlich gar nichts anderes mehr nötig. Die Dokumenatation lässt sich bequem als Kommantare in den Quelltext einfügen und es wird alles an Informationen geliefert, was man benötigt.

VG Simon

[Philipp Hasenfratz]

Halihallo Simon

Mal eine Frage: Du beziehst Dich objektorientierte Sprachen im Allgemeinen, oder?

Auch wenn ich meistens mit Perl "unterwegs" bin; doch, ja, es soll schon allgemein sein.

Also, hier gibt es ja die UML, mit der sich dann unter anderem auch Dokumentationen von objektorientierten Projekten durchführen lassen.

Stimmt. Jedoch arbeitet UML komplett auf einem "graphischen Level"; das kann ich etwas
schlecht umsetzen. Es müsste schon textuell orientiert sein, wie...

Ansonsten benutze ich, wenn ich in Java schreibe, immer das mitgelieferte JavaDoc (http://java.sun.com/j2se/1.4.1/docs/tooldocs/javadoc/index.html), welches sich auch so erweitern lässt, dass man eigene Layouts produzieren kann. Da ist eigentlich gar nichts anderes mehr nötig. Die Dokumenatation lässt sich bequem als Kommantare in den Quelltext einfügen und es wird alles an Informationen geliefert, was man benötigt.

... das. javadoc ist ein schon sehr gutes Beispiel, wobei ich mich da nicht auf externe
Programme festlegen will; aber der Output (und der interessiert mich) ist schon sehr gut.
Gibt's eigentlich an dem noch etwas zu verbessern (ja, klar, das ist subjektiv
abhängig; aber genau diese subjektive Sicht würde mich interessieren)?

Gibt's noch andere Quellen, welche sich mit Dokumentation "beschäftigen" bzw. solche
enthalten/erstellen? - Vielleicht noch zum Hintergrund meiner Frage: Ich möchte einfach
einmal und dann jedoch auf alle Ewigkeit eine Dokumentationsautomatisierung erstellen
(wie das gepostete Beispiel XML => HTML), sodass ich mir nicht bei jedem Projekt
überlegen muss, wie ich die Doku schreibe, bzw. für jedes Dateiformat eine eigene
produzieren muss. Das soll mal alles automatisiert sein (am besten soll auch gleich das
ganze Programm automatisch programmiert werden *g*). Deshalb wollte ich mich bei euch
erkundigen, was denn so an Ansprüchen an eine Dokumentation gestellt werden; was ist aus
Sicht des Programmierers wichtig, was unwichtig (ja, ich gehöre ja auch dazu, dennoch
wollte ich noch andere Meinungen einholen und mich nicht auf meine verlassen; dann 20
Jahre später bemerken, dass meine Dokus für niemanden zu gebrauchen sind[1]). Deswegen
bin ich im Moment etwas auf der Suche nach "guten Dokumentationen", javadoc ist schon ein
guter Ansatz, danke für den Tipp.

[1] mal vom Inhalt abgesehen, den der sollte ja primär stimmen, natürlich.

Viele Grüsse und Danke

Philipp

[Andreas Korthaus]

Hallo Philipp!

Weder habe ich mich bisher mit sowas beschäftig, noch habe ich irgendwelche Ahnung davon, daher kann ich Dir höchtens ein interessantes Projekt nennen, welches sowas (leider nur) für PHP erledigt: http://www.phpdoc.de/demo.html Aber vielleicht sind ja auch Ideen für Dich dabei. phpdoc hat inzwischen den Weg in PEAR geschafft, also wird es nicht ganz so schlecht sein.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Weder habe ich mich bisher mit sowas beschäftig, noch habe ich irgendwelche Ahnung davon, daher kann ich Dir höchtens ein interessantes Projekt nennen, welches sowas (leider nur) für PHP erledigt: http://www.phpdoc.de/demo.html Aber vielleicht sind ja auch Ideen für Dich dabei. phpdoc hat inzwischen den Weg in PEAR geschafft, also wird es nicht ganz so schlecht sein.

Mei, das ist ja "klasse" (womit wir wieder beim Thema sind...). Vielen Dank für das
Beispiel, daraus kann ich wirklich noch einiges "abschauen". Sehr schön finde ich hier
auch die "Strukturierung" der Klassen (sowie bei javadoc), welche in meiner Version nicht
implementiert ist (naja, so vielvererbt sind meine Packages wohl nicht, deshalb habe
ich die Nichtimplementierung von "sub-/superklassen" noch nicht als negativ empfunden,
aber diese Beispiele zeigten mir, dass dies Notwendig ist). Auch wichtig ist die
Angabe von vererbten Methoden/Attributen, die bei mir fehlt.
Auch gut, dass gleich die Core-XML Dateien einsehbar sind, vielleicht entnehme ich da aus dem Source noch einige Tipps, welche Informationen verwaltet werden müssten.

Viele Grüsse und besten Dank für den Link!

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

[...]
Vielleicht noch etwas anders ausgedrückt:
 - Was haltet ihr von meinem Beispiel? - Ausreichend?
 - Was ist besser an dem vorgeschlagenen javadoc?
 - Welche Informationen sind relevant für Entwickler, die dem Projekt beigezogen werden?
 - Welche Informationen sind für die Endanwender von Relevanz?
 - Wie weit sollen Informationen aufgesplittet werden?
   z. B. halte ich die Dokumentationen von javadoc für zu "komplex" und dadurch
   unübersichtlich, wenn man sie das erste mal zu Gesicht bekommt. Die logische
   Strukturierung ist zwar gut, jedoch sind die Funktion und Parameter einer Methode erst
   über einen Link zu erreichen und stellt somit eine "Zerstückelung" der Information
   dar. Wer das erste mal javadoc-Output liest, ist eventuell etwas überfordert
   (zumindest habe ich diese Erfahrung etwas gemacht)
 - Wie strukturiert man am besten eine allgemeine Beschreibung oder Beschreibung der
   ganzen Komponente, oder einer Klasse?
 - Worauf kommt es beim Design an? - Strukturierung, Farben, Inhaltsverweise, TOC,
   Ihr könnt ja meine Doku, wie eine Homepage bewerten, falls das Hilft eine
   Argumentationsbasis zu finden.

Viele Grüsse

Philipp

PS: Ignoriert mein Englisch, hatte einfach, ohne zu überlegen und korrigieren,
eine Doku genommen und nicht auf Rechtschreibfehler geprüft.

[Simon Reinhardt]

Hi!

z. B. halte ich die Dokumentationen von javadoc für zu "komplex" und dadurch
   unübersichtlich, wenn man sie das erste mal zu Gesicht bekommt. Die logische
   Strukturierung ist zwar gut, jedoch sind die Funktion und Parameter einer Methode erst
   über einen Link zu erreichen und stellt somit eine "Zerstückelung" der Information
   dar. Wer das erste mal javadoc-Output liest, ist eventuell etwas überfordert
   (zumindest habe ich diese Erfahrung etwas gemacht)

Naja, wie gesagt, man kann javadoc auch so erweitern, dass eigene Layouts produziert werden, durch die sich solche Mängel sicherlich ausmerzen lassen. Mit dem Aufwand einer solchen Erweiterung habe ich allerdings keine Erfahrung. Es ist aber wohl geplant, javadoc irgendwann mal beizubringen, XML als Output zu liefern. Und das ließe sich ja mit XSLT beliebig formen.
Aber auch, wenn javadoc sehr komplex erscheint - es liefert so viele Imformationen: über die vererbten Methoden, über Subklassen und implementierende Klassen, über die gesamte Vererbungsstruktur usw.
Nur, wie Martin schon gesagt hat: das alles bringt nichts, wenn die Beschreibungen des Programmierers nicht ausführlich genug sind. Ich habe schon so oft erlebt, dass in Suns eigenen Dokumentationen wichtige Informationen gefehlt haben. Und betet, dass Ihr nie mit einer Dokumentation von Apache-Programmierern zu tun bekommt! ;-) (Stichwort: Xalan)

Aber letztendlich kann es auch mit der besten Klassendokumentation noch schwer fallen, zu begreifen, was ein Programm tut. Letzt erst wollte ich über die javadocs herausfinden, wie der SAX-Parser zu benutzen ist. Finde da erst mal die Einstiegsklasse! Ohne zusätzliche Docs oder ein gutes Buch ist man hier verloren. :)

VG Simon

[Martin Speiser]

Hi Simon,

Und betet, dass Ihr nie mit einer Dokumentation von Apache-Programmierern zu tun bekommt! ;-) (Stichwort: Xalan)

Willkommen Leidensgenosse :-)

Letzt erst wollte ich über die javadocs herausfinden, wie der SAX-Parser zu benutzen ist. Finde da erst mal die Einstiegsklasse! Ohne zusätzliche Docs oder ein gutes Buch ist man hier verloren. :)

Ähm... ist glaub die TransformerFactory, so aus dem Kopf raus. Aber hast du schon mit den SQL-Extensions rumgespielt? Die sind noch mit netten kleinen Fehlern versehen. Meine Meinung: Beta, und das müsste deutlich dran stehen.

Gruß,
Martin

[Martin Speiser]

Hallo Philipp,

also neben dem Javadoc gibt es noch was ähnliches von MS für .NET Sprachen, allerdings XML basierend. Womit du es dann machst, ist aber relativ egal, auf das Endergebnis kommt es an.

Wenn du ne Weile mit Java arbeitest, bzw. mit der Hilfe, wirst du feststellen, dass das beste Tool nichts nutzt, wenn man die Doku nebenher macht. Was mich an den Java-Hilfen (sei's nun Java selbst, oder Xalan, oder für andere Bibliotheken) stört, sind zu kurz gehaltene Beschreibungen der Methoden und ihrer Parameter, nichtssagende Beispiele, Sätze wie "see function above" (schön, die steht im Source oben. Nicht in dem, was Javadoc generiert), und Ähnliches. Da liegt die Krux, nicht ob man nun Javadoc nimmt, das .NET-Äquivalent, oder was Eigenes. Man braucht Selbstdisziplin.

Ja, ich nehme mich nicht aus. ;-)

Gruß,
Martin

[Philipp Hasenfratz]

Halihallo Martin und Simon

also neben dem Javadoc gibt es noch was ähnliches von MS für .NET Sprachen, allerdings XML basierend. Womit du es dann machst, ist aber relativ egal, auf das Endergebnis kommt es an.

Hat hierzu vielleicht jemand einen Link? - Wie sieht die Doku dort aus?

Wenn du ne Weile mit Java arbeitest, bzw. mit der Hilfe, wirst du feststellen, dass das beste Tool nichts nutzt, wenn man die Doku nebenher macht.

Full ACK. Und genau deshalb schreibe ich ein Dokumentationstool. Ich habe mich nur zu oft
bei der Handlung erwischt, dass ich gleich mit programmieren angefangen habe und mir
keine Gedanken zu den Informationen/-strukturen gemacht habe; nun, das ist vielleicht
etwas übertrieben, jedoch will ich genau dieses "code&fix"-Vorgehen unterbinden, indem
ich mich sozusagen zwinge erst eine Dokumentation (und den dadurch implizit vorher
getätigten Modellierungsarbeiten) zu schreiben. Der Code/Umsetzung folgt dann später.
Gestern hatte ich schon erste Versuche gestartet, den Perl-Code automatisch aus der
Dokumentation zu erstellen (die Package-Rümpfe).

Was mich an den Java-Hilfen (sei's nun Java selbst, oder Xalan, oder für andere Bibliotheken) stört, sind zu kurz gehaltene Beschreibungen der Methoden und ihrer Parameter, nichtssagende Beispiele, Sätze wie "see function above" (schön, die steht im Source oben. Nicht in dem, was Javadoc generiert), und Ähnliches. Da liegt die Krux, nicht ob man nun Javadoc nimmt, das .NET-Äquivalent, oder was Eigenes. Man braucht Selbstdisziplin.

Stimmt. Die ganze Dokumentation ist eben doch nur soviel wert, wie die Arbeit, die der
Programmierer dafür investiert hat, unabhängig von der Ausgabe des Programmes. Es geht
mir bei diesem Programm auch mehr darum, eine einfach zu verwaltende, unabhängige
Dokumentationsschnittstelle zu erstellen, um mir den Aufwand etwas zu reduzieren
(nicht jedes mal von neuem Gedanken zur Strukturierung der Dokumentation zu machen).

zu Simon: "Aber letztendlich kann es auch mit der besten Klassendokumentation noch schwer fallen, zu begreifen, was ein Programm tut. Letzt erst wollte ich über die javadocs herausfinden, wie der SAX-Parser zu benutzen ist. Finde da erst mal die Einstiegsklasse! Ohne zusätzliche Docs oder ein gutes Buch ist man hier verloren. :)"

genau das steht bei mir auch noch ganz weit oben. Eine reine Dokumentation der Klassen
und Vererbungshierarchien bringt wirklich nur dann etwas, wenn die Funktionsweise und
das Zusammenspiel der Komponenten bereits bekannt ist. Genau dies möchte ich auch in
mein "Tool" einfliessen lassen. Bevor also die Klassenbeschreibungen kommen, muss eine
grundlegende Dokumentation des ganzen "Systems" stattfinden; sozusagen der "Scope" des
Projektes und dann eine allgemein gehaltene Einführung mit Beispielen. Das vermisse ich
bei javadoc auch.

Viele Grüsse

Philipp

[Martin Speiser]

Hi Philipp,

Hat hierzu vielleicht jemand einen Link? - Wie sieht die Doku dort aus?

hm, sieht so aus als ob ich nicht recht hätte, und es kein .NET-Feature ist, sondern "nur" eins von C#. Beschrieben ist es jedenfalls unter http://msdn.microsoft.com/library/en-us/csref/html/vcoriXMLDocumentation.asp?frame=true (auch mit Mozilla abrufbar übrigens).

Gruß,
Martin

[Philipp Hasenfratz]

Halihallo Martin

Hat hierzu vielleicht jemand einen Link? - Wie sieht die Doku dort aus?

hm, sieht so aus als ob ich nicht recht hätte, und es kein .NET-Feature ist, sondern "nur" eins von C#. Beschrieben ist es jedenfalls unter http://msdn.microsoft.com/library/en-us/csref/html/vcoriXMLDocumentation.asp?frame=true (auch mit Mozilla abrufbar übrigens).

Sicherheitshalber war ich dennoch mit dem einzig wahren IE unterwegs :-)
Interessant, danke für den Artikel. Wenn ich das richtig verstanden habe, ist die
Dokumentation eine XML Datei, welche aus Kommentaren des Source entnommen/generiert wird?
Das ist eigentlich auch eine gute Idee (das Perl-pendant wäre hier z. B. POD; obwohl
dieses "allgemein" ist, allgemein in dem Sinne, dass die Strukturierung völlig dem
Programmierer überlassen wird). Das wäre sozusagen eine Stufe tiefer, als das, was ich
machen wollte (aber nicht minder interessant); ich transformiere von einer XML Datei eine
Dokumentation in z. B. HTML, das C#-Docu-Tool erstellt die erstgenannte XML Datei aus den
Quelltextkommentaren. Theoretisch könnte ich das auch bei mir so machen (praktisch
aufgrund fehlender Zeit unrealistisch ;)).

Viele Grüsse

Philipp

[Simon Reinhardt]

Hi!

Full ACK. Und genau deshalb schreibe ich ein Dokumentationstool. Ich habe mich nur zu oft
bei der Handlung erwischt, dass ich gleich mit programmieren angefangen habe und mir
keine Gedanken zu den Informationen/-strukturen gemacht habe; nun, das ist vielleicht
etwas übertrieben, jedoch will ich genau dieses "code&fix"-Vorgehen unterbinden, indem
ich mich sozusagen zwinge erst eine Dokumentation (und den dadurch implizit vorher
getätigten Modellierungsarbeiten) zu schreiben. Der Code/Umsetzung folgt dann später.
Gestern hatte ich schon erste Versuche gestartet, den Perl-Code automatisch aus der
Dokumentation zu erstellen (die Package-Rümpfe).

Ja, und genau hier braucht man die Selbstdisziplin. Weg vom VHIT (Vom Hirn Ins Terminal) hin zur kompletten Planung, bis auch nur die erste Zeile Code geschrieben wird. Wenn Du Dir große Softwarefirmen anguckst, die arbeiten nur so. Die gesamte Struktur steht schon fest und die Programmierarbeit muss nur noch von irgendwelchen Tippsen erledigt werden. Und gerade hier ist UML von Hilfe.
Der andere Ansatz ist dann das Extreme Programming. Ich habe mich zwar noch nicht so umfassend darüber informiert, aber für mich sieht das immer wie ein Rückschritt aus: ohne Planung drauf los programmieren, zwischendurch auftretende Kundenwünsche noch schnell mit reinquetschen (auch wenn dafür der gesamte Code umgestrickt werden muss) - alles nur, damit der Kunde so schnell wie möglich sichtbare Ergebnisse hat. Ich bin immer noch der Meinung: wenn man von Anfang an sauber plant, sind zusätzlich einzubauende Features kein Problem mehr.

VG Simon

[Philipp Hasenfratz]

Halihallo Simon

Ja, und genau hier braucht man die Selbstdisziplin. Weg vom VHIT (Vom Hirn Ins Terminal) hin zur kompletten Planung, bis auch nur die erste Zeile Code geschrieben wird. Wenn Du Dir große Softwarefirmen anguckst, die arbeiten nur so. Die gesamte Struktur steht schon fest und die Programmierarbeit muss nur noch von irgendwelchen Tippsen erledigt werden. Und gerade hier ist UML von Hilfe.

Ja, ja, ich weiss *g*

Der andere Ansatz ist dann das Extreme Programming. Ich habe mich zwar noch nicht so umfassend darüber informiert, aber für mich sieht das immer wie ein Rückschritt aus: ohne Planung drauf los programmieren, zwischendurch auftretende Kundenwünsche noch schnell mit reinquetschen (auch wenn dafür der gesamte Code umgestrickt werden muss) - alles nur, damit der Kunde so schnell wie möglich sichtbare Ergebnisse hat. Ich bin immer noch der Meinung: wenn man von Anfang an sauber plant, sind zusätzlich einzubauende Features kein Problem mehr.

Da gebe ich dir recht. Meiner Meinung nach ist Extreme Programming auch ein Schritt
zurück, aber man muss das in einem aktuellen Kontext sehen. Extreme Programming ist aus
der "Wirtschaft" entstanden und versucht den Wünschen der Wirtschaft gerecht zu werden.
Man versucht durch schnelles Umsetzen (auch wenn's dann übel endet...) möglichst schnell
etwas auf den Bildschirm zu kriegen, koste es was es wolle. Der Grund liegt darin, dass
der Kunde so schnell wie möglich etwas sieht und dann seine Wünsche weiter spezifizieren
kann, sodass sehr schnell ein Feedback vom Kunden möglich wird[1]. Bei der von uns
preferierten Methode (UML-Modellierung, Konzeptionierung und dann Programmierung) sieht
der Kunde das Ergebnis erst viel später (OK, dass kann man mit Prototyping etwas
umgehen). Ein Feedback des Kunden ist eher schwer zu "bekommen" und somit ist die
Kommunikation von Kunde zu Entwicklerteam nicht sehr gut => die Software genügt nur dem
Pflichtenheft (bzw. Lastenhelft, was vom Kunden kam) und einigen Feedbacks, die der Kunde
vielleicht noch abgeben konnte. Anderes Fakt: durch schnelles Programmieren wird die
Software vielleicht unausgereift sein, jedoch können einzelne Teile davon bereits vor dem
Abgabethermin in Einsatz genommen werden (paralleles BugFixing).

Ich hoffe, dass ich den Sinn von Extreme Programming korrekt erfasst habe, denn ich habe
mich auch noch nicht gut informiert.

[1] und dadurch eine Kundenorientierte/-optimierte Lösung erarbeitet wird und keine
"Dem-Entwickler-Team-Genügende".

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

[...]
Hatte gerade etwas Zeit und habe mal etwas gebastelt:
http://www.emedias.ch/tmp/doc.zip

xmldoc2html.pl   - konvertiert eine Komponenten-XML-Datei in HTML
doc.html         - das Ergebnis dieser Konvertierung.
doc.xml          - wobei doc.xml als Eingabe benutzt wurde, was einer Doku von...
Doc.pm           - ... entsprechen könnte.

das wäre mal der erste (noch sehr instabile und unperfektionierte) Prototyp einer
Umsetzung. Leider habe ich es noch nicht geschafft, die gewünschten anderen Eigenschaften
zu implementieren (Modulübersicht/-struktur, allg. Beschreibungen, Beispiele, ...).
Ich hoffe, dass ich noch Zeit habe den zu perfektionieren, da ich nächste Woche wohl
wieder einiges anderes zu tun habe. Würde mich aber interessieren, was ihr dazu meint...

Viele Grüsse

Philipp

PS: Die Benutzung erfolgt auf eigene Gefahr *g*. Das Ding habe ich in ca. 3-4 Stunden
geschrieben; da sind bestimmt noch einige Fehler drinne...

[Simon Reinhardt]

Hi!

Hatte gerade etwas Zeit und habe mal etwas gebastelt:
http://www.emedias.ch/tmp/doc.zip

Gefällt mir ganz gut.
Nur ein paar Sachen noch:

---------------

...
sub getNotes {
   my ($self) = @_;
   my $desc = $self->getElementsByTagName( 'description' );
...

Da müsste 'notes' stehen.

----------------

<method type="constructor" name="new">
<method type="public" name="parseFile">

Ich würde das noch trennen. constructor ist ja eine ganz andere Sache als public. Das eine ist wirklich der Typ der Methode, das andere würde ich (zumindest in Java) unter einem Attribut restriction einbinden. Ich weiß nicht, wie es in Perl ist, aber in Java kann eine Methode Constructor sein und trotzdem noch die Restrictions public/private/protected/nichts haben. Ich weiß auch nicht, welche von diesen Schlüsselwörtern es in Perl gibt, denn Du hast in Doc.pm ja nur eine Methode isPublic().

----------------

Interessant wäre noch, Dein Format mit XSLT zu transformieren. Dann brauchst Du kein kompliziertes Perl-Script mehr dazu. ;-)

VG Simon

[Philipp Hasenfratz]

Halihallo Simon

Hatte gerade etwas Zeit und habe mal etwas gebastelt:
http://www.emedias.ch/tmp/doc.zip

Gefällt mir ganz gut.
Nur ein paar Sachen noch:

Immer gerne! Danke.

...
sub getNotes {
   my ($self) = @_;
   my $desc = $self->getElementsByTagName( 'description' );
...

Da müsste 'notes' stehen.

Uha, danke. Zuviel Copy&Paste :-)

<method type="constructor" name="new">
<method type="public" name="parseFile">

Ich würde das noch trennen. constructor ist ja eine ganz andere Sache als public. Das eine ist wirklich der Typ der Methode, das andere würde ich (zumindest in Java) unter einem Attribut restriction einbinden. Ich weiß nicht, wie es in Perl ist, aber in Java kann eine Methode Constructor sein und trotzdem noch die Restrictions public/private/protected/nichts haben. Ich weiß auch nicht, welche von diesen Schlüsselwörtern es in Perl gibt, denn Du hast in Doc.pm ja nur eine Methode isPublic().

In Perl gibt es eigentlich gar nichts, die Methoden werden nicht weiter charakterisiert.
Es gibt weder private, noch public oder andere Methodenrestriktionen. Perl war anfänglich
nicht für OOP konzeptioniert und dementsprechend schwach ist die Syntax heute
implementiert. Eine Klasse ist in Perl nichts anderes als ein Modul mit Funktionen und
Prozeduren, welchen eine "geblesste" Referenz übergeben wird. Es gibt demnach eigentlich
gar keine Syntax für Klassen.
Dass Restrictions und Types getrennt implementiert sein sollten stimmt. Das werde ich
noch ändern, stammte noch aus dem Anfang der Planung, wo ich es mir noch einfach gemacht
habe (nicht zuletzt deswegen, dass es das in Perl gar nicht gibt, jedoch möchte ich
schon eine Schnittstelle, die Sprachenunabhängig ist).

Interessant wäre noch, Dein Format mit XSLT zu transformieren. Dann brauchst Du kein kompliziertes Perl-Script mehr dazu. ;-)

Das hab ich mir auch überlegt, jedoch mag ich eine Dokumentationskomponente mehr ;-)

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

[...]
Simon: das mit Restrictions vs. Type sollte jetzt OK sein.

Der aktuelle Status ist immer in der changes.txt der doc.zip einzusehen. doc.zip ändert
hat die nächste Zeit immer wiedermal (unperiodisch).

Viele Grüsse

Philipp

[Simon Reinhardt]

Hi!

Der aktuelle Status ist immer in der changes.txt der doc.zip einzusehen. doc.zip ändert
hat die nächste Zeit immer wiedermal (unperiodisch).

Ich werd's mir bookmarken. ;-)

VG Simon

[Philipp Hasenfratz]

Halihallo Simon

Der aktuelle Status ist immer in der changes.txt der doc.zip einzusehen. doc.zip ändert
hat die nächste Zeit immer wiedermal (unperiodisch).

Ich werd's mir bookmarken. ;-)

Ich kann dir natürlich auch einen Update-Assistent schreiben, der jeden Tag durch cron
gestartet nachsieht, ob eine neue Version da ist :-)
Naja, wie gesagt, nächste Woche (und die hat bei mir schon heute angefangen), muss ich
mich wohl wieder der "normalen" Arbeit hingeben, da werd ich nicht allzuviel
weiterkommen[1]. Ich hoffe jedoch, dass sich der Prototyp mal in ein nutzbares Tool
verwandelt, und dieses kommt dann in die Signatur (dann hat's Philipp endlich auch
geschafft eine Signatur zu haben *g*).

[1] ein Nachsehen jeden Tag ist wohl OK.

Viele Grüsse

Philipp

[Simon Reinhardt]

Hi!

Ich kann dir natürlich auch einen Update-Assistent schreiben, der jeden Tag durch cron
gestartet nachsieht, ob eine neue Version da ist :-)

Ich bitte darum! ;)

Ich hoffe jedoch, dass sich der Prototyp mal in ein nutzbares Tool
verwandelt, und dieses kommt dann in die Signatur (dann hat's Philipp endlich auch
geschafft eine Signatur zu haben *g*).

Hachja, vielleicht schaffe ich es ja dann auch mal, mit meinem XML-basierten CMS weiterzukommen und es irgendwann in der Signatur anzupreisen. Und dann meine Website endlich wieder neu auflegen und als Link angeben. :)

VG Simon

[Philipp Hasenfratz]

Halihallo Leidensgenosse ;)

Ich kann dir natürlich auch einen Update-Assistent schreiben, der jeden Tag durch cron
gestartet nachsieht, ob eine neue Version da ist :-)

Ich bitte darum! ;)

Och, ne, nicht noch mehr arbeit :-(( *g*
Aber ich kann dir anbieten dich über E-Mail auf dem laufenden zu halten.

Ich hoffe jedoch, dass sich der Prototyp mal in ein nutzbares Tool
verwandelt, und dieses kommt dann in die Signatur (dann hat's Philipp endlich auch
geschafft eine Signatur zu haben *g*).

Hachja, vielleicht schaffe ich es ja dann auch mal, mit meinem XML-basierten CMS weiterzukommen und es irgendwann in der Signatur anzupreisen. Und dann meine Website endlich wieder neu auflegen und als Link angeben. :)

Deshalb Leidensgenosse... Ich glaube wir haben das selbe "Problem"... Nur nicht aufgeben!
Die Arbeit in der Firma holt einem leider immer zu schnell ein *grrr*! - Und wenn man mal
länger an einem Projekt arbeitet, wachsen die Anforderungen und die Komplexität schnell
in unendliche Weiten...

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Simon

Interessant wäre noch, Dein Format mit XSLT zu transformieren. Dann brauchst Du kein kompliziertes Perl-Script mehr dazu. ;-)

Gestern habe ich mir noch Gedanken zu diesem Vorschlag gemacht. Du hast recht, eine
Verwendung von XSLT wäre sinnvoll, es ist ja höchst unschön, wenn man Code und Design
in einer "Einheit" hat. Nur habe ich dann weiterüberlegt und festgestellt, dass es zu
Problemen kommen wird, wenn man komplexere Dinge transformieren will. Nehmen wir z. B.
eine Übersicht der Klassenvererbung (in der ersten Stufe sind alle Klassen, die von
keiner anderen mehr erben, die zweite Stufe sind diejenigen, welche von diesen
"Super-Basis-Klassen" erben usw.), dies wäre IMHO mit XSLT nicht (bzw. nur sehr schlecht)
abbzubilden, da man für diese Anwendung bereits einen Alogithmus braucht, der einen Baum
der Vererbungshierarchie aufbaut. Wenn man dies mit XSLT abbilden möchte, bräuchte man
geeignete Eingabedaten (diese würden dann leider nicht mehr der
Componenten-Beschreibungs-XML-Datei entsprechen), dies würde bedeuten, dass man mit einem
Programm diese erst herstellt. Das halte ich im Kontext für etwas übertrieben, da man
ja durch CSS schon einiges variabel Designen kann (klar, die Grundstruktur des HTML-
Outputs kann man nicht ändern, aber dessen Anzeigeformat). Es wäre möglich die
einfacheren Outputs (wie z. B. Componentenübersicht mit Methoden/Attributen) durch XSLT
zu erstellen, aber wenn überhaupt, dann möchte ich alles über XSLT erstellen lassen und
das ist meiner Meinung nach nicht möglich.

Oder ist es Fakt, dass alles mit XSLT transformierbar wäre? - Ich sehe Probleme bei
der Ausgabe der Klassenvererbung und z. B. der Angabe von Inputparameter, da sollte nur
die erste Eingabeparameter ein "Input:" vorne stehen haben (OK, möglich, dass es für
dies Direktiven gibt, obwohl mir die z. Z. nicht bekannt sind).

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo,

Problemen kommen wird, wenn man komplexere Dinge transformieren will.

;-) Das ist kaum anzunehmen.

»»Nehmen wir z. B.

eine Übersicht der Klassenvererbung (in der ersten Stufe sind alle Klassen, die von
keiner anderen mehr erben, die zweite Stufe sind diejenigen, welche von diesen
"Super-Basis-Klassen" erben usw.), dies wäre IMHO mit XSLT nicht (bzw. nur sehr schlecht)
abbzubilden, da man für diese Anwendung bereits einen Alogithmus braucht, der einen Baum
der Vererbungshierarchie aufbaut.

Sorry, aber du hat XSL gründlich missverstanden. XSL bzw. XML Parsen ist das auf und ab wandern in einer baumartigen hierarchischen Struktur.

»»Wenn man dies mit XSLT abbilden möchte, bräuchte man

geeignete Eingabedaten (diese würden dann leider nicht mehr der
Componenten-Beschreibungs-XML-Datei entsprechen), dies würde bedeuten, dass man mit einem
Programm diese erst herstellt.

???? Das einzige was du brauchst is XML.

Das halte ich im Kontext für etwas übertrieben, da man

ja durch CSS schon einiges variabel Designen kann (klar, die Grundstruktur des HTML-
Outputs kann man nicht ändern, aber dessen Anzeigeformat).

Wenn du dein XML mit CSS formatieren willst, kannst du nur eine absolute flache Hierarchi bzw. fast keine haben.
Mit XSLT kannst du kreuz und quer über die verschiedensten Verwandschaftspfaden laufen, und noch eingies mehr in der Hierarchie machen.

Es wäre möglich die
einfacheren Outputs (wie z. B. Componentenübersicht mit Methoden/Attributen) durch XSLT
zu erstellen, aber wenn überhaupt, dann möchte ich alles über XSLT erstellen lassen und
das ist meiner Meinung nach nicht möglich.

Sorry, aber ich habe das gefühl, dass du sehr wenig über die Möglichkeiten von XSLT weisst und das du noch gar nichts damit gemacht hast.

Oder ist es Fakt, dass alles mit XSLT transformierbar wäre?

Alles sicher nicht. Du kannst auch mit XSLT blein nicht in Gold Transformieren.

• Ich sehe Probleme bei

der Ausgabe der Klassenvererbung

Wie siehr denn deine XML aus, was in etwa möchtest haben?

Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Problemen kommen wird, wenn man komplexere Dinge transformieren will.

;-) Das ist kaum anzunehmen.

Ich lasse mich gerne vom Gegenteil überzeugen, wirklich. ;)

»»Nehmen wir z. B.

eine Übersicht der Klassenvererbung (in der ersten Stufe sind alle Klassen, die von
keiner anderen mehr erben, die zweite Stufe sind diejenigen, welche von diesen
"Super-Basis-Klassen" erben usw.), dies wäre IMHO mit XSLT nicht (bzw. nur sehr schlecht)
abbzubilden, da man für diese Anwendung bereits einen Alogithmus braucht, der einen Baum
der Vererbungshierarchie aufbaut.

Sorry, aber du hat XSL gründlich missverstanden. XSL bzw. XML Parsen ist das auf und ab wandern in einer baumartigen hierarchischen Struktur.

Das glaube ich nicht (Tim/Thomas)...
Das Prinzip, wie XSL(T) vorgeht ist mir bekannt; ich gebe dir jedoch recht, dass ich den
Leistungsumfang nicht genau kenne, da ich wirklich nicht viel Erfahrung damit habe
(bzw. immer nur "einfache" Transformationen gemacht habe).

»»Wenn man dies mit XSLT abbilden möchte, bräuchte man

geeignete Eingabedaten (diese würden dann leider nicht mehr der
Componenten-Beschreibungs-XML-Datei entsprechen), dies würde bedeuten, dass man mit einem
Programm diese erst herstellt.

???? Das einzige was du brauchst is XML.

Ja, aber ich dachte (und du hast mich noch nicht vom Gegenteil überzeugt), dass man den
Algorithmus in einem Programm implementieren muss, sodass dieser einen entsprechend
erstellten XML-Output generiert, sodass man mit XSLT transformieren kann und dort keine
"Algorithmen zu implementieren" braucht. Den Umweg über das Programm deshalb, da ich mir
(noch) nicht vorstellen kann, dass man das gleich in XSLT umsetzen kann.

Das halte ich im Kontext für etwas übertrieben, da man

ja durch CSS schon einiges variabel Designen kann (klar, die Grundstruktur des HTML-
Outputs kann man nicht ändern, aber dessen Anzeigeformat).

Wenn du dein XML mit CSS formatieren willst, kannst du nur eine absolute flache Hierarchi bzw. fast keine haben.
Mit XSLT kannst du kreuz und quer über die verschiedensten Verwandschaftspfaden laufen, und noch eingies mehr in der Hierarchie machen.

Das wollte ich u. a. damit sagen. Mit XSLT kann man den HTML Output an sich ändern,
mit meiner Version würde man nur über CSS noch Designänderungen vornehmen können.

Sorry, aber ich habe das gefühl, dass du sehr wenig über die Möglichkeiten von XSLT weisst und das du noch gar nichts damit gemacht hast.

ersteres ja, letzteres nein.

Oder ist es Fakt, dass alles mit XSLT transformierbar wäre?

Alles sicher nicht. Du kannst auch mit XSLT blein nicht in Gold Transformieren.

Schade, dachte schon es wäre eine Möglichkeit für mich, als Alchimist ;-)

Wie siehr denn deine XML aus, was in etwa möchtest haben?

Die Eingabe ist so, wie in Doc.xml. Das ist die Grundlage, von wo aus alles andere
transformiert werden soll. Jede Klasse in Doc.xml hat ein optinales Attribut extends,
welches diejenige Klasse "referenziert", von der geerbt werden soll. Bei grossen
Komponenten ergibt dies eine baumartige Vererbungshierarchie, die ich eben ausgeben
möchte. Nehmen wir als Beispiel eine kleine Teilmenge der Doc-Komponente:

XML::DOM::Node
   XML::DOM::Document
      DocComponent
   XML::DOM::Element
      DocClass
      DocMethod
XML::DOM::Parser
   DocParser

XML::DOM::Node und XML::DOM::Parser sind die "Lowest-Level-Klassen", vonwelchen nicht
mehr weiter vererbt wird. Danach kommen diejenigen Klassen, die von denen erben, etc.
Erschwerend kommt hinzu, dass die einzelnen Klassen der gleichen Ebene "zusammengefasst"
werden, also _nicht_ sowas:

XML::DOM::Node
   XML::DOM::Document
      DocComponent
XML::DOM::Node
   XML::DOM::Element
      DocClass
XML::DOM::Node
   XML::DOM::Element
XML::DOM::Parser
   DocParser

Wie kann man das mit XSLT abbilden? - Geht das überhaupt? - Meiner Meinung nach braucht
es dafür eben einen Algorighmus, der einen Baum erstellt; ich weiss derzeit nicht, wie
ich dies mit XSLT machen soll.

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Philipp,

Ich lasse mich gerne vom Gegenteil überzeugen, wirklich. ;)

http://httpd.apache.org/docs-2.0/new_features_2_0.xml
Dann von da ausgehen die XSL-Dateien:
http://httpd.apache.org/docs-2.0/style/manual.en.xsl
http://httpd.apache.org/docs-2.0/style/xsl/common.xsl
http://httpd.apache.org/docs-2.0/style/xsl/sitemap.xsl etc.
die sind um einiges komplizierter, als z.B. welche die du brauchen würdest (jetzt mit deinem doc.xml)

(generell kannst du bei der doku vom Apche 2 die HTML-Endungen durch XML ersetzen und du hast due XML/XSLT Version der Doku: geht allerdings nur mit Browser die XML mit XSLT selbst darstellen können.)

Sorry, aber du hat XSL gründlich missverstanden. XSL bzw. XML Parsen ist das auf und ab wandern in einer baumartigen hierarchischen Struktur.

Das glaube ich nicht (Tim/Thomas)...

Das ist schon OK, wenn du mir nicht glaubst, aber das ändert wenig daran, dass sowohl ein XML als auch ein XSL Prozessor mit "Bäumen" arbeitet. Als leichtverständliche Einführung ist <file:///D:/selfhtml/xml/darstellung/xslgrundlagen.htm#transformation> wirklich geeignet ;-)

Das Prinzip, wie XSL(T) vorgeht ist mir bekannt;

OK, und wie ist das Prinzip vom XSLT? ;-)

???? Das einzige was du brauchst is XML.

Ja, aber ich dachte (und du hast mich noch nicht vom Gegenteil überzeugt), dass man den Algorithmus in einem Programm implementieren muss, sodass dieser einen entsprechend
erstellten XML-Output generiert, sodass man mit XSLT transformieren kann und dort keine
"Algorithmen zu implementieren" braucht.

Ich weiss wirklich nicht was du meinst. Was sollte in einem Programm implementiert werden: Ich weiss nicht was du hier mit Algorithmen meinst. Was für Algorythmen sollten denn iun der XSL-Sheet nicht drinn sein? Kenntnisse über die Arbeistweise eines XML oder XSL Prozessor wären dir hier vom Vorteil. (ich meine es nicht ungut)
(http://www.fh-wedel.de/~si/seminare/ws00/Ausarbeitung/5.xslt/xslt1.htm#Anchor-56514)

Das wollte ich u. a. damit sagen. Mit XSLT kann man den HTML Output an sich ändern,
mit meiner Version würde man nur über CSS noch Designänderungen vornehmen können.

Ja, das ist richtig, aber ich sehe das Problem dabei nicht.

Die Eingabe ist so, wie in Doc.xml. Das ist die Grundlage, von wo aus alles andere
transformiert werden soll. Jede Klasse in Doc.xml hat ein optinales Attribut extends,
welches diejenige Klasse "referenziert", von der geerbt werden soll. Bei grossen
Komponenten ergibt dies eine baumartige Vererbungshierarchie, die ich eben ausgeben
möchte. Nehmen wir als Beispiel eine kleine Teilmenge der Doc-Komponente:

XML::DOM::Node
   XML::DOM::Document
      DocComponent
   XML::DOM::Element
      DocClass
      DocMethod
XML::DOM::Parser
   DocParser

Ja, das wird mir jetzt klarer, aber sowas abzubilden in XSL wirklich kein so großes Problem.

XML::DOM::Node und XML::DOM::Parser sind die "Lowest-Level-Klassen", vonwelchen nicht mehr weiter vererbt wird. Danach kommen diejenigen Klassen, die von denen erben, etc.

Da stimmt was nicht: entweder sie (XML::DOM::Node und XML::DOM::Parser) vererben noch was, oder nicht. Wenn ja sind sie nicht das lowest-level, wenn nicht, wo sollten dann klassen kommen die von denen (vom XML::DOM::Node und XML::DOM::Parser) erben?

Erschwerend kommt hinzu, dass die einzelnen Klassen der gleichen Ebene "zusammengefasst"
werden, also _nicht_ sowas:

Du möchtest eine Doku, das wie eine JavaDoku aufgebaut ist?

Wie kann man das mit XSLT abbilden? - Geht das überhaupt? - Meiner Meinung nach braucht es dafür eben einen Algorighmus, der einen Baum erstellt; ich weiss derzeit nicht, wie
ich dies mit XSLT machen soll.

So langsam verstehe ich was du meinst: das geht auch mit XSLT, mit rekursiven templates etc. ist sowas möglich, kommt nur wirklich darauf was du genau haben möchtest.

Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

*erstmal sorry, dass ich nicht frequentierter antworten kann, entspricht normalerweise
nicht meine Art*

Ich lasse mich gerne vom Gegenteil überzeugen, wirklich. ;)

http://httpd.apache.org/docs-2.0/new_features_2_0.xml
Dann von da ausgehen die XSL-Dateien:
http://httpd.apache.org/docs-2.0/style/manual.en.xsl
http://httpd.apache.org/docs-2.0/style/xsl/common.xsl
http://httpd.apache.org/docs-2.0/style/xsl/sitemap.xsl etc.
die sind um einiges komplizierter, als z.B. welche die du brauchen würdest (jetzt mit deinem doc.xml)

(generell kannst du bei der doku vom Apche 2 die HTML-Endungen durch XML ersetzen und du hast due XML/XSLT Version der Doku: geht allerdings nur mit Browser die XML mit XSLT selbst darstellen können.)

Diese Dokumente haben keine (mir ersichtliche) "Rekursionswünsche", die sind relativ
einfach zu erstellen (das ist jetzt nicht überheblich gemeint, sondern leicht in dem
Sinne, dass der Output leicht über templates vom Input erstellen lassen können).

Sorry, aber du hat XSL gründlich missverstanden. XSL bzw. XML Parsen ist das auf und ab wandern in einer baumartigen hierarchischen Struktur.

Das glaube ich nicht (Tim/Thomas)...

Das ist schon OK, wenn du mir nicht glaubst, aber das ändert wenig daran, dass sowohl ein XML als auch ein XSL Prozessor mit "Bäumen" arbeitet. Als leichtverständliche Einführung ist <file:///D:/selfhtml/xml/darstellung/xslgrundlagen.htm#transformation> wirklich geeignet ;-)

... Klar arbeitet er mit Bäumen, aber das Traversieren derjenigen ist auf die Verwendung
von templates beschränkt und denen kann man keinen Zielknoten angeben (oder doch?
select mit einer Variable möglich?).

Das Prinzip, wie XSL(T) vorgeht ist mir bekannt;

OK, und wie ist das Prinzip vom XSLT? ;-)

...! - Höre ich mich wirklich so leienhaft an?

Ich weiss wirklich nicht was du meinst. Was sollte in einem Programm implementiert werden: Ich weiss nicht was du hier mit Algorithmen meinst.

Also entweder du verstehst mich überhaupt nicht, oder ich stelle eine so dumme Frage, das
du dir nicht vorstellen kannst, dass ich das nicht weiss. Ich versucht das in
[pref:t=35303&m=195253] nochmals zu erleutern; vielleicht sehe ich den Wald vor lauter
Bäumen nicht; wäre zumindest eine logische Erklärung für meine Verwirrung...

Das wollte ich u. a. damit sagen. Mit XSLT kann man den HTML Output an sich ändern,
mit meiner Version würde man nur über CSS noch Designänderungen vornehmen können.

Ja, das ist richtig, aber ich sehe das Problem dabei nicht.

Das hat auch nichts mit dem anderen Problem zu tun. Ich hatte nur selbstkritisch meine
Lösung analysiert und festgestellt, dass es nicht sinnvoll ist, wenn man die HTML-Ausgabe
über Perl realisiert, da bei einer Änderung am Perl-Code gearbeitet werden müsste, was
nicht Sinn der Sache sein kann.

Die Eingabe ist so, wie in Doc.xml. Das ist die Grundlage, von wo aus alles andere
transformiert werden soll. Jede Klasse in Doc.xml hat ein optinales Attribut extends,
welches diejenige Klasse "referenziert", von der geerbt werden soll. Bei grossen
Komponenten ergibt dies eine baumartige Vererbungshierarchie, die ich eben ausgeben
möchte. Nehmen wir als Beispiel eine kleine Teilmenge der Doc-Komponente:

XML::DOM::Node
   XML::DOM::Document
      DocComponent
   XML::DOM::Element
      DocClass
      DocMethod
XML::DOM::Parser
   DocParser

Ja, das wird mir jetzt klarer, aber sowas abzubilden in XSL wirklich kein so großes Problem.

Für einen Tipp wäre ich sehr dankbar, denn mir fällt wirklich nichts ein. Ein Stichwort,
oder ein Link, würde vielleicht schon reichen.

Erschwerend kommt hinzu, dass die einzelnen Klassen der gleichen Ebene "zusammengefasst"
werden, also _nicht_ sowas:

Du möchtest eine Doku, das wie eine JavaDoku aufgebaut ist?

Wäre eine gute Basis, ja.

Wie kann man das mit XSLT abbilden? - Geht das überhaupt? - Meiner Meinung nach braucht es dafür eben einen Algorighmus, der einen Baum erstellt; ich weiss derzeit nicht, wie
ich dies mit XSLT machen soll.

So langsam verstehe ich was du meinst: das geht auch mit XSLT, mit rekursiven templates etc. ist sowas möglich, kommt nur wirklich darauf was du genau haben möchtest.

OK, rekursive templates, nur müssten diese im Input-Stream herumspringen, wie ist das
realisierbar? - Ich hoffe, dass ich mein Anliegen in [pref:t=35303&m=195253] etwas
genauer beschreiben konnte?

Viele Grüsse und Danke!

Philipp

[Thomas J.S.]

Hallo Philipp,

... Klar arbeitet er mit Bäumen, aber das Traversieren derjenigen ist auf die Verwendung von templates beschränkt und denen kann man keinen Zielknoten angeben (oder doch? select mit einer Variable möglich?).

Natürlich kannst du beim Templates Zileknoten angeben.

Das Prinzip, wie XSL(T) vorgeht ist mir bekannt;

OK, und wie ist das Prinzip vom XSLT? ;-)

...! - Höre ich mich wirklich so leienhaft an?

Irgendwie, ja. Ohne dich damit beleidigen zu wollen.

Ja, das wird mir jetzt klarer, aber sowas abzubilden in XSL wirklich kein so großes Problem.

Für einen Tipp wäre ich sehr dankbar, denn mir fällt wirklich nichts ein. Ein Stichwort,
oder ein Link, würde vielleicht schon reichen.

Stöbere mal unter:
http://www.dpawson.co.uk/xsl/sect2/sect21.html

Du möchtest eine Doku, das wie eine JavaDoku aufgebaut ist?

Wäre eine gute Basis, ja.

Müsste dein XML dann nich auch so aussehen? ;-)

OK, rekursive templates, nur müssten diese im Input-Stream herumspringen, wie ist das
realisierbar?

http://www.dpawson.co.uk/xsl/sect2/recursion.html

• Ich hoffe, dass ich mein Anliegen in [pref:t=35303&m=195253] etwas genauer beschreiben konnte?

Ich werde mir das etwas später ansehen.

Schöne Grüße
Thomas

[Thomas J.S.]

Hallo Philipp,

doc.xml          - wobei doc.xml als Eingabe benutzt wurde, was

So, ich habe mal auf die schnelle einen XSL-Sheet geschrieben, der mit deiner XML-Datei funktioniert:
Ich habe nciht alles (z.B. kein Inhaltsverzeichniss) gemacht, aber das wirst du schon sehen:

Grüße
Thomas
----------------------------------------------
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="html" encoding="iso-8859-1" indent="yes" />

<xsl:template match="/component">
   <html>
  <head>
   <title><xsl:value-of select="name" /></title>
        <style>
     <![CDATA[
           .class_title { text-color: #00ff00; font-family: Arial; font-size: 25pt; }
           .method_title { font-family: Arial; background-color: #999999; text-color: #000000; border-width: 1px; border-color: #000000; border-style: solid; }
           .class_table { width: 500px; border-width: 1px; border-color: #000000; border-style: solid; }
           .desc_title { vertical-align: top; font-family: Arial; font-size: 10pt; }
           .desc_value { font-size: 10pt; }
           .in_title { vertical-align: top; font-family: Arial; font-size: 10pt; }
           .in_value { font-size: 10pt; }
           .out_title { vertical-align: top; font-family: Arial; font-size: 10pt; }
           .out_value { font-size: 10pt; }
           .notes_title { vertical-align: top; font-family: Arial; font-size: 10pt; }
           .notes_value { font-size: 10pt; }
     ]]>
        </style>
  </head>

<body>
   <xsl:apply-templates select="class"/>
  </body>
  </html>
 </xsl:template>

<xsl:template match="class">
  <a name="{@name}" id="{name}"></a>

<h1 class="class_title" id="class_{@name}">
   <xsl:value-of select="@name" />
  </h1>

<table class="class_table" id="class_table_{@name}">
   <xsl:for-each select="method">
    <tr>
     <td class="method_title" colspan="3">
      <xsl:value-of select="@restriction" />&#160;
      <a name="{@name}" id="{@name}">
       <xsl:value-of select="@name" />
      </a>
     </td>
    </tr>
    <xsl:if test="description">
     <tr>
      <td class="desc_title">Description:</td>
      <td class="desc_value">
       <xsl:value-of select="." />
      </td>
     </tr>
    </xsl:if>
    <xsl:if test="in and (in !='')">
     <tr>
      <td class="in_title">Input:</td>
      <td class="in_value">
       <xsl:apply-templates />
      </td>
     </tr>
    </xsl:if>
    <xsl:if test="out and (out !='')">
     <tr>
      <td class="out_title">Output:</td>
      <td class="out_value">
       <xsl:apply-templates />
      </td>
     </tr>
    </xsl:if>
    <xsl:if test="notes">
     <tr>
      <td class="notes_title">Notes:</td>
      <td class="notes_value">
       <xsl:value-of select="." />
      </td>
     </tr>
    </xsl:if>
   </xsl:for-each>
  </table>

</xsl:template>

<xsl:template match="item">
  <xsl:value-of select="@type" />: <xsl:value-of select="." />
  <xsl:if test="@class">
   (Class: <a href="#{.}"><xsl:value-of select="." /></a>)
  </xsl:if>
 </xsl:template>

</xsl:stylesheet>

[Philipp Hasenfratz]

Halihallo Thomas

So, ich habe mal auf die schnelle einen XSL-Sheet geschrieben, der mit deiner XML-Datei funktioniert:
Ich habe nciht alles (z.B. kein Inhaltsverzeichniss) gemacht, aber das wirst du schon sehen:

Vielen Dank für das Beispiel. Das Inhaltsverzeichnis würde ich sowieso in eine andere
Datei auslagern (und das würde ich selber fertigstellen können ;)).
Leider hat dies über die Transformation mit XML::XSLT für Perl nicht 100% funktioniert.
Die Input/Output - Parameter werden nicht ausgegeben, nach einigen Änderungen werden sie
zwar Ausgegeben, jedoch mit Description und Notes angehängt... Das Problem liegt, wie ich
glaube, nicht bei bei deinem XSLT, sondern dem XML::XSLT Modul; nach durchsicht der Doku
gibt es anscheinend noch Lücken in der Implementation; es ist noch nicht 100% W3C
compatible; schade... Wie mir scheint gibt's einige Probleme mit xsl:if und xsl:when.
Ich werde noch etwas testen, vielleicht habe ich auch einen Fehler gemacht...

Eigentlich würde ich die Transformation über XSLT bevorzugen, wenn ich dann davon
überzeugt bin, dass ich alles damit transformieren kann[1]. Ich möchte die beiden
Techniken (einmal über DocComponent-Interface und einmal über XSLT) nicht mischen, wenn
es nicht nötig ist; muss jedoch gestehen, dass es mir nicht gefällt, wie ich Code und
Design vermischt habe, dies wäre mit XSLT anders (und sogar standardisierter).

[1] siehe anderes Posting mit "normalisierter Vererbungshierarchie".

Viele Grüsse und Danke für deine Arbeit!

Philipp

[Simon Reinhardt]

Hi!

So, ich habe mal auf die schnelle einen XSL-Sheet geschrieben, der mit deiner XML-Datei funktioniert:
Ich habe nciht alles (z.B. kein Inhaltsverzeichniss) gemacht, aber das wirst du schon sehen:

Tja, genau das ist ja der springende Punkt: das Inhaltsverzeichnis. Natürlich kann man in XSLT durch Baumstrukturen wandern - aber die Frage ist: wie erstellt man diese in XSLT? In seiner XML-Datei sind die Klassen untereinander aufgelistet und im Enddokument sollen sie hierarchisch dargestellt werden. Als Verbindung dient nur das extends-Attribut. Mir fällt da jetzt auch auf Anhieb keine Lösung ein.

VG Simon

[Thomas J.S.]

Hallo Simon,

Tja, genau das ist ja der springende Punkt: das Inhaltsverzeichnis. Natürlich kann man in XSLT durch Baumstrukturen wandern - aber die Frage ist: wie erstellt man diese in XSLT? In seiner XML-Datei sind die Klassen untereinander aufgelistet und im Enddokument sollen sie hierarchisch dargestellt werden. Als Verbindung dient nur das extends-Attribut. Mir fällt da jetzt auch auf Anhieb keine Lösung ein.

Mir schon, aber ich habe im Moment dazu keine Zeit, der andere Sheet braucht paar Min., daher war das kein Problem.

Schöne Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Simon und Thomas

Tja, genau das ist ja der springende Punkt: das Inhaltsverzeichnis. Natürlich kann man in XSLT durch Baumstrukturen wandern - aber die Frage ist: wie erstellt man diese in XSLT? In seiner XML-Datei sind die Klassen untereinander aufgelistet und im Enddokument sollen sie hierarchisch dargestellt werden. Als Verbindung dient nur das extends-Attribut. Mir fällt da jetzt auch auf Anhieb keine Lösung ein.

Genau das ist mein Problem. Ich habe noch darüber nachgedacht. Die Verbindung stellt das
extends-Attribut dar, welches als "Foreign Key" (wenn ich das mal so als Analogie
verwenden darf) für eine andere Klasse dient und dessen name-Attribut entspricht. Wenn
man jetzt einen Tree der Vererbungen realisieren möchte, müsste man von diesem @extends
auf die Node der referenzierten Klasse springen und dort das selbe Verfahren iterierend
verwenden. Jetzt ist die Frage, wie man mit XSLT diese Rekursion (das wiederverwendbare
Schema auf referenzierte Knoten anwenden) erstellen kann. Konkreter würde dies so
aussehen:

Input.xml
<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>

Ausgabe.txt sollte etwa so aussehen:

Klasse v1
  |
  +-- Klasse v2
  |      |
  |      +-- Klasse v3
  |
  +-- Klasse v21
         |
         +-- Klasse v31

pseudo transform.example.xslt

<xsl:template name="vererbung">
   <xsl:value-of select="@extends" />
   <xsl:if test="@extends">
      <xsl:if test="/component/class/@name = ./@extends">
         <xsl:call-template name="vererbung" on="/component/class/@name = ./@extends"/>
      </xsl:if>
   </xsl:if>
 </xsl:template>

das on="..." würde dann einem Selektieren des "Zielbaumes"[1] entsprechen, von wo aus
weitertransformiert werden würde und somit die Rekursion eingeleitet wird, bis in
@extends nichts mehr steht. Die grosse Frage ist: Wie kann man mit XSLT in dem Eingabe-
Baum durch die Knoten des DOM springen? - Die Antwort lautet meiner Meinung nach: Geht
nicht. Deshalb habe ich geschrieben, dass ich mich gerne vom Gegenteil überzeugen lasse,
bzw. für andere Lösungsvorschläge dankbar wäre; kann ja sein, dass ich von einem völlig
falschen Grundkonzept ausgehe und es ganz anders zu machen wäre mit den Mitteln von
XSLT, nur: mir fällt keine ein. Zudem, was ich da oben an Beispiel für eine XSLT ge-
schrieben habe, würde auch nicht ganz dem Ausgabe.txt entsprechen (mal von der Syntax
abgesehen), da der Baum nur für eine Klasse erstellt werden würde und somit eine ganz
einfache Syntax hätte (z. B. v1->v2->v3). Was für eine Klassenübersicht sinnvoll wäre
ist, ein Baum, der alle Klassenvererbungen abbildet und die gleichen Klassen
zusammenfassen würde. Hat jemand eine Idee, wie sich dies realisieren lassen würde?

[1] des Inputs, nicht in den Transformationsregeln und Node des XSLT-Sheets.

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Philipp,

Input.xml
<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>

Dein Doc.xml schaut aber anders aus:
<class name="DocParser">
   <method restriction="public" name="parseTree">
      <in>
         <item type="instance" class="XML.DOM.Document">DOMDocument</item>
      </in>
   </method>
</class>

<class name="DocComponent" extends="XML.DOM.Document">

</class>

Hier verweist eine Klasse nicht auf eine andere Klassen, sonder nur auf eine Methode einer Klasse.
Oder: z.B. es gibt öfters Klassen die ein "extends="XML.DOM.Element"" haben, aber es gibt keine Klasse mit einem Namen "XML.DOM.Element". Das selbe ist mit extends="XML.DOM.NodeList.

Sprich, mir scheint deine doc.xml etwas inkonsistent zu sein um daraus ein Inhaltsverzeichniss generieren zu können. Es gibt keine Querverweise die man nutzen könnte.

Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Input.xml
<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>

Dein Doc.xml schaut aber anders aus:
<class name="DocParser">
   <method restriction="public" name="parseTree">
      <in>
         <item type="instance" class="XML.DOM.Document">DOMDocument</item>
      </in>
   </method>
</class>

<class name="DocComponent" extends="XML.DOM.Document">

</class>

Hier verweist eine Klasse nicht auf eine andere Klassen, sonder nur auf eine Methode einer Klasse.

Ich kann beim besten Willen nicht sehen, aufgrund welcher Information du dies folgerst.

Oder: z.B. es gibt öfters Klassen die ein "extends="XML.DOM.Element"" haben, aber es gibt keine Klasse mit einem Namen "XML.DOM.Element". Das selbe ist mit extends="XML.DOM.NodeList.

Aha, ja, das war eine kleine Inkonsistenz im Datenmodell, welche ich mit
<external_component> und <external_class> umgehen werde. Die referenzierten Klassen
gehören nicht zur Komponente, die Dokumentiert werden soll, sondern zu einer anderen
Komponente, die ich mit <external_*> abbilden (nur den Komponentenname und -Klassen;
die Doku soll die andere Komponente (XML.DOM in diesem Falle) nicht auch noch umfassen,
deshalb sind das nur "Querverweise" und Informationen, die für den Index gebraucht
werden) werde. Aber wie kommst du auf "Methoden einer Klasse"? - XML.DOM.Document und
-Element sind Klassen der Komponente XML.DOM.

Sprich, mir scheint deine doc.xml etwas inkonsistent zu sein um daraus ein Inhaltsverzeichniss generieren zu können. Es gibt keine Querverweise die man nutzen könnte.

In der vorliegenden Version hast du recht. Entschuldigung, dass ich die neue Version
nicht genannt habe:

<library>
   <component name="DocComponent">
      ... <!-- das alte -->
   </component>
   <external_component name="XML.DOM">
      <external_class name="XML.DOM.Document" extends="XML.DOM.Node"></external_class>
      <external_class name="XML.DOM.Element" extends="XML.DOM.Node"></external_class>
      <external_class name="XML.DOM.NodeList" extends="XML.DOM.Node"></external_class>
      <external_class name="XML.DOM.Node"></external_class>
   </external_component>
</library>

Optional external_component mit Attribut src um eine externe Ressource ggf. einzulesen.

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Philipp,

Dein Doc.xml schaut aber anders aus:
<class name="DocParser">
   <method restriction="public" name="parseTree">
      <in>
         <item type="instance" class="XML.DOM.Document">DOMDocument</item>
      </in>
   </method>
</class>

<class name="DocComponent" extends="XML.DOM.Document">

</class>

Hier verweist eine Klasse nicht auf eine andere Klassen, sonder nur auf eine Methode einer Klasse.

Ich kann beim besten Willen nicht sehen, aufgrund welcher Information du dies folgerst.

Das steht so in deinem (alten?) doc.xml.
"extends" bedeutet für mich "[es] erweitert", also die Klasse:
<class name="DocComponent" extends="XML.DOM.Document"> erweitert die Klasse "XML.DOM.Document". Es gb aber keine Klassen mit diesem Namen.
Es gab nur eine Methode einer anderen Klasse mit einem "class="XML.DOM.Document" Attribut.
So nahm ich an, dass der Verweis im "extends" datauf hindeutet.
Was bedeutet sonst?
<method restriction="public" name="parseTree">
  <in>
    <item type="instance" class="XML.DOM.Document">DOMDocument</item>
</in>
</method>
----------------

<library>
   <component name="DocComponent">
      ... <!-- das alte -->
   </component>
   <external_component name="XML.DOM">

<external_class name="XML.DOM.Node"></external_class>
   </external_component>
</library>

Ich weiss zwar noch immer nicht was du machst und wozu das ganze ist (mich haben eben nur die Fragen um XSLT interessiert),
aber eine referenzierte Klasse gehört in meinem Augen auch zum Komponent: dass es nicht umfassend dargestellt werden soll, ist schon klar, aber so wie es bei dir oben steht, weiss niemand außer dir welche Komponentet die <external_component name="XML.DOM"> referenziert.

Das gilt natürlich nur dann, wenn du in deinem Library mehrere Komponenten beschreibst, wenn du pro Library nur eine Komponente beschreibst, ist die sache klar.

Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Das steht so in deinem (alten?) doc.xml.

Ja. Alt sowie neu.

"extends" bedeutet für mich "[es] erweitert", also die Klasse:

Dann bedeutet es für uns beide das selbe ;-)

<class name="DocComponent" extends="XML.DOM.Document"> erweitert die Klasse "XML.DOM.Document". Es gb aber keine Klassen mit diesem Namen.

Ja, da diese auch nicht zu der zu dokumentierenden Komponente gehört. Es muss eine
Trennung zwischen verschiedenen Komponenten vorgenommen werden, besonders in der Grösse
der einzugebenden Daten, deshalb die external_* - Nodes; man soll nicht noch XML.DOM
dokumentieren, wenn man eine neue Komponente erstellen will, ist ja einleuchtend...
Die Klasse XML.DOM.Document würde in dem Fall von oben in einer <external_component
name="XML.DOM"><external_class name="XML.DOM.Document" /></external_comp.> abgebildet.
So ist die Vererbungshierarchie vollständig abbildbar, ohne die Komponenten explizit und
vollständig in die Dokumentation aufzunehmen.

Es gab nur eine Methode einer anderen Klasse mit einem "class="XML.DOM.Document" Attribut.
So nahm ich an, dass der Verweis im "extends" datauf hindeutet.
Was bedeutet sonst?
<method restriction="public" name="parseTree">
  <in>
    <item type="instance" class="XML.DOM.Document">DOMDocument</item>
</in>
</method>

Aha, hier liegt der Hacken: Die Methode parseTree erwartet als Eingabeparameter (in)
eine Instanz der Klasse XML.DOM.Document. Also etwa parseTree($dom), wobei $dom eine
Instanz der Document-Klasse von XML.DOM ist. Das hat mit dem Attribut "extends" nichts
zu tun.

Ich weiss zwar noch immer nicht was du machst und wozu das ganze ist (mich haben eben nur die Fragen um XSLT interessiert),

Nun, ich habe nichts dagegen; wenn du dich jedoch ein kleines bisschen mit dem Kontext
beschäftigt hättest, würdest du verstehen, worum es mir geht. Ich sage ja nicht, dass
es deine Aufgabe ist mich zu verstehen, oder gar mir zu helfen; aber vielleicht hilft
dir die Lektüre meiner Postings, um mein Problem besser zu verstehen, denn ich bin der
Meinung, dass ich es ausreichend erklärt habe.

aber eine referenzierte Klasse gehört in meinem Augen auch zum Komponent: dass es nicht umfassend dargestellt werden soll, ist schon klar, aber so wie es bei dir oben steht, weiss niemand außer dir welche Komponentet die <external_component name="XML.DOM"> referenziert.

Jein, eine referenzierte Klasse gehört nicht umbedingt zur Komponente; falls die
referenzierte (extends) Klasse einer andere Komponente, wie z. B. XML.DOM angehört,
gehört sie eben nicht zur aktuellen Komponente.
Die <external_component>-Nodes referenzieren keine Klassen, sie sind Kontainer für
Klassen, die eben nicht weiter ausdokumentiert werden sollen. In diesem Kontainer
werden die Klassen der (nicht zu dokumentierenden) Komponente abgebildet, aufwelche
eben ggf. referenziert wird. Beispiel:

<class name="DocComponent" extends="XML.DOM.Document">
...
<external_component name="XML.DOM">
   <external_class name="XML.DOM.Document" extends="XML.DOM.Node">...</external_class
   ...
   <external_class name="XML.DOM.Node">...</external_class>
   ...
</external_component>

Klasse "DocComponent" erweitert die Klasse "XML.DOM.Document"; das XSLT Template
sollte also entweder in <class> oder in allen <external_class> nach dem Klassennamen
"XML.DOM.Document" suchen und diesen ausgeben. Danach geht es rekursiv bei der
Klasse XML.DOM.Document weiter; ein kurzer Blick in @extends => 'XML.DOM.Node',
also geht die Suche nach der Klasse XML.DOM.Node los; also wieder alle <class>
und <external_class> nach XML.DOM.Node durchsuchen. Gefunden... aha, @extends
leer => Rekursionsbedinung erfüllt und zurück.

Das gilt natürlich nur dann, wenn du in deinem Library mehrere Komponenten beschreibst, wenn du pro Library nur eine Komponente beschreibst, ist die sache klar.

Die Library umfasst genau eine Komponente, die dokumentiert werden soll (eingeführt
durch <component>); um jedoch den ganzen Kontext zu erfassen, werden auch noch
andere Komponenten aufgenommen (<external_component>). Letztere haben einzig den
Zweck, die Vererbungshierarchien genau abbilden zu können.
Nun ja, eigentlich ist das Interface auf Perl Seite so ausgerichtet, dass auch
mehrere Componenten (ausdokumentierte) in die Library aufgenommen werden können,
aber für das XSLT geh ich jetzt von der Annahme aus, dass es nur ein Element
<component> gibt, jedoch mehrere <external_component>'s.

---
Vielleicht ein doc.xml Konflikt (tausendmal Entschuldigung, wenn ja)? -
http://www.emedias.ch/tmp/doc.xml
---

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Philipp,

Ich habe jetzt mal alls aus der Posting gelöscht.
Sorry, wenn ich etwas nerve, aber du hast mal gesagt:

----------
<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>
------------

Dein XML hat davon nichts:
(ich habe alles auf das wesentliche reduziert (die sortierung ist von mir, das können wir iher ignorieren))
-------------

<component name="Doc">
<class name="DocParser"></class>
<class name="DocAttribute"> </class>
<class name="DocLibrary"   extends="XML.DOM.Document"></class>

<class name="DocExternalClass"  extends="XML.DOM.Element"></class>
<class name="DocComponent"   extends="XML.DOM.Element"></class>
<class name="DocClass"    extends="XML.DOM.Element"></class>
<class name="DocMethod"   extends="XML.DOM.Element"></class>
<class name="DocItem"    extends="XML.DOM.Element"></class>

<class name="DocClassMap"   extends="XML.DOM.NodeList"></class>
<class name="DocAttributeList"  extends="XML.DOM.NodeList"></class>
<class name="DocMethodList"  extends="XML.DOM.NodeList"></class>
<class name="DocOutputList"  extends="XML.DOM.NodeList"></class>
<class name="DocInputList"   extends="XML.DOM.NodeList"></class>

</component>

<external_component name="XML.DOM">
   <external_class name="XML.DOM.Document" extends="XML.DOM.Node"></external_class>
   <external_class name="XML.DOM.Element" extends="XML.DOM.Node"></external_class>
   <external_class name="XML.DOM.NodeList" extends="XML.DOM.Node"></external_class>
   <external_class name="XML.DOM.Node"></external_class>
</external_component>

</library>

--------------------

Wie dem auch sei:
Ich habe dir einen XSL-Sheet hochgeladen (weil ich glaube, dass der nicht in einer Posting passt.
http://www.meta-text.net/test/doc.xsl

Ich habe damit gearbeitet, was ich hatte: also mit deinem zuletzt verlinkten doc.xml.
Ich steige damit langsam aus diesem Thread aus (ich mag Perl nicht und das animiert mich nicht gerade dazu mich in Klassen und Methoden zu vertiefen *g*), mir ging es ja nur darum, dass ich überzeugt bin, dass deine anforderungen auch mit XSLT erfüllt werden können.

Ich habe die interne Verlinkung etwas überarbeiten müssen, denn einge Methoden in verschiedenen Klassen hatten den selben Namen.
Sicher könnte man einiges anderes machen: z.B. bei der Rekursion statt for-each mit key's arbeiten etc., aber ich denke das wesentlich ist "angekommen".

Schöne Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Ich habe jetzt mal alls aus der Posting gelöscht.
Sorry, wenn ich etwas nerve, aber du hast mal gesagt:

---

<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>

Dein XML hat davon nichts:

Das war ein Beispiel, um die Sache etwas auf das Wesentliche zu reduzieren!?

Ich habe damit gearbeitet, was ich hatte: also mit deinem zuletzt verlinkten doc.xml.
Ich steige damit langsam aus diesem Thread aus (ich mag Perl nicht und das animiert mich nicht gerade dazu mich in Klassen und Methoden zu vertiefen *g*), mir ging es ja nur darum, dass ich überzeugt bin, dass deine anforderungen auch mit XSLT erfüllt werden können.

Vielen Dank für dein XSL! - So habe ich mir das vorgestellt. Hatte gestern noch ver-
zweifelt versucht das ganze selber zu lösen, kam jedoch nicht zum gewünschten Erfolg.
Um so mehr danke ich dir für deine Arbeit! - Auch mit deinen Links (vielen Dank auch
für diese), obwohl der Inhalt verständlich ist, war ich irgendwie nicht in der Lage
zur lösung meines Problems.

Ich habe die interne Verlinkung etwas überarbeiten müssen, denn einge Methoden in verschiedenen Klassen hatten den selben Namen.
Sicher könnte man einiges anderes machen: z.B. bei der Rekursion statt for-each mit key's arbeiten etc., aber ich denke das wesentlich ist "angekommen".

Ich sehe das jetzt so: Ich komme von meiner Perl-Lösung weg und versucht das mit XSL
umzusetzen; das ist gleich eine gute Übung für mich *g*. Ich werde (wenn ich endlich
wieder Zeit habe... *grrr*) mich dann noch um die Details kümmern ;)

Viele Grüsse

Philipp

[Thomas J.S.]

Hallo Philipp,

Vielen Dank für dein XSL! - So habe ich mir das vorgestellt. Hatte gestern noch ver-
zweifelt versucht das ganze selber zu lösen, kam jedoch nicht zum gewünschten Erfolg.

Das eigentliche "Problem" ist, um sowas im Ergebnis wie im toc2 zu erzeugen, muss man zwei verch. Gruppierungen miteinander kombinieren. Und wenn du nicht nur die Querverweise auf external_class in den Klassen hast, sondern auch Querverweise auf Klassen muss man 3 Gruppierungen miteinander verflechten.
Meine Lösung berücksichtigte z.B. sowas nicht:

---

<component>
   <class name="v1" />
   <class name="v2" extends="v1"/>
   <class name="v3" extends="v2"/>
   <class name="v21" extends="v1"/>
   <class name="v31" extends="v21"/>
</component>

also wo Klassen auf andere Klassen und nicht auf external_class verweisen (jedoch sollte das Prinzip der Abfragen jetzt klar sein *g*). Ebenso kann man sich darüber streiten ob die vielen Abfragen mit "//element" performancemäßig gut sind oder nicht, aber wie gesagt: es gibt auch andere Lösungen. ;-)

Schöne Grüße
Thomas

[Philipp Hasenfratz]

Halihallo Thomas

Vielen Dank für dein XSL! - So habe ich mir das vorgestellt. Hatte gestern noch ver-
zweifelt versucht das ganze selber zu lösen, kam jedoch nicht zum gewünschten Erfolg.

Das eigentliche "Problem" ist, um sowas im Ergebnis wie im toc2 zu erzeugen, muss man zwei verch. Gruppierungen miteinander kombinieren. Und wenn du nicht nur die Querverweise auf external_class in den Klassen hast, sondern auch Querverweise auf Klassen muss man 3 Gruppierungen miteinander verflechten.

Ich sehe das Problem. Auf was habe ich mich da nur eingelassen *g*...

also wo Klassen auf andere Klassen und nicht auf external_class verweisen (jedoch sollte das Prinzip der Abfragen jetzt klar sein *g*). Ebenso kann man sich darüber streiten ob die vielen Abfragen mit "//element" performancemäßig gut sind oder nicht, aber wie gesagt: es gibt auch andere Lösungen. ;-)

TIMTOWTDI eben, ja :-)
Komisch, jetzt ist mir alles klar; nur bin ich eben selber nicht darauf gekommen. Danke
für den "Geistesblitz". Wegen der Performance: Ich habe schon bemerkt, dass eine reine
XSLT Variante zumindest in Perl implementiert (wobei dies jetzt leider nicht mehr
funktioniert, da in XML::XSLT einiges, was ich dazu bräuchte nicht implementiert ist)
schon langsamer ist, als eine "reine Perl & XML" Variante. Das ist jedoch für diese
Aufgabenstellung nicht relevant. Es geht hier um relativ kleine XML Dokumente, welche
nur einer Dokumentation dienen. Diese wird wohl einige male überarbeitet und neu in
HTML transformiert. Da spielt es keine Rolle, ob die Übersetzung eine Sekunde oder
zwanzig Sekunden dauert. Also von der Performanceoptimierung habe ich mich in diesem
Projekt distanziert; hier geht es um ein gutes, leichtverständliches und übersichtliches
Layout für eine Komponentenbeschreibung.

Nochmals besten Dank für deine Hilfe! - Auf dem Gelernten und von dir Erarbeiteten kann
ich aufbauen. Und mit diesen Worten verabschiede auch ich mich von dem Thread, falls
nicht noch weitere Postings hinzukommen (was ich damit überhaupt nicht unterbinden
möchte).

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

Wie die Zeit verrinnt... :-(
Leider vereinnahmt mich die Firma im Moment zu 100%, komme derzeit mit der Doku nicht
weiter. Ich habe mich jetzt dazu entschieden auch auf XSLT umzusteigen (wenn Thomas
meint, dass das funktioniert, dann wird's wohl auch; wenn nicht, auch gut, dann gibt's
eben ein etwas weniger "algorithmisch ausgefeiltes" Inhaltsverzeichnis [bzw.
Vererbungshierarchieverzeichnis]); gleichzeitig möchte ich auch meine DocComponent bei-
behalten, um später mal einen schönen PDF Output zu generieren (viel später leider).
Nun ja, dieser Thread wird bald im Archiv verschwinden und taugt nicht mehr zu sehr
vertiefenden Diskussionen, deshalb werde ich bei gegebener Zeit darauf zurückkommen und
auch nochmal anfragen, wie das mit dem Inhaltsverzeichnis geht (falls ich es bis dann
nicht selber herausfinde). Auf jeden Fall wollte ich mich bei allen für die Antworten
und Anregungen bedanken! - Danke.

Viele Grüsse

Philipp