Mr.Green
Anmeldungsdatum: 21. April 2007
Beiträge: 464
|
Hallo zusammen, ich versuche derzeit, einen Codegenerator in XSLT zu bauen, und stehe nun vor dem Problem, die Templates und die XML-Eingabedokumente zu trennen und zu modularisieren. Meine Struktur soll die folgende werden: Eine Entity A soll aus mehreren Bs bestehen, die wiederum aus mehreren Cs bestehen können, die wiederum aus mehreren Ds bestehen können: A
+-B
| +-C
| | +-D
| | --D
| --C
| --D
+-B
+-C
| --D
--C
Ich möchte nun jede der Entiäten in einem eigenen XML-Dokument beschreiben, und für jede ein eigenes XSLT-Template haben. Mein Problem ist nun aber, wie ich ein "Master"-Template baue, das für "jedes A, jedes B, jedes C"... die entsprechenden Templates aufruft und mir dann die Ergebnisdatei zusammenbaut. Ich bin mir fast sicher, dass man es über document() und xsl:apply-templates lösen kann, aber ich stehe hier auf dem Schlauch. Hat jemand einen Tip? Gruß
Mr.Green
|
xabbuh
Anmeldungsdatum: 25. Mai 2006
Beiträge: 6411
|
Kannst du mal ein kleines Beispiel geben, was genau du da vorhast?
|
Mr.Green
(Themenstarter)
Anmeldungsdatum: 21. April 2007
Beiträge: 464
|
Klar. Ich habe eine Kette aus Software-Modulen, die ich instanziieren will. Ich nenne die mal Filter. Diese Filter bilden eine Filterkette, die wiederum in einer Ketteninstanz verwendet werden soll, die ich dann in meine Software einbinde. Als einfaches Beispiel mal die C-Struktur, die ich (u.a.) eben mit XSLT generieren will: typedef struct
{
int foo;
} FilterX;
typedef struct
{
double bar;
} FilterY;
typedef struct
{
FILTER_x fx[4];
FILTER_y fy;
} FilterchainX;
typedef struct
{
FILTER_y fy[10];
} FilterchainY;
typedef struct
{
FILTERCHAIN_x fcx;
FILTERCHAIN_y fcy;
} Instance;
typedef struct
{
Measinstance m;
} Main; Beschreiben will ich die Struktur oben wie folgt: FilterX.xml:
<filter name="FilterX">
<var name="foo" type="int"/>
</filter>
FilterY.xml:
<filter name="FilterY">
<var name="bar" type="double"/>
</filter>
FilterchainX.xml:
<filterchain name="FilterchainX">
<use_filter name="fx" type="FilterX" size="4"/>
<use_filter name="fy" type="FilterY"/>
</filterchain>
FilterchainY.xml:
<filterchain name="FilterchainY">
<use_filter name="fy" type="FilterY" size="10"/>
</filterchain>
Instance.xml:
<instance name="Instance">
<use_filterchain name="fcx" type="FilterchainX"/>
<use_filterchain name="fcy" type="FilterchainY"/>
</instance>
Main.xml
<main>
<use_instance name="m" type="Instance"/>
</main>
Das Ganze kann halt beliebig skalieren.
Weil die Templates umfangreichen werden, möchte ich sie halt in verschiedene Templates und XML-Beschreibungen auslagern.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Wie erzeugst Du überhaupt XSLT, mit welcher Sprache ? - mir ist das nämlich immer ein Buch mit 7 Siegeln. Deshalb würde ich dazu xmlstarlet benutzen. Das wirft mit der Option -C seinen XSLT aus. track
|
Mr.Green
(Themenstarter)
Anmeldungsdatum: 21. April 2007
Beiträge: 464
|
Das XSLT Template schreibe ich von Hand.
Eigentlich ist das ja auch echt gut zu schreiben; mir fehlt da momentan für mein Problem nur eine gute Idee.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Wenn Du Dich mit XSLT so gut auskennst, würde mich interessieren, wie Du Dir das draufgeschafft hast. Kennst Du ein gutes Tutorial oder Nachschlagewerk ? - denn was ich bisher dazu gefunden habe (z.B. w3school und Zvon ), ist sowas von sperrig .... Da wäre ich dankbar für einen Tip (oder mehrere 😉 ). LG, track
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
track schrieb: Kennst Du ein gutes Tutorial oder Nachschlagewerk ? - denn was ich bisher dazu gefunden habe (z.B. w3school und Zvon ), ist sowas von sperrig ....
Naja, "sperrig" ist bei XML eben Programm 😈 Ich fand die Teile von s3school ganz ok; ansonsten hatte ich an der Uni ein Buch dazu... kann mich aber nicht mehr an den Titel erinnern. Ich gestehe, dass ich XSLT auch nur für Transformationen von XML → XML verwendet hatte. Ich würde das Problem des OP persönlich anders angehen und auf einen Mix aus JSON (Daten), Jinja2 (Template-Engine) und Python (Steuerung) setzen. Aber das ist eben immer auch eine Frage der persönlichen Fähigkeiten und vor allem Kenntnisse ☺
|
xabbuh
Anmeldungsdatum: 25. Mai 2006
Beiträge: 6411
|
Warum benötigst du dafür denn separate XML-Dateien? Kannst du die nicht einfacher alle in einer Datei definieren? Dann kannst du das ganze immer noch dynamisch erweitern, ohne dein XSLT anpassen zu müssen.
|
gonzo.d
Anmeldungsdatum: 8. Januar 2008
Beiträge: 201
Wohnort: Berlin
|
Lysander schrieb: Naja, "sperrig" ist bei XML eben Programm 😈 Ich fand die Teile von s3school ganz ok; ansonsten hatte ich an der Uni ein Buch dazu... kann mich aber nicht mehr an den Titel erinnern.
Hab grad das http://iss.uni-saarland.de/workspace/documents/wt_8_xml_xquery_xpath_und_xslt.pdf gefunden, gibt einen schnellen Überblick und Literaturempfehlungen. ru g
|
Mr.Green
(Themenstarter)
Anmeldungsdatum: 21. April 2007
Beiträge: 464
|
Hallo, ich will verschiedene XML-Dateien, weil die Entities voneinander getrennt sein sollen.
XML (und nicht etwas JSON) ist meiner Ansicht nach das Mittel der Wahl, weil ich daraus eben alles generieren kann, mir DTDs schreiben kann usw.
Damit prüfe ich schon lange vor dem Compiler, der den generierten Code zu sich nimmt, ob das Ursprungsdokument wohlgeformt ist. XSLT habe ich mir nebenbei beigebracht, im Wesentlichen nur über w3schools Tutorial. Sperrig finde ich das nicht, ich finde vorallem die Sandbox echt cool.
Danach hab ich mir Eclipse hergenommen, das hat auch ein XML-Plugin, was die Arbeit einfacher macht. Wenn ich vor einem konkrten Problem stehe, hilft Google i.d.R. weiter. Da gibt es dann immer kleine Beispiele. Sonst gibt es noch Altova XMLSpy. Das ist echt fett, aber sauteuer und nur 30 Tage Demo. Ich hab mein Ursprungsproblem nun gelöst, indem ich die Dokumente (Entities) über document() einbinde und die XSLT-Sub-Templates importiere.
Aufrufen kann man die Sub-Templates dann entweder über apply-templates oder call-templates.
Richtig cool: call-templates ist wie ein Funktionsaufruf, der sogar Parameter übergeben kann! Übrigens: Sperrig ist bei XML nicht Programm.
Ich gebe zu, man muss sich an manches gewöhnen, aber XSLT, XPath und DTDs finde ich persönich einfach nur genial. Ja, die Syntax ist gewöhnungsbedürftig, vorallem bei DTDs...
|
Lysander
Anmeldungsdatum: 30. Juli 2008
Beiträge: 2669
Wohnort: Hamburg
|
Mr.Green schrieb: Übrigens: Sperrig ist bei XML nicht Programm.
Doch! 😉
Ich gebe zu, man muss sich an manches gewöhnen, aber XSLT, XPath und DTDs finde ich persönich einfach nur genial. Ja, die Syntax ist gewöhnungsbedürftig, vorallem bei DTDs...
Mit richtigen Werkzeugen ist XML durchaus für viele Zwecke geeignet; es kommt wie immer auf den Einsatzzweck an. XML an sich ist aber sperrig, alleine durch die "Eloquenz" 😉
|
xabbuh
Anmeldungsdatum: 25. Mai 2006
Beiträge: 6411
|
Mr.Green schrieb: ich will verschiedene XML-Dateien, weil die Entities voneinander getrennt sein sollen.
Heißt aber, dass du das Template jedes Mal anpasst, wenn neue Entitäten dazu kommen?
Ich hab mein Ursprungsproblem nun gelöst, indem ich die Dokumente (Entities) über document() einbinde und die XSLT-Sub-Templates importiere.
Aufrufen kann man die Sub-Templates dann entweder über apply-templates oder call-templates.
Schreibst du dir für jede Entität ein eigenes Subtemplate? Das sollte doch eigentlich unnötig sein, wenn die Entitäten alle dem Muster folgen, das du in deinem Beitrag vorher gepostet hast, oder nicht?
Richtig cool: call-templates ist wie ein Funktionsaufruf, der sogar Parameter übergeben kann!
Du könntest auch noch EXSLT anschauen. Wenn du das verwendest, kannst du sogar "richtige" eigenes Funktionen schreiben, die du genau wie die eingebauten XSLT-Funktionen aufrufst.
|
Mr.Green
(Themenstarter)
Anmeldungsdatum: 21. April 2007
Beiträge: 464
|
Nein, neue Entities folgen natürlich meinem Muster (außer sie fallen aus dem Muster 😉 ), und ich kann sie automatisch transformieren. Ich habe jetzt Subtemplates für verschiedenen "Funktionen" geschrieben. Sie sind nicht nach Entity designt, sondern nach Anwendungszweck ("generiere mir die Private-Members, generiere mir die Methoden") und arbeiten alle auf denselben Entities.
|